Coupling and architecture quanta

How easily a system evolves depends mostly on coupling: if changing A forces changes to B, C, and D, change is expensive. The aim isn’t zero coupling (that’s impossible) but appropriate coupling: tight where things genuinely change together, loose where they don’t.

Architecture quantum

The architecture quantum is the smallest part of a system that can be deployed independently and evolve on its own. In the 2nd edition (and Software Architecture: The Hard Parts) a quantum has:

• Independent deployability: it includes everything it needs to run, including its data store.
• High functional cohesion: it does one coherent job (in DDD terms, roughly a bounded context).
• High static coupling inside: the code, libraries, and infrastructure it depends on.
• Synchronous dynamic coupling: services that call each other synchronously behave as one quantum at runtime, because they share availability and performance.

Why it matters: each quantum can have its own architectural characteristics. A payment service may need strict consistency; a recommendations service may favour availability. A monolith with one shared database is usually one quantum, so every part has to meet the strictest requirement.

A common surprise

Splitting a monolith into microservices that share one database, or that chain synchronous calls, often still leaves you with one quantum. You pay the cost of distribution without gaining independent evolution.

Connascence

Connascence (Meilir Page-Jones) gives a vocabulary for kinds of coupling. Two components are connascent if a change in one requires a change in the other.

Static (visible in source code), from weaker to stronger:

• Name: agree on a name.
• Type: agree on a type.
• Meaning / convention: agree on what a value means (for example, magic numbers).
• Position: agree on parameter order.
• Algorithm: agree on an algorithm (for example, both sides hash the same way).

Dynamic (only visible at runtime), from weaker to stronger:

• Execution: order of execution matters.
• Timing: timing of execution matters.
• Values: several values must change together.
• Identity: components must reference the same entity.

Guidelines:

• Prefer weaker forms, especially across boundaries.
• Keep strong connascence local (inside a module or quantum).
• Reduce the degree (how many components are affected).

Related ideas

• Domain-driven design / bounded contexts give natural quantum boundaries.
• Postel’s law (be conservative in what you send, liberal in what you accept) reduces coupling between services.
• Contract testing makes integration coupling explicit and checkable.
• Duplication over coupling: across quanta, some duplication can be cheaper than a shared library that ties release cycles together.