Modularity
Description
Modularity organizes a system into units that are more tightly integrated internally than they are with one another. The boundaries are not merely labels: a small, explicit interaction surface prevents many internal decisions from leaking outward. The result is locality of change. A module can be revised, substituted, reused, or recombined while neighboring modules continue to rely on the same contract. The diagnostic is not “does the system have parts?” Almost every system does. Ask instead: which decisions can change without forcing coordinated changes elsewhere, and what interface makes that independence possible? If the answer is “none,” the decomposition is cosmetic. If a bounded set of decisions can vary behind a stable interface, the module is doing structural work.Aliases
Near-decomposability emphasizes the interaction topology: within-unit interactions dominate in the short run while cross-unit effects are weaker or slower. Modular architecture emphasizes the designed artifact. Both name the same transferable structure; “near” matters because useful modules are rarely perfectly independent.Triggers
- A change in one region unexpectedly requires edits throughout the system.
- Teams want independent ownership but keep coordinating on internal implementation details.
- Several variants could share a stable frame while swapping one functional unit.
- A system is called modular, but no one can name the contract that confines change.
- Reuse or recombination is desired without standardizing every internal detail.
Exclusions
- Partition without interaction discipline — names and directories do not create modules when dependencies cross every boundary freely.
- Load-bearing global coupling — some systems genuinely require dense coordination; modularizing them may destroy the behavior being preserved.
- Containment alone — container supplies an inside and outside, but not necessarily a contract that localizes change.
- Failure isolation alone — bulkhead optimizes blast radius. Modularity may yield that benefit, but its broader payoff is independent evolution and recombination.
Structure
Relationships
- bulkhead — bulkheads are modules whose load-bearing contract is failure isolation.
- adapter — adapters translate between module contracts without dissolving their boundaries.
- graceful-degradation — bounded coupling lets the remainder keep operating when one unit disappears.
- composite — composite is recursive uniform containment; modularity is constrained coupling and local change, independent of topology.
Examples
David L. Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules,” Communications of the ACM 15(12), 1972, 1053–1058, doi:10.1145/361598.361623 · computer-science
David L. Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules,” Communications of the ACM 15(12), 1972, 1053–1058, doi:10.1145/361598.361623 · computer-science
Karl T. Ulrich, “The Role of Product Architecture in the Manufacturing Firm,” Research Policy 24(3), 1995, 419–440, doi:10.1016/0048-7333(94)00775-3 · engineering-and-technology
Karl T. Ulrich, “The Role of Product Architecture in the Manufacturing Firm,” Research Policy 24(3), 1995, 419–440, doi:10.1016/0048-7333(94)00775-3 · engineering-and-technology
Herbert A. Simon, “The Architecture of Complexity,” Proceedings of the American Philosophical Society 106(6), 1962, 467–482 · business
Herbert A. Simon, “The Architecture of Complexity,” Proceedings of the American Philosophical Society 106(6), 1962, 467–482 · business
Günter P. Wagner, Mihaela Pavlicev, and James M. Cheverud, “The road to modularity,” Nature Reviews Genetics 8, 2007, 921–931, doi:10.1038/nrg2267 · biology
Günter P. Wagner, Mihaela Pavlicev, and James M. Cheverud, “The road to modularity,” Nature Reviews Genetics 8, 2007, 921–931, doi:10.1038/nrg2267 · biology