Layered Architecture

Definition

Presentation, application, domain, persistence — each layer depending only on the one beneath it. The load-bearing property is not the layering; it is the enforced dependency direction, which means a change in storage cannot propagate upward into the domain.

Why it matters

It is the most widely understood structure in software, so a new engineer is productive on day one. That is a genuine and undervalued architectural quality. It also makes the most common change — swapping a technical detail such as a database driver or a template engine — local.

When it works well

Systems whose complexity is genuinely technical rather than domain-driven; CRUD-heavy applications; teams where consistency across many similar modules matters more than optimality in any one.

Failure scenarios

• The pass-through layer. A layer that exists because the diagram had a box, and does nothing but forward calls. Pure latency, pure maintenance, and it will outlive everyone who remembers why it is there.
• Layers confused with tiers. Layers are logical; tiers are physical. Deploying each layer as a separate process because they are drawn as separate rectangles converts local calls into network calls and gains nothing.
• The domain depending on persistence. Once entities are ORM classes carrying database concerns, the dependency direction has inverted and the layering is decorative. This is what hexagonal and clean architecture exist to prevent.
• Change spread across all layers. If every feature touches all four layers, the layering is cutting across the axis of change rather than along it. That is the argument for organising by feature or capability first, and layering inside each.

Industry parallel

Large enterprise platforms — the kind Microsoft's enterprise guidance addresses — remain predominantly layered, and mostly for organisational reasons: a layered structure is legible to many teams, auditable, and maps onto specialised skills. The pathology in that setting is layer-shaped teams, which turn every feature into a multi-team negotiation and cement the problem via Conway's Law.

Trade-offs

You gain comprehensibility, substitutability of technical details, and easy onboarding. You pay in indirection, a tendency to anaemic domain models, and structural bias against features that naturally cut across layers. For most systems, most of the time, it remains the correct default — and the correct default is worth defending against more fashionable alternatives that cost more than the problem does.

Interview question

"When does a layered architecture actively mislead you, and what would you use instead?"