Layers in Software Architecture that Every Sofware Architect should Know
Architectures have the same objective — the separation of concerns. They all achieve it by dividing the software into layers. — Uncle Bob
Layers
Layers are horizontal (don’t get confused with title image) abstract parts of an application. Their boundaries are making a right angle with the data flow. Layers are representing the different levels and types of abstraction of the concerns which accompany software development.
Why Divide the Application into Layers
- Maintains the Single Responsibility Principle.
- Follows Separation of Concerns.
- Isolates development roles & skills. (Presentation Layer — FE dev, Business Layer — BE dev)
- Supports multiple implementations. (Interchangeable Presentation Layer)
- Varying rates of change.
- Slices application to more manageable units.
Layered Architecture Pattern
This is the most common architecture pattern, also known as the n-tier architecture pattern. It becomes standard for most OOP architects and developers.
Each layer covers a specific role within the application. Mostly, we distinguish between the classic three-layered architecture or four-layered domain-centric architecture. In this article, I will cover three-layered architecture. If you are more interested in domain-centric architecture, follow the link.
Three-layered Architecture
Three-layered architecture is the go-to for CRUD applications. By CRUD, I mean software, which the most often use-case is to Create, Read, Update, or Delete something.
I wouldn't recommend more complex domain-centric architecture for such systems. If you choose the domain-centric architecture for CRUD systems, you will find out that there is no material for domain modeling over time.
Presentation Layer
As the name suggests, the Presentation Layer contains code and technologies for User Experience. So, I am talking about web development frameworks like Angular or Blazor, less-used desktop frameworks like WPF or WinForms, and mobile development frameworks like Xamarin.
Presentation patterns like MVVM or MVC are also part of this layer. The BackEnd part of such patterns should logically operate only with presentation Models (presentation data structures).
Once there is a need to implement entity behavior, command, query, or some communication with external systems, it is a sign that this code belongs somewhere else. More precisely, into the Business Layer.
Business Layer
Business Layer is a filled code responsible for the existential meaning of software. Your application does not exist because it is a mobile app or because it uses Azure SQL Server. It exists because it has its purpose, and algorithms implementing that purpose belong to Business Layer.
The layer input is data structures received from Presentation Layer and the other end data structures from the Data Access Layer. The output is data structures expected by Presentation Layer or data structures expected by the Data Access Layer.
The form of the Business Layer’s output data structure should satisfy the other two layers as much as possible. Use-cases and behaviors are modifiers responsible for such formating.
There are more ways how to tackle the design of the Business Layer. Command Query Responsibility Separation or CQRS is one of them. You can read more about CQRS here.
Data Access Layer
Data Access Layer is responsible for the connection to persistence. The most common persistence is a relational database, so the Data Access Layer often contains the Object-relational mapping (ORM) framework like Entity Framework Core or Hibernate.
If you are using Entity Framework Core like me, this is the layer where you will design entities and database context.