At architecture scale, how do you decide where module or service boundaries go using cohesion and coupling — and when is accepting tighter coupling the right call?

## The question a boundary answers A boundary is a bet: *changes will be more likely to stay inside it than to cross it.* Get it right and features are single-team, single-deploy. Get it wrong and every feature is a cross-team negotiation. Cohesion and coupling are the language for making that bet explicit. ## Inputs for placing boundaries **1. Axis of change / bounded context.** Group by *who requests the change*, not by what the code looks like. Two modules that both parse text but serve accounting and marketing have different stakeholders and belong apart. Domain-Driven Design's bounded context is the same rule applied to language: where a term's meaning shifts ("Customer" in Sales vs Billing), you have a boundary. **2. Co-change evidence.** Version-control history is the cheapest empirical signal available. Files or packages that repeatedly change in the same commit are cohesive in practice, whatever the folder structure says; a package whose files never co-change is probably two packages. Tools that mine temporal coupling from git logs make this measurable rather than aesthetic. **3. Team ownership (Conway's Law).** "Organisations design systems that mirror their communication structure." A boundary that cuts across a team produces constant coordination and will erode; a boundary aligned with a long-lived team survives. The Inverse Conway Manoeuvre is deliberately shaping teams to get the architecture you want. **4. Transactional invariants.** If two pieces of data must be consistent *at the same instant* (an account balance and its ledger lines), splitting them means distributed transactions or compensating sagas. DDD's rule of thumb — one aggregate per transaction, references between aggregates by identity only — is a cohesion/coupling rule in disguise. **5. Volatility and rate of change.** Isolate the parts that change most often behind stable interfaces so their churn does not propagate. This is Parnas's original information-hiding criterion: hide the decisions most likely to change. **6. Non-functional isolation.** Independent scaling, differing availability or compliance requirements, or a need for a different technology stack can justify a boundary even when the domain does not. ## Classifying the cross-boundary dependency Once boundaries exist, the design work is choosing *what kind* of coupling connects them: | Mechanism | Coupling it creates | Cost | |---|---|---| | Synchronous call (request/response) | **Runtime/temporal**: B must be up now | Availability multiplies (0.99 × 0.99…); latency adds; cascading failure without timeouts, retries with jitter, circuit breakers, bulkheads | | Shared database/table | **Common coupling** | No owner of invariants; schema changes are lock-step; the hardest to undo | | Shared library | **Deployment/version coupling** | Upgrades must be coordinated; a shared "common" package drifts into the zone of pain | | Asynchronous event | Weakest (**message coupling**) | Eventual consistency, ordering/duplicate handling, schema evolution of events, harder end-to-end tracing | | Data replication / read model | Value connascence | Staleness, reconciliation, storage cost | Also useful is the **anti-corruption layer**: when you must depend on a model you do not control (a legacy system, a vendor API), put a translating adapter at the boundary so its concepts do not leak into your core — bounded, deliberate coupling at one point instead of diffuse coupling everywhere. And remember the **direction** rule: dependencies should point from volatile toward stable (Stable Dependencies Principle). Where the natural call direction is wrong, invert it with an interface owned by the stable side, or flip a synchronous call into an event the consumer subscribes to. ## When tighter coupling is the right call Decoupling is not free. Deliberately accept more coupling when: - **An invariant requires immediate consistency.** A saga with compensations is often more expensive and more error-prone than keeping the two entities in one transactional boundary. Prefer one aggregate over eventual consistency for genuinely atomic business rules. - **The domain is still being discovered.** Early boundaries are guesses, and a wrong service boundary is far more expensive to move than a wrong package boundary. A **modular monolith** — enforced in-process boundaries, one deployable — keeps decomposition options open. Extract to services when a boundary has proven stable and there is a real scaling/ownership reason. - **Decoupling machinery outweighs the benefit.** Introducing a broker, contract tests, event versioning and a tracing story to remove one dependency between two modules owned by the same team is negative value. Match the mechanism to the coordination cost it actually removes. - **The alternative is worse duplication.** Duplicating a genuine business rule creates connascence of algorithm across copies — usually worse than a dependency on one owned implementation. (Duplicating *incidentally similar* code is fine; "a little copying is better than a little dependency" applies to accidental, not essential, similarity.) - **The dependency is on something genuinely stable.** Coupling to a mature standard, a value type, or a versioned public contract propagates almost no change, so effort spent hiding it behind an interface buys nothing. ## Failure modes to name - **Distributed monolith** — services split on technical layers or arbitrary lines, chatty synchronous calls, shared database, lock-step releases. All the operational cost, none of the autonomy. - **Entity services** — one service per database table, so every use case orchestrates five calls; boundaries follow data shape rather than capability. - **The shared "common" library** — everything anyone might reuse, imported by all: maximum afferent coupling, concrete, volatile — the textbook zone of pain. - **Over-abstraction** — an interface per class, indirection with one implementation. It reduces the *appearance* of coupling on a diagram while raising the cost of reading the code. - **Nanoservices** — splitting past the point where a change fits in one boundary, converting internal calls into network calls and cohesion into latency. ## How to know you got it right Measure outcomes, not diagrams: what fraction of changes touch exactly one boundary; how many teams must coordinate for a typical feature; lead time from commit to production per boundary; whether a boundary can be deployed and rolled back alone; and whether incidents in one boundary stay contained. If most changes cross boundaries, your cohesion is wrong regardless of how clean the dependency graph looks.