Cohesion is usually taught at class level. How does the same principle drive boundaries at module, service and team scale, and what happens when those boundaries are drawn on the wrong criterion?

## Cohesion is scale-free The same question — *do these things belong together?* — repeats at every level: | Unit | Cohesive when… | |---|---| | Statements in a method | they perform one step of one task | | Methods in a class | they serve one purpose / one reason to change | | Classes in a package/module | they change together for the same reason | | Modules in a service | they belong to one business capability | | Services in a platform | each is independently deployable and owned | What changes with scale is the **cost of getting it wrong**. A badly split class costs you a refactor in an IDE. A badly split *service* costs you a distributed transaction, a network hop on the hot path, cross-team release coordination, and possibly a data migration to fix. ## The named principles at module scale - **Common Closure Principle (CCP)** — "gather into a component classes that change for the same reasons and at the same times." This is literally SRP/cohesion for components, and it is the primary cohesion criterion above class level. - **Common Reuse Principle (CRP)** — "classes that are used together are packaged together; don't force consumers to depend on things they don't use." CCP and CRP *pull against each other* (CCP grows components, CRP shrinks them), together with the Reuse/Release Equivalence Principle; Martin's "tension diagram" says you deliberately favour CCP early (change is frequent, reuse is speculative) and shift toward CRP as a component matures. - **Bounded Context (DDD)** — a boundary within which a domain model and its ubiquitous language are consistent. Two contexts may both say "Customer" and mean different things; forcing one shared model across them is a cohesion failure that produces a model nobody can change safely. - **Conway's Law / Inverse Conway Manoeuvre** — system structure mirrors communication structure. A boundary that does not match team ownership will be crossed constantly by coordination; teams either route around it or the boundary erodes. ## The classic wrong criteria 1. **By technical layer.** Services named `web-api`, `business-logic`, `data-access`. Every feature — "add a discount field" — touches all three, so nothing can ship independently. High *technological* similarity, zero *change* cohesion. 2. **By entity/table.** A service per database table (`customer-service`, `address-service`) fragments a single business capability into chatty pieces that must be updated together, usually with a shared database underneath. 3. **By reuse fantasy.** A "common" or "shared-lib" component that everything depends on becomes a coincidental-cohesion bucket at platform scale: every team changes it, every change forces everyone to re-release, and its release cadence throttles the whole organization. 4. **By org chart accident** rather than capability, freezing a temporary team structure into the architecture. ## The failure mode: the distributed monolith Symptoms: coordinated/lock-step releases across services; a change to one feature requiring PRs in several repos; synchronous call chains several hops deep on a single user request; distributed transactions or sagas introduced to restore invariants that a wrong boundary broke; a shared database schema several services write to; shared DTO libraries versioned in lock-step. You paid all the costs of distribution (network failure modes, partial failure, operational overhead, eventual consistency) and kept all the costs of a monolith (coupled releases). Almost always the cure is to *move the boundary* — merge services back and re-split along capability lines — rather than to add more integration machinery. ## Measuring cohesion at this scale - **Temporal / logical coupling from version control**: how often do commits touch component A and component B together? Persistent co-change across a boundary means the boundary is in the wrong place. - **Cross-boundary call fan-out per user request**: many hops for one business operation implies a capability split across components. - **Release coupling**: number of components that must be deployed together to ship one feature. The single most damning metric. - **Ticket/epic spread**: how many components a typical feature ticket touches. - **Ownership diffusion**: number of teams committing to one component. ## Trade-offs a principal is expected to raise - **Cohesion boundaries are guesses about the future.** You are betting on which things will change together. Where the bet is uncertain, prefer a *modular monolith* — enforce module boundaries in-process (build-level dependency rules, architecture tests) so the boundary is cheap to move — and extract a service only when a boundary has proved stable and there is an independent reason (scaling, isolation, team autonomy, compliance). - **Some duplication beats wrong cohesion.** Two contexts with superficially identical models are often better off with separate models plus an anti-corruption layer than with one shared model that neither can evolve. - **Sequencing.** Boundary changes at this scale are expensive; prioritize with hotspot and co-change data, and do them one seam at a time behind stable interfaces. - **The organizational half.** Redrawing a service boundary without redrawing ownership just relocates the coordination cost. Boundary, code ownership, on-call, and roadmap should coincide.