How many modules are affected if the order changes its schedule and there is a contract?

Only the order. The invoice remains stable because the invoice data contract remains the same.

Order calls payment in sync and waits. What kind of coupling is this, and how do you loosen it?

Time coupling: Order depends on the result of the payment as long as it waits. It can be loosened asynchronously, for example with an order and a later response. For this, you take distributed error cases into account.

The invoice should read order tables directly for simplification. How do you weigh up?

Advantage: less code for the transfer. Disadvantage: Scheme changes of the order break the bill, and it requires joint database tests instead of a contract test. With limited benefit, the price outweighs.

ConceptChapter I · Principles · Building block 1 of 6

Coupling

Coupling describes how much a building block depends on details of another. Dependencies transmit changes and failures along their relationships.

By Michael Meierhoff · Meierhoff Systems

Detailed couplingKnows internal tables and status.
ContractNarrow, business interface.
Types of couplingData, format, time, delivery, meaning.

Context

Why this is important

The more a building block knows about the innards of another, the further the effect of changes and failures. A conversion to the order then breaks the bill. Where modules draw their boundaries, the building block treats module boundaries.

This building block explains relationships between building blocks. For the internal cohesion of a building block see Cohesion.

At a glance · Contract instead of detailed access

A component uses another through a narrow contract; if it reaches into its internals, every change spreads.

Shop example · Playing through scenarios

coupling between order and invoice

The invoice module requires order number, invoice address and total amount. It should neither read internal order tables nor know the complete shopping cart.

This is how you read the picture

Detailed coupling In the case of detail coupling, the invoice is set to “breaks” as soon as the order schedule changes.
Contract In the case of contract coupling, the invoice only knows order number, address and amount and remains stable.
Types of coupling The table shows five types in the shop and one lever for loosening.

Coupling

Event

StableOrderTables unchanged
CoupledInvoicing data contractno contract, invoice directly
CoupledInvoiceReads internal order tables

Tables and statusKnown knowledge

The invoice runs, but knows internal tables and status of the order. Any subsequent change there affects them.

Select the coupling and trigger a change of the order pattern. You see who she meets.

Five Ways the Shop Is Coupled

Five Ways the Shop Is Coupled
Species	In the shop	So you loosen it up.
Data	Invoice reads the tables of the order directly.	Own contract, clear module boundaries, data sovereignty when ordering.
Format	All modules share the same order format.	Own models per module, translation in bounded context or via ACL.
Time	Order waits synchronously for payment.	Do not wait for everything: accept order, follow up payment as “clarification is ongoing”.
Delivery	All modules go live with a release.	Separate only if there is a proven need, for example as a microservice.
Significance	Everyone needs to know what a status value means.	Technical terms in the contract, Ubiquitous Language.

coupling has multiple faces, not just data access. Each species is loosened in a different place.

Benefits & limitations

Helps if:

Changes in a building block require regularly coordinated adjustments in several places.
Teams need independent deployments and must identify hidden release or data dependencies.

Boundaries

Loose coupling has a cost: more contracts to maintain, more indirection and, with asynchronous decoupling, distributed failure cases. Reduce coupling where changes actually propagate, while keeping Complexity in view.
Complete isolation complicates necessary collaboration. Aim for a clear, stable dependency, such as a narrow API Contract, rather than prohibiting every relationship. Strengthen the relevant Module Boundaries.

In practice

Determine dependencies in several forms. Collect calls, data accesses, common formats and time expectations. The result makes direct and indirect ties visible.
Trace a typical change through the graph. Record the affected building blocks, teams and releases. Connect the findings to Module Boundaries to distinguish private details from stable contracts.
Clarify data ownership and the contract. Define who may change a schema and how consumers adopt new versions. Data Ownership helps assess shared table access and its consequences.
Examine coupling dimensions in the invoicing process. Record assumptions about schema, meaning, timing and ordering. Clarify whether an amount is net or gross and which change would require a coordinated release. Use the findings to assess Module Boundaries.

Read the detailed explanation

Dependencies can involve calls, shared data, common formats, timing constraints or coordinated releases. The more assumptions consumers make about another building block's internals, the further changes propagate. Module Boundaries defines controlled access; Cohesion groups related responsibilities within a building block.

Building blocks still need to collaborate. The aim is a clear, stable dependency with explicit ownership, rather than complete isolation. Examine the consequences of changes, failure behaviour and data ownership. Tracing real flows also reveals indirect coupling through shared databases or operational assumptions.

Gregor Hohpe describes coupling as multidimensional. An invoice worker can be temporarily unavailable while orders continue to be accepted. The participants still share assumptions about schema, meaning and, where relevant, ordering. An 'amount' field may mean net or gross despite using the same numeric format. Temporal decoupling and semantic compatibility therefore need separate checks.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
How many modules are affected if the order changes its schedule and there is a contract?
View the solution with justification
Only the order. The invoice remains stable because the invoice data contract remains the same.
ApplyingTransferred to a new situation
Order calls payment in sync and waits. What kind of coupling is this, and how do you loosen it?
View the solution with justification
Time coupling: Order depends on the result of the payment as long as it waits. It can be loosened asynchronously, for example with an order and a later response. For this, you take distributed error cases into account.
EvaluateWeighing an alternative
The invoice should read order tables directly for simplification. How do you weigh up?
View the solution with justification
Advantage: less code for the transfer. Disadvantage: Scheme changes of the order break the bill, and it requires joint database tests instead of a contract test. With limited benefit, the price outweighs.

Explore further

These building blocks continue the thoughts of this page.

References

Continue on the learning path

Next in Principles & boundaries: Cohesion.

6 Building blocks

Continue withCohesion