Principle
Make dependencies directional where possible
Mutual dependency amplifies coordination.
When it fits
- When two components or teams repeatedly block each other because each requires internal knowledge of the other.
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
Choose a stable abstraction or ownership direction so one side depends on a contract rather than both sides depending on internals. Keep truly reciprocal work explicit.
An example
A reporting layer depends on a published canonical model; the core model no longer depends on report-specific transformations.
Check your result
A routine change on one side no longer automatically creates a reverse change request.
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 withBreak a dependency before optimizing inside it
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