Finding Boundaries: Cohesion, Coupling and Bounded Context
Objectives
By the end of the lesson, you can explain the difference between cohesion and coupling, say what a bounded context and a data owner are, and recognise the signs of a badly drawn boundary.
Why is the boundary the key question?
Every architecture — monolith, modulith or services — is a system of boundaries. The style only decides how strong and how costly the boundary is. If the boundary is in the wrong place, no style helps: the network between services only makes a bad split more expensive.
Cohesion and coupling
Cohesion expresses how much the responsibilities of a unit belong together. Cohesion is high if the things inside change together and serve common rules.
Coupling is the degree of dependency between units. Coupling is low if a unit uses only one stable, well-named operation of another; it is high if it also knows the other's internal structure or data.
The goal is high internal cohesion and manageable external coupling. Complete independence is not realistic: in the end the units together deliver one working system.
Bounded context
The meaning of a concept can differ across parts of an organisation. A "product" is a description and an image in the catalogue, movements and a quantity in the warehouse, and tax data in billing. If everything is forced into a single common model, it gets in everybody's way.
A bounded context is the boundary within which a single model is consistently valid. According to Martin Fowler's description, large models are divided into such contexts, and the relationships between the contexts are stated explicitly. A context is not the same as a service: it is a good starting point for boundary search, but a context can be implemented by a module or a service, and a service can also carry several contexts.
Data owner
Every modifiable piece of business data has exactly one data owner: the unit that enforces the rules of the data and carries out the modifications. A consumer may query it or keep a copy, but the rules are enforced by the owner.
If several units write the same data independently of each other, that is coupling without responsibility and contract: changing the schema affects everyone. Own data together with the rules that belong to it is one of the strongest tests of a boundary.
flowchart LR
A["Unit A:<br/>own rules and data"] -->|"contract"| B["Unit B"]
B -.->|"does not write A's data directly"| A
How is a bad boundary recognised?
Take a concrete business operation and write down which units, data and calls it needs.
Sign
What does it indicate?
Two units talk back and forth many times in every request
Too fine a split; cohesion crosses the boundary
Almost every change touches the same three units
The boundary does not follow the nature of change
Several units write the same data
The data owner is missing
Unit names are entity names (User, Address, Email)
Cut by data model, not by responsibility
One unit combines many responsibilities that change for different reasons
Too coarse a split
Size alone is not a measure. Co-change, the data owner and the required transactional guarantee give usable guidance.
Common misconceptions
Statement
Clarification
"A bounded context is a microservice."
A context can be realised as a module, a service or several services.
"Tight coupling is always bad."
Inside a unit it is desirable; the problem is hidden coupling that crosses boundaries.
"Every piece of data may be stored in only one place."
Copies are fine; the rules of the original are still enforced by the owner.
"If the service is small, the split is good."
Co-change and the data owner matter, not size.
In short
A boundary is good if cohesion is high inside and coupling is manageable outside.
A bounded context is a boundary within which a model is consistent.
Every piece of modifiable data has one owner.
Signs of a bad boundary: many back-and-forth calls, shared writes, units that change together.
Review questions
What distinguishes cohesion from coupling?
Why can the same concept (for example "product") differ in two contexts?
Finding Boundaries: Cohesion, Coupling and Bounded Context
Objectives
By the end of the lesson, you can explain the difference between cohesion and coupling, say what a bounded context and a data owner are, and recognise the signs of a badly drawn boundary.
Why is the boundary the key question?
Every architecture — monolith, modulith or services — is a system of boundaries. The style only decides how strong and how costly the boundary is. If the boundary is in the wrong place, no style helps: the network between services only makes a bad split more expensive.
Cohesion and coupling
Cohesion expresses how much the responsibilities of a unit belong together. Cohesion is high if the things inside change together and serve common rules.
Coupling is the degree of dependency between units. Coupling is low if a unit uses only one stable, well-named operation of another; it is high if it also knows the other's internal structure or data.
The goal is high internal cohesion and manageable external coupling. Complete independence is not realistic: in the end the units together deliver one working system.
Bounded context
The meaning of a concept can differ across parts of an organisation. A "product" is a description and an image in the catalogue, movements and a quantity in the warehouse, and tax data in billing. If everything is forced into a single common model, it gets in everybody's way.
A bounded context is the boundary within which a single model is consistently valid. According to Martin Fowler's description, large models are divided into such contexts, and the relationships between the contexts are stated explicitly. A context is not the same as a service: it is a good starting point for boundary search, but a context can be implemented by a module or a service, and a service can also carry several contexts.
Data owner
Every modifiable piece of business data has exactly one data owner: the unit that enforces the rules of the data and carries out the modifications. A consumer may query it or keep a copy, but the rules are enforced by the owner.
If several units write the same data independently of each other, that is coupling without responsibility and contract: changing the schema affects everyone. Own data together with the rules that belong to it is one of the strongest tests of a boundary.
How is a bad boundary recognised?
Take a concrete business operation and write down which units, data and calls it needs.
User,Address,Email)Size alone is not a measure. Co-change, the data owner and the required transactional guarantee give usable guidance.
Common misconceptions
In short
Review questions
Learning resources