Principle
Decompose around likely change, not the org chart
Useful boundaries localize likely change.
When it fits
- When a system is split into components that mirror teams but every business change still touches many components.
When to avoid it
- Modularity trades coordination inside a boundary for coordination across interfaces. Do not split systems simply to make diagrams or org charts look cleaner.
Why it matters
Identify design decisions likely to vary independently and place them behind boundaries that minimize coordinated change. Team ownership can follow later.
An example
A pricing rule and its data are isolated from transport mechanics so policy changes do not require transport rewrites.
Check your result
Common changes touch fewer modules without creating hidden duplication.
Keep this limit in mind
- Modularity trades coordination inside a boundary for coordination across interfaces. Do not split systems simply to make diagrams or org charts look cleaner.
Connected ideas
Useful withHide volatile decisions behind stable interfaces
Evidence and sources
Supports
Parnas showed that modularization outcomes depend on decomposition criteria and argued for boundaries that hide changeable design decisions to improve flexibility and comprehensibility.
This is foundational software-design reasoning; organizational adaptations require separate validation.
On the Criteria To Be Used in Decomposing Systems into Modules · Abstract and design comparison