Layered Architecture
Layered architecture organises code into horizontal layers with downward dependencies, making separation explicit but risking a leaky, anemic domain.
Definition
Layered architecture is a structural pattern that partitions a system into logical layers, such as presentation, application, domain, and infrastructure, where each layer depends only on the layers beneath it.
Context and scope
It is the default shape of many enterprise applications and a starting point for teams that need clear module boundaries.
Common misconceptions
- layers must be deployed as separate services
- strict layering automatically yields a good domain model
Anti-patterns
- letting the presentation layer call the database directly
- putting business rules in controllers or repositories
Related concepts
Authoritative source
https://martinfowler.com/bliki/PresentationDomainDataLayering.html
Definition
Layered architecture is a structural pattern that partitions a system into logical layers, such as presentation, application, domain, and infrastructure, where each layer depends only on the layers beneath it.
It is the default shape of many enterprise applications and a starting point for teams that need clear module boundaries. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.
When to use it
A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.
How it works
The rule that a layer may call only lower layers keeps dependencies acyclic, so a change in the domain does not ripple upward into infrastructure.
Technology concerns can leak through the layers unless the domain stays free of framework types, which is where the style is frequently compromised.
Trade-offs and alternatives
Because layers are logical rather than physical, all of them usually run in one process, which keeps deployment simple but limits independent scaling. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.
Common misconceptions
A persistent misconception is that layers must be deployed as separate services. Another is that strict layering automatically yields a good domain model. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.
Anti-patterns to avoid
Two recurring anti-patterns are to letting the presentation layer call the database directly and to putting business rules in controllers or repositories. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Onion Architecture, Clean Architecture, Domain-Driven Design.