Architecture
Architecture is the part of software design concerned with module boundaries and the decisions that are hard to change — the system’s skeleton. Architecture is a subset of design; not all design is architecture.
The change-management criterion for module boundaries that distinguishes architecture from lower-level design is developed in the published paper on the Independent Variation Principle [1]. The criterion is the missing piece two design notions openly defer to. Cohesion is correctness relative to a partitioning rule, assessed as a purity-completeness pair per rule, so a cohesion judgment is only as definite as the rule behind it [2]. Coupling is access to a shared resource, and telling couplings a domain artifact mandates (essential) from the rest (accidental) needs a criterion grounded in the domain; without one, module boundaries are arbitrary [3]. The change-driver partition closes both gaps at once: grouping by the full change-driver set is the common refinement of the modularisation principles, so one partition answers to all of them together [2].
1 What architecture is
The usual answers describe the occupation, not the discipline. One says architecture is what architects do — an activity. Another says it is “the important stuff, whatever that is” [4] — a judgment, not a criterion. A third says it is the set of decisions that are hard to change — a cost correlate that misfires exactly where a criterion is needed. None of the three can say, for a concrete design question, whether the question is architectural at all.
The change criterion completes the significance answer instead of leaving it a shrug: “important” becomes definite once it is read as whatever materially shapes how the system varies under change. Significance is then a fact about the domain, not a consensus of experts.
One criterion does the classifying: derivability.
A question the design must answer is architectural exactly when the domain’s causal knowledge bears on the answer by restricting which answers the system may take.
The domain’s causal knowledge is the knowledge required to realize the system’s purpose within the obligations its governing artifacts impose — regulations, contracts, specifications, service-level commitments. Two separations carry the weight:
- Domain obligations are facts about the domain. The architect has no authority over them; the architect’s derivation is a fallible estimate of them.
- Machine and cost knowledge are not second sources of authority. They enter the derivation only through the obligations that depend on them: a latency SLA in the platform contract, not a taste for speed, forces the cache; a seven-year retention statute, not caution, forces the durable store.
The architecture of a system is then the set of its answers to architectural questions, together with their admissible sets. Given jointly satisfiable obligations, the criterion classifies each answer:
- Derivable core — the obligations admit exactly one answer. The design transcribes it; no selection occurs, because a decision is a selection from two or more admissible answers, and a singleton leaves nothing to select.
- Feasible region — the obligations admit several answers. Judgment operates here, and must be presented as judgment: reasoned, challengeable, never dressed up as necessity.
- Provisional — the available knowledge does not settle the admissible set. The gap is a defect to repair, not a preference to push through quietly.
- Infeasible — the obligations cannot be jointly satisfied. No realizable design exists, and the remedy is a governing act on the artifacts, not a design choice.
A payment system runs all four classes in one place. The acquiring contract requires settlement deduplication, and a seven-year tax statute makes that storage durable: derivable core, no design debate left. Confirmation by push or by polling admits several admissible answers: feasible region, and the choice is recorded as judgment. Whether capture must close within seven days is settled by no artifact at hand: provisional, a gap to repair. A new erasure duty within thirty days collides with the seven-year retention statute: infeasible, and resolved above the design when the statute prevails.
Checkability has a stated scope: the governing artifacts must be identifiable, the obligations expressed in them, and the knowledge required to realize the purpose within them available. Within that scope a third party can decide whether the derivation holds, given only the artifacts and the recorded material. Checkable does not mean true — a claim can be checkable and false — but it means the argument never rests on the architect’s private word.
2 The architect enables everyone else
Architecture is instrumental. It is a means to delivery, not an end in itself, and it is judged by whether it enables the delivery system around it to function. This is the central claim of the account:
Enablement. Every role the product’s obligations require — product managers, builders, testers, sponsors — must be able to do the job those obligations make necessary: with satisfying quality, in time, and in budget.
Three consequences follow:
- Enablement is a property of the whole delivery system, and the architect is answerable for it even though many hands achieve it. Which roles are necessary is itself derived: a role is necessary exactly when some obligation makes its work necessary. Both errors are derivation defects — omitting a role some obligation requires leaves work that must be done with no one accountable for it; inventing a role no obligation supports smuggles a preference into the delivery system under the name of architecture.
- The accountability is held by a single role. This is an organizational commitment, not something the criterion derives. The organization decides what fills the role — one individual architect, a team, or a committee whose members share the architecture tasks. Whoever fills it is answerable for the whole of enablement.
- The duty is dischargeable. One accountability, four duties: derive (identify the causal domain knowledge and extract the design from it), document (express the one derivation so each role can act on it), validate (check the built system against the recorded derivation), and re-examine (re-derive when the knowledge moves).
Why the role must exist at all has a structural answer. Apply the change criterion recursively to the organisation itself: modules sit in deployment units, deployment units in organisational domains, and at each level the units below become elements with their own change-driver structure. A team that applies the criterion flawlessly inside its own modules is blind to the level where its whole module is one element among many. Cross-team and cross-system drivers therefore have no owner at the team level. The failure looks mundane. A module set one team owns is legitimate: all coordination is internal. The day a second team takes authority over half of it, nothing in the domain changes, but internal coordination silently becomes inter-team coordination — interface contracts, synchronised releases, shared pipeline ownership. No team can see the misalignment from inside. The role exists to hold what no team can see: a system whose change drivers cross team or system boundaries needs an architect — not a decision-maker, but the reader and steward of the drivers no single team can see.
The role account also corrects Fowler’s aphorism that an architect’s value is inversely proportional to the number of decisions made [4]. That metric can only describe what a good architect avoids. The value is three positive readings: identify the change drivers; decide when a hard constraint — security isolation, regulatory separation, deployment topology, a real-time budget — should dominate the change-cost axis; and choose the tools whose constructs let the domain knowledge be embodied faithfully. The rest is read off the domain, not decided.
Enablement is not the satisfaction of every local preference. A tester’s wish to bypass an audit trail is a local preference when the domain forces the trail; the correct answer is no, together with a way for the tester to do the real job — verifying behaviour — within the constraint. Only a blockage the architecture produced, or could have removed at a cost the domain permits, counts against the architecture.
Two tests make the claim operational rather than aspirational:
- The documentation test. Documentation is one derivation expressed per audience, not a set of artifacts: milestones for product management, testable quality attributes for testers, contracts for builders, risk posture for the sponsor. Each role must be able to act on its view without interviewing the architect; under-documentation fails one way, and a view no required role consumes fails the other.
- The validation test. When something fails, the process must be able to attribute the failure to the derivation and not only to the builders. A validation process that can only ever blame the builders is quality theater: it performs assurance while protecting the one thing that most needs to be challengeable.
The failure test turns the definition into three checkable predicates, each with an observable condition:
- Blocking an artifact-derived job. A role cannot do the job its governing artifacts require because of a decision the causal knowledge does not admit.
- Incoherent combinations. Every choice is admissible alone, but combinations fail — either behaviourally (no single behaviour of the system can exhibit two answers together, such as synchronous fraud review against a one-second latency SLA) or in delivery (a decision taken to satisfy one role defeats the required job of another, such as an hourly data-funnel rebuild that blocks the daily regression run).
- Validation that attributes every failure to the builders. There is no recorded derivation to check the build against, or no step in the process that can blame the derivation.
Refusal follows the same pattern. The architect may refuse a demand that contradicts the derivable core, but only by showing why — citing the obligation the demand violates and the artifact that imposes it. An architect who cannot show why a demand violates the domain’s obligations has no authority to refuse it.
Re-examination closes the loop. The knowledge moves — an obligation is amended, a latency ceiling shifts, pricing changes — and every derivation built on it is in question. An architecture correctly derived from yesterday’s knowledge is today a derivation from a false premise, and it fails exactly as if it had been wrong from the start.
3 Architecture is derived, not designed
The account sharpens into a partition criterion, and the consequence is stark:
- A decision is architectural exactly when its answer constrains the assignment of elements to modules — the partition of the system into modules — and therefore, wherever module and team boundaries align, which future change-work falls to which team. A decision the causal knowledge forces but that determines only itself — which database is named, which integer width is used — is derived but not architectural.
- The class diagram is recovered, not designed. The classes, the coupling, the cohesion, and even the kind of relationship between two classes — parameter, association, or event — are transcribed from the domain’s temporal and identity semantics. Where the shape varies across developers, the variation traces to a convention the language underdetermines, not to a choice over the structure of knowledge.
- Modularisation is derived too: the objective it serves is itself domain knowledge, read from the domain’s economics, and the cost-minimising partition is read off the forcing conditions. That the partition minimising change propagation minimises lifetime maintenance cost is a proved result, not a preference [5]; the optimal modularization is derivable from coupling [6], and the partition it produces is the change-driver partition [1] — the common refinement of the modularisation principles, so one decomposition answers to all of them at once [2].
- Most apparent trade-offs dissolve once demands carry numbers and scopes. The irreducible remainder is resolved by a business commitment made above the system, not by the architect: the architect surfaces the conflict with its prices attached, and stops.
Within the design there is no choice: only the value choice above the system and the reading beneath it remain. The value choice has a number attached and is made above the design — committing to one card scheme’s fees over another’s, or accepting a 200 ms p99 to halve infrastructure cost. Everything else is arithmetic, and arithmetic does not have taste.
4 Styles assume; the domain decides
Read as hypotheses about which parts change for different reasons, the styles get a uniform diagnosis. Each style fixes a structural proxy — rings, layers, slices — and succeeds where the proxy tracks the domain’s actual variation. Where it does not, the style fails silently: nothing in the diagram tells you the assumption broke.
The shared prescription behind the core-protecting styles — that business logic can always be made independent of infrastructure — does not always hold. Achievability is a structural property of the domain. Where the domain’s drivers require infrastructure-level knowledge, no reformulation of the domain eliminates that knowledge, enforcing the style forces a falsified model, and abstraction that removes load-bearing drivers is domain substitution, not purification. A pricing module whose rounding rules a tax statute fixes shows the substitution: route the statute’s rounding into an infrastructure adapter, and the adapter now embodies domain knowledge wherever the diagram places it. What counts as infrastructure is relative, too — a payment processor is infrastructure to a client system, and a first-class, regulation-driven domain to its own operators. The practical test is driver completeness: after the abstraction, are all original drivers still represented and independently testable?
Clean Architecture decomposes into a partition criterion (group by ring role) plus a dependency-direction constraint. The partition criterion diverges from the optimal partition whenever ring role does not track the change drivers [1], and stability by ring position corrupts the stability ordering, because genuine stability is a property of an element’s governing authorities, not its ring membership. The conclusion is not to apply the rings more carefully, but to apply the change-driver partition directly and invert dependencies only where the domain grants substitutability.
Boundary ownership has its own grammar: who controls an interface specification, who implements it, and who uses it. Of the ownership configurations that grammar allows, three are stable — bilateral control, provider-driven control, shared governance; four degenerate to simpler forms; two are structurally contradictory.
Architecture Styles examines the styles one at a time: Hexagonal Architecture, Onion Architecture, Clean Architecture, Layered Architecture, and Vertical Slice Architecture. Each asks whether the style embodies the domain’s knowledge or invents structure the domain never mandated.
5 Splitting services trades a coupling space, it does not shrink one
The monolith-to-services split has a reputation for reducing coupling, and a habit of disappointing it. The analysis:
- Coupling is access to a shared resource, and it does not depend on where the elements run [3]. A split therefore cannot remove coupling in general; what it does is replace one kind of coupling space with another.
- The co-location family — shared mutable state, implicit initialisation order, cache and configuration bleed, concurrency, shared transactions — is unbounded, bespoke to each system, largely written nowhere, and therefore unmanageable.
- The remote-deployment family a boundary installs is short, fixed, and manifest by construction: latency, availability and partial failure, serialisation and versioning, delivery and ordering, consistency, transport security, discovery, and boundary observability. It is handled largely by organisational discipline — timeouts, retries, idempotency, contract tests, service-level objectives — with a small named residue of genuine technical complexity, consistency above all.
- Coupling grounded in what two sides share, not where they run, survives any seam. The coupling paper names it essential: a domain artifact — a statute, a contract, a standard — requires the elements to share the resource, so no deployment can remove it [3]. Where a seam strands such a genuinely-shared resource across the boundary, the split adds the fixed remote set on top of the surviving domain-imposed coupling [7]: the distributed monolith, which is not a botched decoupling but the predictable cost of a seam that ignores the shared-resource structure. The canonical case is two services and one database: the seam splits the code, but both sides still write the same orders table, so every schema change now crosses the very boundary the split was meant to remove.
- Because one side’s coupling is invisible and never priced while the other’s is tangible and fully counted, the choice cannot rest on a cost estimate. It rests on the preconditions: whether a favourable seam exists, whether what crosses it is thin, and whether the organisation can bear the fixed remote set.
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
- On the Nature of Coupling: All Coupling as Shared Resource Access — Zenodo, 2026 — doi:10.5281/zenodo.21925122
- Why Minimizing Change Propagation Minimizes Maintenance Cost — Zenodo, 2026 — doi:10.5281/zenodo.21362542
- A Self-Contained Derivation of the Optimal Modularization from Coupling — Zenodo, 2026 — doi:10.5281/zenodo.21925268
- Coupling as a Consequence of Cohesion: Decomposition, the Coupling Floor, and Domain-Imposed Coupling — Zenodo, 2026 — doi:10.5281/zenodo.21925201