Layered Architecture
Layered architecture — the classic horizontal, or “N-tier,” style — divides the system into horizontal layers by technical role: presentation, application or business logic, and persistence or data access. Each layer calls the layer beneath it; the call graph descends. A common discipline forbids skipping a layer: the presentation layer reaches the database only through the business layer.
The style has no single author. It is the default arrangement of a great many systems, taught as the natural way to separate a user interface from business logic from storage. So the question is not whether it admits to being a design. It is the commonest one. The question is which parts of it embody the domain’s knowledge and which parts it invents.
This page applies the same test used for onion architecture, clean architecture, and hexagonal architecture: does the domain’s change-driver structure mandate the cut?
1 At a glance
| Underlying principle | Succeeds when | Fails when |
|---|---|---|
| Layers group elements by technical role: presentation, business logic, persistence. | Each change is confined to one layer. | A single change driver crosses layers — a rule edit touching presentation, logic, and persistence. |
2 The claim
The layers are technical roles: presentation (controllers, views), application (coordinating logic), business logic, and persistence (repositories, data access). Each layer depends on the layer below it. The claim is that a change to a technical concern stays within its layer: a change to the interface touches presentation, a change to storage touches persistence.
3 Layers divide by technical role
Layering’s axis is technical role. Elements are grouped by what they technically are — a controller, a service, a repository — not by what they change for. The rule that fixes the depth is a direction claim: each layer calls the one below.
IVP does not group by technical role; it groups by which change activates an element. Technical role and change-driver class are different axes [1]. A business rule and its persistence code may share a change driver while sitting in different layers; a controller and a repository may share nothing. So layering’s stated axis — presentation versus logic versus storage — is a proxy. It can coincide with the partition, when a domain’s change drivers happen to be technical; it does not determine it.
4 The layers are not in the domain’s analysis
No business analysis or functional analysis organises knowledge as presentation, business logic, and persistence. Analysis names capabilities, processes, rules, entities, and decisions. It does not name “the controller layer” or “the data-access layer.” Those categories appear when a designer lays out code; they are a technical encoding. Absence from the analysis is evidence, not the test; the test is coincidence with the partition.
5 A layer is not independently replaceable
Layering’s strongest claim is replaceability: swap the database layer, or the presentation layer, and the others stand. That is a claim about the direction of reference. Layering exists to isolate change — a technical change stays in its layer — so the coupling at issue is change coupling.
Under the framework’s reading, a single business-rule change commonly drives the controller, the service, and the repository together: the rule is edited, its endpoint changes, its stored form changes. Then those elements carry the same change-driver assignment, and the layer boundaries run through one Γ-equivalence class. Each boundary that separates them splits a class — a Unit Completeness failure. The rule is scattered across layers, and the change must cross every boundary between them. Replaceability holds for the layer’s mechanism; it does not hold for the rule.
6 What layering embodies, and what it invents
Two parts are worth separating.
- The descending dependency rule is a claim about direction, not about the cut. Direction is domain-determined only where the domain itself orders the elements: where one element’s requirement is chosen to satisfy another’s. Layering’s rule points every dependency down, whether or not the domain orders them that way. Where they align, the rule adds no structure; where they do not, it asserts a direction the domain does not have.
- The layers are a claim about the cut. Presentation, business logic, persistence: the stratification is not in the analysis.
A representation is unavoidable. What is not unavoidable is inventing a concept — a named kind, boundary, or category — that the knowledge does not contain. A layer is such an invention exactly when it does not coincide with a change-driver class. If the layer groups elements with different change-driver assignments, it invents a unity; if its boundary splits elements with the same assignment, it invents a division. Only a layer that coincides with a Γ-equivalence class is not an invention, and then it is a redundant name for a real class. Layers rarely so coincide, because a domain’s rules do not divide by technical role.
By IVP’s foundational claim, the change-driver partition is the domain’s only organising knowledge [1]. Faithfulness admits no concept that does not correspond to a Γ-equivalence class; any structure beyond the partition is deviation, and deviation is the accidentality. Layering’s layers are that deviation: the business layer usually holds rules with several distinct change drivers, and its boundary separates each rule from the persistence code that shares the rule’s change driver.
7 The split is not the style
The proof is in the artifacts. Grouping by change driver yields the partition; an engineer who embeds the domain faithfully, and who has never heard of layering, arrives at the partition. She may separate concerns — interface, logic, storage — because that is a natural impulse, but the strict layer discipline, each layer calling only the one below, is a convention. She groups by what changes together, not by what an element technically is.
Non-spontaneity is evidence, not proof, that a structure is a convention and not knowledge. Layering fails wherever a layer straddles a Γ-equivalence class — the ordinary business-rule feature, for example. The encoding is the designer’s, the partition is the domain’s.
8 The IVP account
IVP groups elements by change-driver assignment: elements with the same assignment belong together. A module is pure when all its elements share one change-driver assignment set [1]. Judged by that standard, layering’s layers are correct where no class straddles them and no two non-equivalent elements are grouped.
For the ordinary feature, they are not correct; off the partition, the decomposition is wrong under the change-driver criterion.
9 When layering is beneficial, and when it is harmful
The theory is not maintenance-only. Each concern the system must respect — logical structure, security, deployment, platform, a latency budget — is, once modelled as knowledge governed by change drivers, a partitioning rule over the same element set. IVP is one such principle, and not the only one: grouping by the full change-driver set (Γ-equivalence) is the common refinement of the concerns’ rules, correct under every one at once [2]. The claim is a re-description, not a proof that no other kind of principle exists. So layering answers to one decomposition, not one per concern.
Layering does no harm only where its layers coincide with that decomposition. Where they do not, every change crosses a boundary the domain did not set: a class split across layers scatters one change, and a layer that groups non-equivalent elements couples what the domain keeps apart.
Two caveats bound the claim. The cost model is separate, and it models maintenance cost: the partition minimises total maintenance cost under the coefficient condition the model states, unconditional only in the pure, disjoint change-driver case [3]; whether the metric matches real economic cost is empirical. And the theory does not discover the rule: identifying the domain conditions and building the partition is a separate domain-analysis task [2]. A concern left out of the model is a requirements gap, not a cohesion judgement.
Beneficial, here, means only that layering does no harm: its layers coincide with the change-driver decomposition. It still adds no decomposition of its own. Outside the band, layering is harmful wherever its layers do not coincide with the partition.
10 Beyond placement: faithful embodiment
The theory separates three properties: placement — the right knowledge in the right modules — which is what cohesion measures; faithful embodiment — each piece realised as it requires; and dependency parsimony — the dependencies are the ones the purpose requires. The three are independent [2].
Correctness is the second alone. A system satisfies an obligation exactly when every knowledge piece the obligation constrains is correctly embodied by some element; placement does not enter. So cohesion governs the cost of achieving and maintaining correctness — the scope to read and the radius to change — not whether it holds. A module can be placed exactly right and still compute a rule with the wrong formula.
Layering can clear placement and fail this. Nothing in a layer checks whether the code realises the knowledge it carries, and the layer diagram looks the same.
Layering is fully sound only when it clears every bar: its layers coincide with the change-driver decomposition, and the code realises the domain’s knowledge faithfully. Alignment without embodiment is a system placed correctly and still wrong about its domain.
11 Summary
- Layered architecture divides the system into horizontal layers by technical role, each calling the one below. Its stated axis is technical role.
- IVP does not group by technical role; it groups by change driver. The role axis is a proxy.
- The layers — presentation, business logic, persistence — appear in no analysis artifact.
- A layer is not independently replaceable: under the framework’s reading, a rule and its persistence code carry the same change-driver assignment, so the layer boundaries split one class (a Unit Completeness failure).
- Where the layers coincide with the partition, layering adds nothing; where they do not, it invents structure the domain did not mandate.
- The strongest defensible claim: layering’s layers are invented concepts except where they coincide with the partition. Its decomposition value is the partition, which one can obtain without it.
- Layering does no harm only where its layers coincide with the change-driver decomposition; it is harmful where they do not. Placement is not faithful embodiment.
- IVP is one modularising principle among those the system’s concerns induce; Γ-equivalence is the common refinement of them. The theory is a re-description, not a proof that no other kind of principle exists.
Compare vertical slice architecture, which cuts the other way, and hexagonal architecture.
Back to the verdict ledger.
The formal development. The definitions, theorems, and proofs behind this page are published in:
- The Independent Variation Principle — Zenodo, 2026 — doi:10.5281/zenodo.20794332
- On the Nature of Cohesion: Cohesion as Correctness Relative to a Partitioning Rule — Zenodo, 2026 — doi:10.5281/zenodo.21703193
- Why Minimizing Change Propagation Minimizes Maintenance Cost — Zenodo, 2026 — doi:10.5281/zenodo.21362542