The layered architecture, or n-tiered architecture, is one of the most common monolithic architecture styles. Components in a layered architecture are organized in horizontal layers, where each layer represents a specific role in the entire application. The most common case consists of four layers:
- Presentation Layer: handles the user interface and browser communications
- Business Layer: executes the business logic of the application
- Persistence Layer: handles data persistence logic, such as running SQL queries
- Database Layer: physical storage of data in a database or a file system
Key Properties
Separation of Concern
Since each layer performs a specific role and has specific responsibilities, components in each layer can focus on a single task, which allows developers who have specific technical expertise to focus on what they do best. However, it also means that the entire system is slow to respond to changes in requirements.
Isolation between Layers
Each layer in the layered architecture can either be a closed layer or an open layer. A closed layer cannot be bypassed, so for the layer above it to access the layer below it, the request must go through the closed layer in the middle. An open layer, on the other hand, can be bypassed, so the layer above it may directly access the layer below it.
In a layered architecture, changes in one layer generally does not impact components in other layers, so there is isolation between the layers. In order to ensure this isolation, the application cannot be tightly coupled between all the layers, which means that the best practice of layered architecture is to maintain closed layers.
Open Services Layer
One exception to the best practice of maintaining closed layers is the open services layer. In some applications, there are shared components that can be used by components in multiple layers, such as by the presentation layer and the business layer. In this case, there should be an additional services layer, which contains all of the shared components. This layer must be left open because even though it sits underneath the business layer, it needs to be directly access by both the presentation layer and the business layer.
Architecture Sinkhole
One common anti-pattern of the layered architecture is the architecture sinkhole, which is when some layers are simply passed through without performing any logic. For example, when the presentation layer needs to fetch some simple data from the database, it may do so with no action taken by the business layer and only a simple SQL query executed by the persistence layer.
This anti-pattern is very common and almost unavoidable in the layered architecture, so the best practice is not to eliminate it completely (which requires all layers to be open), but to keep it at a minimum. Generally, a rule of thumb is to have less than 20% of requests be architecture sinkholes.
Trade-Offs
Advantages
- Great for small, simple applications, or as a starting point to more complex applications due to its simplicity and low cost to implement.
Disadvantages
- As the application grows more complex, this architecture style is very difficult to maintain. Because it is a monolithic architecture style, deployments and testing are difficult. Even simple changes require the entire system to be fully tested and redeployed.
- Scalability is low due to the lack of modularity, because it is difficult to scale up one component independently of the other components.
- Fault tolerance is low because the monolithic design leads to a single point of failure. Any component’s failure could lead to the failure of the entire system.
