Principle
Separate policy from implementation mechanism
Stable mechanisms should not hard-code volatile policy where avoidable.
When it fits
- When a rule change repeatedly requires low-level rewrites across the system.
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
Express business policy in one explicit layer or configuration boundary and let implementation consume it through a stable contract, subject to security and performance constraints.
An example
Order-block policy changes from ZM to another rule without rewriting the underlying persistence and integration mechanics.
Check your result
A policy change can be reviewed and deployed without unnecessary changes to unrelated mechanism code or process.
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 withDesign a fallback at the interface
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