Layered Architecture

Definition

The layered (n-tier) architecture organises code into horizontal technical layers — typically presentation, business, persistence, and database. Each layer has a specific technical role, and requests flow downward through the layers.

Also known as: n-tier architecture, multi-tier architecture.

The layered style is the natural outcome of technically-partitioned organisations (Conways Law): UI developers, backend developers, rules developers, and DBAs map directly to the four standard layers. This is why it is the most common "accidental architecture" — teams that don't consciously choose a style tend to produce this one. (→ Fundamentals Of Software Architecture)

Topology

┌─────────────────────────┐
│    Presentation Layer   │  (web/API, UI)
├─────────────────────────┤
│    Business Layer       │  (domain logic, rules)
├─────────────────────────┤
│    Persistence Layer    │  (ORM, data access)
├─────────────────────────┤
│    Database Layer       │  (SQL/NoSQL)
└─────────────────────────┘

Closed layers: a request in the presentation layer must pass through every layer below it in order. Enforces the layers of isolation principle — each layer is isolated from all layers except its immediate neighbours. This allows any layer to be replaced without impacting others (e.g., swapping JSF for React.js without touching the business layer), provided contracts between layers remain unchanged.

Open layers: a layer can be bypassed. Used for shared services, e.g., a shared utilities layer with audit/logging classes that any layer can call directly. Without an open layer, the business layer would need to route through the persistence layer to reach such utilities — unnecessary coupling. Failing to document which layers are open vs closed produces brittle, tightly coupled systems.

Architecture sinkhole anti-pattern: requests pass through every layer as simple pass-throughs with no business logic performed — pure object instantiation and forwarding with no added value. This wastes memory and degrades performance. Heuristic (the 80–20 rule): if ≤20% of requests are sinkholes, acceptable. If 80%+ are sinkholes, the layered architecture is wrong for this problem domain or all layers should be made open. (→ Fundamentals Of Software Architecture, Software Architecture Patterns)

The historical fast-lane reader pattern (early 2000s) allowed the presentation layer to bypass intermediate layers for simple data retrieval — a pragmatic workaround for the sinkhole problem, at the cost of isolation.

Physical Deployment Variants

Three variants are common:

1. Presentation + business + persistence in one deployment unit; database layer as an external database.
2. Presentation in its own deployment unit; business + persistence combined; separate external database.
3. All four layers in a single deployment (including an embedded or in-memory database) — common for on-prem products delivered to customer sites.

When to Use

• Small, simple applications with a single domain and a limited team.
• Budget-constrained projects needing the simplest possible architecture.
• Systems where time-to-market is secondary to low operational complexity.
• Brownfield migration starting point — legacy systems most commonly use this style.
• As a starting point while evaluating whether a different style is needed. If beginning as layered while assessing microservices, keep inheritance shallow and reuse minimal to preserve the ability to migrate. Do not let the layered structure calcify.

Architecture Characteristics Ratings

Trade-offs

Strengths:

• Extreme simplicity — universally understood by developers.
• Lowest initial cost — no infrastructure complexity.
• Good starting point for applications that may not need to scale.

Weaknesses:

• The architecture by implication and accidental architecture anti-patterns: teams that don't consciously choose a style produce layered architecture by default. Conway's Law reinforces this — technically structured organisations naturally build technically partitioned systems.
• Technical partitioning → changes to any business feature touch all layers → low agility.
• Cannot support differing architecture characteristics for different domains — the entire system shares one set of operational requirements (single Architecture Quantum).
• The architecture sinkhole anti-pattern erodes performance.
• High MTTR: startup times of 2–15 minutes for large layered monoliths mean every incident has extended downtime. (→ Fundamentals Of Software Architecture)

Quanta

Single quantum. All components share a single deployment boundary and a single set of architecture characteristics.

Partitioning

Technical (see Technical Vs Domain Partitioning).

How Different Sources Treat It

Related Pages

• Technical Vs Domain Partitioning — layered is the canonical technically-partitioned style
• Architecture Characteristics — layered scores lowest on most modern characteristics
• Architecture Styles Comparison — side-by-side with all other styles
• Service Based Architecture — a practical evolution of layered for teams wanting more agility without full microservices complexity
• Model Driven Design — Evans' binding principle; layered architecture is the structural prerequisite for MODEL-DRIVEN DESIGN
• Ports And Adapters — the DDD alternative for core subdomains; inverts the dependency direction layered architecture relies on
• Business Logic Patterns — layered fits transaction script and active record; ports and adapters fits domain model
• Mvc Web Presentation — MVC, Page Controller, Front Controller: the presentation layer patterns that sit at the top of a layered architecture
• Architecture Styles — overview and decision guide for all architecture styles