Cohesion
Whether the things inside a boundary belong together and change for the same reason.
4 to work through
-
beginner
Review this. An internal library called platform-common holds an HTTP client, a feature-flag reader, a money type, a retry helper and tenant-context propagation. 140 services depend on it. A one-line bugfix to the money type produces version 4.12.0, and until each service upgrades it is running a version missing the fix. The last upgrade wave took eleven weeks. What would you split, and what would you leave alone?
3 min answer -
intermediate
A subscription-billing platform has an "invoice service" that generates invoices, sends dunning emails, computes tax, syncs to accounting systems and renders PDFs. Is that cohesive? How would you decide?
1 min answer -
intermediate Multiple choice
Every meaningful feature in a platform requires changes to at least nine services and three teams. Which architectural property has failed and what is the diagnostic?
2 min answer -
advanced Multiple choice
A search company must decide where the rules deciding which documents are eligible to appear for a query should live - the crawler, the indexer, the query serving layer, or a dedicated component. Which choice best reflects cohesion?
2 min answer
4 terms in this topic
Change-Reason Cohesion
The working test for a module boundary - things belong together if they change for the same reason, at the same time, driven by the same stakeholder,…
conceptCohesion in Practice
Whether the things inside a boundary belong together — measured by whether they change for the same reason and at the same time.
conceptConnascence
A graded vocabulary for coupling that ranks each dependency by how hard it is to change and how far apart the parties are, so boundaries can be argue…
conceptFunctional Cohesion
The strongest form of cohesion, in which every element of a module contributes to a single well-defined task.
Neighbouring topics
Architecture Fundamentals
General material on what solution architecture is and what an architect is accountable for.
Requirements to Constraints
Turning stated requirements into the constraints that actually bound a design.
Functional vs Non-Functional
Behaviour versus quality of behaviour, and why only the second constrains structure.
Architectural Drivers
The small subset of requirements whose change would force the structure to change.
Quality Attributes
Availability, latency, throughput, security, cost — expressed as testable scenarios.
Architecture Principles
Durable agreed rules that rule options out, stated with rationale and implications.
Coupling
How much one component must know about, or change alongside, another.
Modularity
Composing a system from parts that can be understood and replaced independently.
Separation of Concerns
Organising so that a change to one concern touches one place.
Abstraction & Encapsulation
Hiding mechanism behind contract, and protecting invariants by owning state.
Architecture Styles
System-level organising shapes, and how they differ from problem-level patterns.
Evolutionary Architecture
Designing for guided incremental change rather than for correctness on day one.
Fitness Functions
Automated checks that an architectural characteristic still holds.
Architecture Documentation
What to write down, at what altitude, and what nobody will ever read.
Conway's Law
Systems mirroring the communication structure of the organisation that builds them.
Trade-off Fundamentals
Why every architecture is a set of purchases, and how to state what you gave up.
Technical Constraints
Existing estate, skills, licences and platforms as inputs rather than obstacles.
Architecture Roles
Solution, enterprise, domain and platform architecture, and where each is accountable.
Reference Models
Shared conceptual frames — layering, tiers, viewpoints — and their limits.