What it is#
The layered architecture (aka n-tier) organizes an application into horizontal layers, each with a specific responsibility (presentation, business, persistence, database). Layers form abstractions over the work required to satisfy a request so each layer can focus on its role and hide implementation details from others.
Typical topology#
- Commonly four layers: Presentation → Business → Persistence → Database.
- Variants exist: combine business+persistence, separate presentation into its own deployment, or bundle all layers into one monolithic deployment (common for small apps or on-prem products).
Roles of each layer#
- Presentation: UI, user input, formatting, client communication.
- Business: domain rules, orchestration, calculations, validation.
- Persistence: data access logic, repositories/DAOs, ORM usage.
- Database: physical storage (RDBMS, NoSQL, filesystems).
Open vs Closed layers & layers of isolation#
- Closed layer: requests must traverse layers in order (no skipping).
- Open layer: upper layers may bypass intermediate layers to reach a lower layer.
- Layers of isolation (goal): changes inside one layer should not affect others if inter-layer contracts remain stable. Closed layering is the usual mechanism to achieve isolation; opening layers reduces isolation and increases coupling.
When to add or rearrange layers#
- Add a services or shared layer to centralize common utilities and to enforce architectural access rules.
- Mark that layer open if business logic still needs optional bypass to lower layers; mark closed if you want strict isolation.
Strengths#
- Simple, familiar, low initial cost — good starting point for small or early projects.
- Clear separation of technical concerns, easier to assign responsibilities to teams.
- Easy to understand and implement; low barrier for developers.
Weaknesses / trade-offs#
- Monolithic deployment: small changes often require redeploying the whole unit.
- Poor agility: harder to evolve a specific domain because the domain is spread across layers.
- Scalability & elasticity: limited — vertical scaling predominates; fine-grained horizontal scaling is difficult.
- Testability & deployability: lower — larger regression surface and higher deployment risk.
- Performance & fault tolerance: not ideal for high-performance or highly fault-tolerant systems without extra engineering (caching, threading).
- Architecture sinkhole anti-pattern: excessive pass-through requests across layers with no real processing (wastes CPU/memory).
Guidance & best practices#
- Use layered architecture as a pragmatic starting point when requirements are unclear or time/budget are tight.
- Keep reuse minimal and inheritance shallow to preserve modularity and ease later migration.
- Explicitly document which layers are open vs closed and why — failure to do so leads to hidden coupling and brittle designs.
- Measure how many requests are pure pass-throughs (sinkholes). If a high percentage are sinkholes, reconsider the style (80/20 rule: some sinkholes acceptable; widespread sinkholes are a red flag).
- When growth or scalability becomes critical, consider migrating to more modular styles (service-based, microservices, event-driven, etc.).
Typical examples#
- Classic three-tier web app: browser (presentation) → application server (business + persistence) → relational database.
- Single WAR/JAR Java web app where UI, services, and DAOs are deployed as one artifact (monolithic layered app).
Quick checklist before choosing layered architecture#
- Is the project small or short-lived? → layered is a good fit.
- Do you need rapid, independent scaling of specific features? → layered may not be suitable.
- Can you maintain clear contracts and controlled access between layers? → if yes, layered can remain maintainable.