Layered architecture organizes a system into horizontal tiers — typically presentation, application, domain and data — where each layer depends only on the layer below it. It is the default choice for most enterprise applications because it is simple to reason about.
The defining rule is unidirectional dependency: the presentation layer calls the application layer, which calls the domain layer, which talks to the data layer. Nothing points upward.
The four classic layers
Most implementations use a variant of these tiers, each with a single responsibility.
- Presentation: UI, controllers, input handling.
- Application: orchestration, use cases, transactions.
- Domain: business rules and domain models.
- Data: repositories, persistence and external integrations.
A clean dependency direction is worth more than a thousand lines of tests. If the domain layer imports UI code, the architecture has already leaked.
When layered architecture works best
It shines for applications with a clear business domain and predictable change: CRUD-heavy back offices, internal tools and classic enterprise systems. It is easy to hire for and easy to test each layer in isolation.
When it struggles
Problems appear when the system grows: cross-cutting concerns like logging and caching tend to drip through every layer, and a single "everything" domain layer turns into a god class. Teams then evolve toward ports and adapters or microservices.
// Unidirectional dependency example (conceptual)
presentation -> application -> domain -> data
// Never: data -> domain -> application -> presentationLayered architecture FAQ
How many layers should an application have?
Use the fewest layers that keep responsibilities clear — often three or four. More layers add indirection without adding value.
Is layered architecture obsolete?
No. It remains the industry baseline. Patterns like hexagonal or clean architecture are refinements that fix the same dependency problems layered design can suffer from.
