Checklist
Count coordination edges before adding a component
Every new node can create more interfaces to understand and maintain.
When it fits
- When a proposed component, workflow or team boundary looks locally clean but adds many new interactions.
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.
Checklist
- List new inbound dependencies.
- List new outbound dependencies.
- List new ownership and support interfaces.
- Compare with keeping the capability inside an existing boundary.
Why it matters
Before adding a component, count required producers, consumers, approvals, observability paths and ownership handoffs. Compare coordination cost with the benefit of separation.
An example
A new microservice removes 200 lines of code but creates six operational interfaces and an on-call dependency; the trade-off is reconsidered.
Check your result
The design decision includes coordination edges and lifecycle cost, not only local component size.
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 withTest whether modularity actually localizes change
Evidence and sources
Provides context
Simon described complex systems as often hierarchical and near-decomposable, motivating analysis of relatively strong within-subsystem interactions and weaker cross-subsystem interactions.
Near decomposability is a conceptual property, not evidence that any chosen boundary is correct.
The Architecture of Complexity · Near-decomposability discussion