Protocol
Hide volatile decisions behind stable interfaces
Information hiding protects the rest of the system from volatility.
When it fits
- When callers depend directly on internal details that change often.
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
Define an interface around the capability and keep likely-to-change representation or rules inside. Expose only what consumers need for stable use.
Steps
- Name the volatile design decision.
- Define what consumers actually need.
- Create a stable contract around that need.
- Test whether internal change can occur without caller changes.
An example
Downstream consumers request a canonical customer status rather than reading several internal tables whose representation may change.
Check your result
A representative internal change can be made without coordinated edits to every consumer.
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 withMinimize the number of teams that must change together
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