Cohesion
Cohesion describes the inner connection of the tasks of a building block. High business cohesion bundles rules that are changed together for the same reasons.
- Reason for changeWhat changes together belongs together.
- Technical sectionA module carries a technical task completely.
- Appropriate moduleThe technically correct home of each task.
Context
Why this is important
Tasks that are changed for various reasons do not belong together. Where they are mixed, a price change draws payment code. How tasks are generally separated is handled by the building block Separation of Concerns.
This building block looks inwards: Does it belong together what is in a building block? How tasks are distributed to different places deals with separation of responsibilities.
At a glance · Shared reason, shared module
Cut by technology or by business domain?
Price determination, product description and product range view change for catalogue reasons. Payment authorization and payment status, on the other hand, follow rules of payment.
This is how you read the picture
- Reason for change The number “Appliced modules” in the scenario: price rule or payment type shows the reason.
- Technical section In the cut "by business domain" only catalogue or Payment.
- Appropriate module The table below: Column “Belonged in” calls catalogue or payment.
- ChangesSurface surfaceAdjusting the price display
- ChangesBusiness logicInclude price rule for cups
- ChangesData accessExpanding price fields and queries
- Not availableCatalogueThere is no such thing in this section
- Not availablePaymentThere is no such thing in this section
3Affected modules
The price rule runs through all three layers, although it is technically one thing.
Values illustrative
Which task belongs in which module?
| Task | Why is it changing? | Belongs to | Otherwise, go with |
|---|---|---|---|
| Change the product price | Range and price rule | Catalogue | General data service |
| Maintaining product text | Presentation of the product range | Catalogue | Order |
| Refusal of payment | Payment rule | Payment | Catalogue |
| Clarify the payment status | Provider interaction | Payment | Invoice |
Benefits & limitations
Helps if:
- A building block has several unrelated reasons to change.
- Rules and data are searched for at different points and adapted together.
Boundaries
- Shared reasons for change shape cohesion even in small building blocks. Examine those reasons and avoid decomposition that merely adds Coupling.
- A technical catch-all area can obscure business responsibility. State its purpose and check whether Separation of Concerns clearly separates different reasons for change.
In practice
- Examine change patterns. Compare several real-world changes and note which rules, data and tests were affected together. The result shows recurring responsibilities.
- State each building block's purpose clearly. Describe its coherent task and the information it owns. Use Module Boundaries to communicate this purpose to consumers.
- Separate independent reasons for change. Check whether unrelated changes are grouped without a shared business reason. Separation of Concerns helps organise these responsibilities without unnecessary handovers.
Read the detailed explanation
A cohesive building block groups behaviour and data that change for the same business or technical reason. It has a clear purpose, and its internal parts support a coherent responsibility. Separation of Concerns separates different reasons for change; Module Boundaries makes responsibilities visible to consumers.
Cohesion becomes apparent in real change patterns: which rules, tests and data change together? Purely technical grouping may conceal different responsibilities; excessive fragmentation creates additional handovers. A meaningful internal relationship helps developers locate changes in the right place.
The term comes from Larry Constantine's Structured Design, which ranked cohesion from weak to strong: coincidental, logical, temporal, procedural, communicational, sequential and functional. A 'Utils' collection has coincidental cohesion when its contents are grouped only because they fitted nowhere else. Logical cohesion groups similar kinds of tasks, such as all output functions, even when they have no business relationship. Temporal cohesion groups 'everything that runs at night': timing is the only connection. Functional cohesion means all parts work together to fulfil one task. A miscellaneous helper module has weak cohesion because its parts change for different reasons: each change touches the same module and may affect unrelated parts.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
How many modules change in the new price rule in the technical section?
View the solution with justification
Three: interface, business logic and data access. In the business cut, only the catalogue changes.
ApplyingTransferred to a new situation
The shop needs a new price rule for cups. Where is it implemented and what is left untouched?
View the solution with justification
In the catalogue, because “change product price” belongs to the range and price rule. The payment shall remain unaffected.
EvaluateWeighing an alternative
Should the translation of the payment status go into the bill because it is needed there?
View the solution with justification
The bill would have everything in one place. However, the provider status changes with the payment integration and therefore belongs to the payment, as the matrix shows. The invoice reads the translated result.
Explore further
These building blocks continue the thoughts of this page.
References
- David Parnas · On the Criteria To Be Used in Decomposing Systems into Modules (opens in new tab)Basic paper on information hiding and stable module boundaries. Original scientific publication; full text access by the publisher may be restricted.
- Robert C. Martin: The Single Responsibility Principle (opens in new tab)A module should have a reason to change: What changes for the same reason belongs together.
- Microsoft Domain Analysis (opens in new tab)Derives domain boundaries and bounded contexts from business contexts.