Layered / N-Tier Architecture

Layered architecture organizes code into horizontal layers — commonly presentation, application/domain, and data access — with a dependency rule that higher layers call lower layers, not the reverse. N-tier often maps those layers to separately deployable tiers (browser, app servers, database).

It is widely taught and easy to explain. It helps when teams need clear technical separation and auditability. It hurts when business complexity is the main problem and layering becomes ceremony that scatters domain logic.

Classic strict layering sometimes collapses domain into "services" that are anemic — entities as data bags, logic in service classes. Prefer keeping invariants in the domain model when complexity warrants it.

• Dependencies point inward/downward: UI → application → domain ← infrastructure adapters.
• Lower layers must not import UI types.
• Domain must not import ORM annotations if you want framework independence (hexagonal strengthens this).
• Cross-cutting concerns (logging, auth) via explicit mechanisms — not random imports upward.

• Domain is complex — horizontal slices scatter a single business change across many folders.
• Every feature requires touching all layers mechanically (pass-through methods with no logic).
• Layers become dumping grounds ("UtilService", "CommonManager").
• Physical N-tier distribution without need adds latency and failure modes.

• Keep validation of business invariants in domain, not only controllers.
• Do not let controllers access repositories directly if you need a use-case boundary.
• Combine with vertical modules: layered inside each module, not one global layer cake.
• Enforce with lint/arch tests.
• Document the dependency rule in an ADR.

Logical layers need not map 1:1 to network tiers. Many systems keep presentation+application+domain in one process and treat DB as the second tier. Adding tiers requires requirements: separate scale, separate security zones, or separate teams managing each tier.

Controllers should translate and authorize at the edge, then call application use cases. Repositories encapsulate queries. Domain objects enforce invariants. DTOs crossing layer boundaries prevent leaking persistence models to APIs.

Many codebases start layered and grow painful. Evolve by introducing vertical modules while keeping layers inside each module — a modular layered monolith. Alternatively, push toward hexagonal ports at the domain boundary when framework coupling hurts.

• Identify the hottest change sets that touch every layer — candidates for module extraction.
• Introduce interfaces at infrastructure boundaries incrementally.
• Delete pass-through services that add no policy.
• Add archunit/dependency rules before large refactors so regressions fail CI.

The same flow in a poorly layered system often has SQL and pricing math inside the controller — fast to write, expensive to change safely.

Write an ADR when you choose layered as the house style so newcomers know the dependency rule and where business logic must live.

Pure layering organizes by technical role; modular monoliths organize by business capability (with optional layers inside). Large products usually need both: capabilities as the primary cut, layers as the secondary cut.

Layered architecture pairs well with onboarding checklists and code review rubrics ("which layer does this belong in?"). In Agile teams, still deliver vertical slices — implement across layers per story rather than finishing the data layer for all features first (a Waterfall trap inside an Agile calendar).

Next: Hexagonal. Also Modular Monolith.