Layered architecture is the classic way to separate concerns. What are its rules and its failure modes, and when would you separate by feature slice instead of by technical layer?

## What layering is **Layered (n-tier) architecture** partitions a system by technical role: 1. **Presentation / API** — HTTP controllers, UI, serialization, request/response models. 2. **Application / use-case** — orchestration, transaction boundaries, authorization entry points. 3. **Domain** — entities, value objects, business rules and invariants. 4. **Infrastructure / persistence** — database access, message brokers, external HTTP clients, file systems. Two rules make it separation rather than decoration: - **Directed dependencies.** A layer may depend only on the layer(s) below (classic) or only inward (hexagonal / ports-and-adapters / clean architecture). No cycles, no upward references. - **Contracts at the boundary.** Each layer exposes an interface; internals stay private. In the inward-dependency variants, the domain defines *ports* (interfaces) and infrastructure supplies *adapters*, so the compile-time dependency points from infrastructure to domain — **dependency inversion**. That is what makes the domain testable without a database. A further distinction: **open vs. closed layers.** In a closed layered architecture every call passes through each layer in order (better isolation, more pass-through code); open layers permit skipping (less ceremony, weaker isolation). Choose deliberately and state the rule — an undocumented mix decays fast. ## What layering buys - Replaceable I/O: change ORM, database, or transport with contained edits. - Fast tests: domain logic runs in memory. - Uniform placement rules — newcomers know where code goes. - A natural home for cross-cutting concerns (transaction boundary at the application layer, authn at the presentation edge). ## Failure modes (what interviewers want) ### 1. Pass-through / "lasagna" layers Every layer's method does `return next.doTheSameThing(args)`. The indirection buys nothing and multiplies files. Symptom: a service class with only single-line delegations and a mapper that copies identical fields. Remedy: collapse the layer, or justify it with an actual transformation/policy it applies. ### 2. Change amplification Adding one field touches: API DTO → validation → mapper → application command → domain entity → persistence entity → mapper → migration → test fixtures. If the vast majority of your changes are feature-shaped and each one hits every layer, then your separation axis is orthogonal to your change axis. This is the strongest empirical argument for vertical slicing. ### 3. Leaky layers The domain imports ORM annotations; controllers receive entities and trigger lazy loading during serialization; UI paging is expressed in SQL `OFFSET`. The layer boundary exists syntactically but the concern crossed it. Detect with dependency rules enforced in CI (import checks, ArchUnit-style tests, module systems, linters). ### 4. Skipped layers / cycles A controller calling a repository directly "just this once". Without automated enforcement, that becomes the norm and the architecture is documentation only. ### 5. Anemic domain All behavior lives in "services", entities are field bags. Technically layered, but the domain concern isn't actually separated — it's scattered across procedural service classes. ### 6. Layers as team boundaries A UI team, a backend team and a DBA team means every feature needs three teams and three handoffs — Conway's Law working against you. Cross-functional teams owning vertical slices deliver features independently. ## Vertical slicing / feature-based separation Organize top-level modules by **business capability** — `orders/`, `billing/`, `catalog/` — each containing its own controller, use cases, domain and persistence. Related ideas: package-by-feature (vs package-by-layer), modular monolith, bounded contexts in Domain-Driven Design, and the Common Closure Principle: *classes that change together belong together.* Benefits: a feature change lives in one directory; slices can be extracted into services later; ownership maps to teams; deletion of a feature is a directory delete. Costs: shared concepts risk duplication across slices; you need explicit rules for cross-slice communication (public API per module, events, no reaching into another slice's internals — enforceable with module systems or architecture tests); and the boundaries are harder to draw correctly early. ## The usual synthesis Slice **vertically by capability at the top level**, and layer **inside each slice**. You then get both separations along the axes that matter: features change independently of each other, and within a feature the domain rule stays independent of transport and storage. Keep genuinely shared kernel code small and explicitly shared. ## Deciding: questions to ask - Look at the last 50 commits: do they cluster by feature or by layer? Separate along the dominant clustering. - Which is more likely — replacing the database, or shipping a new feature this quarter? Optimize for the frequent case. - How many teams touch this codebase, and along what lines? - Is any layer purely mechanical? If it never applies a policy or transformation, it is overhead. - Are the layer rules enforced automatically, or aspirational? Unenforced boundaries erode.