Vertical Slice Architecture
Vertical slice architecture organises code by feature or use case. Each slice runs end to end for one operation — request, validation, business rules, persistence — and slices do not share layers. There is no horizontal business layer; each slice holds what its operation needs. Bogard presents it as a response to the cross-layer editing that layering forces for a single feature [1].
So the question is not whether it admits to being a design. It does. 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 layered architecture, onion architecture, and hexagonal architecture: does the domain’s change-driver structure mandate the cut?
1 At a glance
| Underlying principle | Succeeds when | Fails when |
|---|---|---|
| Slices group elements end to end by feature or use case. | Each feature carries its own change driver and no rule crosses features. | A cross-cutting change driver (tax, audit, authorisation) reaches every slice. |
2 The claim
A slice is a feature. “Place order,” “issue refund,” “cancel subscription”: each is a slice, cut end to end through request handling, rules, and storage. The claim is that a feature change stays inside its slice. Slices do not depend on one another.
3 Slices divide by feature or use case
Slicing’s axis is the feature or use case. Elements are grouped by which operation they serve.
This axis is closer to the domain than the rings of onion or clean, because an analyst names operations. Where a use case is a change-driver class, the slice coincides with the partition. The axis fails when a change driver spans features. IVP groups by which change activates an element; a rule that applies to every order — currency handling, tax, authorisation, audit — is one change driver, and it reaches every slice that processes an order [2]. So the feature axis is a proxy. It can coincide with the partition, when each feature carries its own change driver; it does not determine it.
4 The slice is not in the domain’s analysis
A business analysis names use cases, processes, and capabilities. It does not organise knowledge as slices of code that each own a request handler and a persistence path. The use case is in the analysis; the slice is the code that encodes it. The end-to-end code unit — the thing that bundles one operation’s request, rules, and storage — appears when a designer lays out code; it is an encoding. This is the distinction the style blurs: the axis is domain-near, the code form is not. Absence of the code form from the analysis is evidence, not the test; the test is coincidence with the partition.
5 A feature is not independent of the others
Vertical slicing’s strongest claim is that each feature changes independently. That is a claim about change. A slice exists to contain a feature’s change, so the coupling at issue is change coupling.
Under the framework’s reading, a cross-cutting rule drives every slice together: change the tax rule, and every slice that computes tax changes. Then the shared change driver reaches across slices, and each slice holds its feature change driver plus the shared rule’s change driver — two assignment sets where the slice wanted one. Each slice that must carry the shared rule becomes impure, and the shared rule’s class is scattered across slices — a Unit Completeness failure. The feature is independent only when no change driver crosses slices. That is the style’s hidden hypothesis: that the feature is the whole of its elements’ change story.
6 What vertical slicing embodies, and what it invents
Two parts are worth separating.
- The slice boundary is a claim about the cut. When its axis — the use case — is a change-driver class, the cut is domain-near: the business names the operation, and the slice follows it. That is the closest any style on this site comes to the partition, because the analyst already thinks in operations.
- The assumption that the feature is the only change driver is the invention. A slice asserts that its feature is the whole of its elements’ change story. Where a cross-cutting change driver exists, the assertion is false, and the slice invents a unity — a feature boundary the domain does not have.
The general criterion applies. 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 slice is such an invention exactly when it does not coincide with a change-driver class. If the slice groups elements with different change-driver assignments — its feature’s change driver plus a shared rule’s — it invents a unity; if its boundary separates elements with the same assignment, it invents a division. Only a slice that coincides with a Γ-equivalence class is not an invention, and then it is a redundant name for a real class.
By IVP’s foundational claim, the change-driver partition is the domain’s only organising knowledge [2]. Faithfulness admits no concept that does not correspond to a Γ-equivalence class; any structure beyond the partition is deviation, and deviation is the accidentality.
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 vertical slices, arrives at the partition. She groups by what changes together. A slice per operation follows only where the operation is itself a change-driver class — which the analyst’s use cases sometimes are and sometimes are not.
Non-spontaneity is evidence, not proof. The slice’s axis is domain-near, so vertical slicing is the style most likely to coincide with the partition — and the one whose failure is most instructive where a cross-cutting change driver breaks the coincidence. 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 [2]. Judged by that standard, a slice is correct where no class straddles it and no two non-equivalent elements are grouped — that is, where its feature is the sole change driver of its elements.
Where a cross-cutting rule is present, it is not correct: the shared change driver makes each affected slice impure and scatters the shared rule’s class across slices — a Unit Completeness failure. Off the partition, the decomposition is wrong under the change-driver criterion.
9 When vertical slicing 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 [3]. The claim is a re-description, not a proof that no other kind of principle exists. So vertical slicing answers to one decomposition, not one per concern.
Vertical slicing does no harm only where its slices coincide with that decomposition. Where they do not — where a change driver crosses slices — every change crosses a boundary the domain did not set: each slice groups non-equivalent elements, and the shared rule’s class is scattered.
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 [4]; 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 [3]. A concern left out of the model is a requirements gap, not a cohesion judgement.
Beneficial, here, means only that vertical slicing does no harm: its slices coincide with the change-driver decomposition. It still adds no decomposition of its own. Outside the band, vertical slicing is harmful wherever its slices 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 [3].
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 slice can be placed exactly right and still compute a rule with the wrong formula.
Vertical slicing can clear placement and fail this. Nothing in a slice checks whether the code realises the knowledge it carries, and the slice diagram looks the same.
Vertical slicing is fully sound only when it clears every bar: its slices 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
- Vertical slice architecture organises code end to end by feature or use case; slices do not share layers. Its stated axis is the feature.
- The axis is domain-near: analysts name operations, so a slice frequently coincides with the partition.
- It fails under a cross-cutting change driver: one shared rule reaches every slice, making each impure and scattering the rule’s class (a Unit Completeness failure).
- The use case is in the analysis; the end-to-end slice is the code form of it, an encoding.
- Where the slices coincide with the partition, vertical slicing adds nothing; where they do not, it invents structure the domain did not mandate.
- The strongest defensible claim: vertical slicing’s slices are invented concepts except where they coincide with the partition. Its decomposition value is the partition, which one can obtain without it.
- Vertical slicing does no harm only where its slices 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 layered 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