Layered Architecture
Objectives
By the end of the lesson, you can distinguish a layer from a service, and explain the advantage and the typical weakness of layering.
Why is layering needed?
The oldest and most widespread way to organise the internal structure of a monolith is to divide the code into levels of responsibility. This approach influences later styles as well, so it is worth understanding precisely.
What is layered architecture?
Layered architecture divides the system into logical layers and prescribes that a layer may call only the one below it. Typical layers are presentation, business logic and data access. The Azure Architecture Center describes the N-tier style as one in which each layer has a defined responsibility, and dependencies are regulated by the rule that a higher layer can use services in a lower layer, but not the other way around.
A layer is a logical concept (code structure), a tier is a physical one (runtime). The same application can run in a single tier or on separate machines. A layer is therefore not a service and does not mean a network boundary.
flowchart TB
P["Presentation"] --> B["Business logic"]
B --> D["Data access"]
D --> DB[("Database")]
By aspect
| Aspect |
Layered structure |
| Coupling |
Regulated along layer boundaries; there is no separate boundary between functions |
| Deployability |
Typically one unit; a change touches several layers |
| Scaling |
A layer can be run and scaled separately if divided into several tiers |
| Data management |
Typically a shared database |
| Failure handling |
Simple, because the call stack is in one process |
| Cost |
Low; a familiar pattern |
What is the weakness of layering?
According to the Azure description, horizontal layering can make it harder to introduce change: a new function often goes through several layers, so a change affects several parts at once. A layer cuts by technical responsibility (data, logic, presentation), not by business responsibility. That is why layered code can become a collision point when many teams work at the same time.
A frequent mistake is also that layers "skip" each other (presentation calls data access directly), or that business rules leak into presentation. Layering gives an advantage only if the direction of dependency is checked.
How does it relate to the others?
The layered structure is simple and well known, but the direction of cutting (technical) differs from what the modular monolith (2.4) or microservices (3.3) use (business capability). Inside the modules of a modular monolith there are often layers too.
Common misconceptions
| Statement |
Clarification |
| "Three layers are three services." |
A layer is code structure; a tier is runtime structure. |
| "Layering is the same as splitting into modules." |
A layer is cut by technical, a module by business responsibility. |
| "Layering is outdated." |
It is still a common internal structure; its weakness is the direction of the cut, and that the monolithic design prevents independent release of features. |
In short
- Layered architecture divides into logical layers, and calls go one way.
- A layer is code structure, a tier is runtime structure.
- The cut follows technical responsibility, so one function goes through several layers.
- Keeping the direction requires checking.
Review questions
- How does a layer differ from a tier and from a service?
- Why does a new function often affect several layers?
- How can it be checked that the layers do not skip each other?
Learning resources
Layered Architecture
Objectives
By the end of the lesson, you can distinguish a layer from a service, and explain the advantage and the typical weakness of layering.
Why is layering needed?
The oldest and most widespread way to organise the internal structure of a monolith is to divide the code into levels of responsibility. This approach influences later styles as well, so it is worth understanding precisely.
What is layered architecture?
Layered architecture divides the system into logical layers and prescribes that a layer may call only the one below it. Typical layers are presentation, business logic and data access. The Azure Architecture Center describes the N-tier style as one in which each layer has a defined responsibility, and dependencies are regulated by the rule that a higher layer can use services in a lower layer, but not the other way around.
A layer is a logical concept (code structure), a tier is a physical one (runtime). The same application can run in a single tier or on separate machines. A layer is therefore not a service and does not mean a network boundary.
flowchart TB P["Presentation"] --> B["Business logic"] B --> D["Data access"] D --> DB[("Database")]By aspect
What is the weakness of layering?
According to the Azure description, horizontal layering can make it harder to introduce change: a new function often goes through several layers, so a change affects several parts at once. A layer cuts by technical responsibility (data, logic, presentation), not by business responsibility. That is why layered code can become a collision point when many teams work at the same time.
A frequent mistake is also that layers "skip" each other (presentation calls data access directly), or that business rules leak into presentation. Layering gives an advantage only if the direction of dependency is checked.
How does it relate to the others?
The layered structure is simple and well known, but the direction of cutting (technical) differs from what the modular monolith (2.4) or microservices (3.3) use (business capability). Inside the modules of a modular monolith there are often layers too.
Common misconceptions
In short
Review questions
Learning resources