Coupling
Also known as: tight coupling, loose coupling, afferent and efferent coupling
Coupling is the degree to which one component depends on the internals of another, measured by how much of it must change when the other changes. Low coupling is not the goal in itself — the goal is that changes stay local, and coupling is the property that decides whether they do.
Last reviewed · Part of the Architecture Glossary
In practice
Types, worst to best:
| Type | Example | Change blast radius |
|---|---|---|
| Content | Reaching into another module's private state or table | Everything |
| Common | Shared mutable global or shared database table | Every writer |
| Control | Passing a flag that switches the callee's behaviour | Both sides, always together |
| Stamp | Passing a whole object when one field is needed | Callee couples to the whole shape |
| Data | Passing exactly the parameters needed | Local |
Two measurements worth automating as fitness functions:
- Afferent coupling (Ca) — how many modules depend on this one. High Ca means it is hard to change; it needs a stable interface.
- Efferent coupling (Ce) — how many modules this one depends on. High Ce means it is fragile; it breaks when any of them move.
Temporal coupling is the one that hides in distributed systems: service A cannot complete without service B being up right now. Asynchronous messaging removes it; a synchronous call chain multiplies it into the availability arithmetic.
When it matters
Every boundary decision, every shared-library proposal, every "let's just query their table" shortcut.
Common mistake
Chasing zero coupling. Components that never interact do nothing useful together; the aim is appropriate coupling — data-level, versioned, and explicit — not none.
See also
- Bounded ContextA bounded context is an explicit boundary within which a domain model and its terms have one consistent meaning.
- Anti-Corruption LayerAn anti-corruption layer is a translation boundary that converts between your domain model and an external or legacy one, so foreign concepts and naming do not leak inward.
- Fitness FunctionAn architectural fitness function is an automated, objective test of a non-functional requirement — coupling, latency, security posture, cost — run continuously in CI.
- Contract TestingContract testing verifies that a provider's API satisfies the expectations its consumers actually rely on, by running each consumer's recorded expectations against the provider in isolation.