> ## Documentation Index
> Fetch the complete documentation index at: https://agentconcepts.io/llms.txt
> Use this file to discover all available pages before exploring further.

# modularity

> A system is organized into internally cohesive units whose interactions with other units are constrained by explicit interfaces, so change, substitution, or recombination can remain local rather than propagating through the whole.

<Badge>biology</Badge> <Badge>business</Badge> <Badge>computer-science</Badge> <Badge>engineering-and-technology</Badge>

# 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](/concepts/container) supplies an inside and outside, but not necessarily a contract that localizes change.
* **Failure isolation alone** — [bulkhead](/concepts/bulkhead) optimizes blast radius. Modularity may yield that benefit, but its broader payoff is independent evolution and recombination.

## Structure

<img src="https://mintcdn.com/agentconcepts/jxnkHTbC28keCfWc/concepts/_assets/modularity-slots.svg?fit=max&auto=format&n=jxnkHTbC28keCfWc&q=85&s=160e39495a1fa7f8e272990ddde445a3" alt="Internal structure of modularity: a table of its component slots and the concepts that fill them." style={{ width: "100%" }} width="817" height="281" data-path="concepts/_assets/modularity-slots.svg" />

The concept composes four roles: coherent modules, stronger internal than external coupling, constrained interfaces, and a locality payoff. Remove the interface constraint and the modules become arbitrary partitions. Remove the locality payoff and the “modular” label is observationally empty.

## Relationships

<img src="https://mintcdn.com/agentconcepts/jxnkHTbC28keCfWc/concepts/_assets/modularity-neighborhood.svg?fit=max&auto=format&n=jxnkHTbC28keCfWc&q=85&s=0c99f7543e7f09b80a3c44970ee0d482" alt="Relationship neighborhood of modularity: a graph of the concepts it connects to and the concepts it is a part of." style={{ width: "100%" }} width="920" height="891" data-path="concepts/_assets/modularity-neighborhood.svg" />

* [bulkhead](/concepts/bulkhead) — bulkheads are modules whose load-bearing contract is failure isolation.
* [adapter](/concepts/adapter) — adapters translate between module contracts without dissolving their boundaries.
* [graceful-degradation](/concepts/graceful-degradation) — bounded coupling lets the remainder keep operating when one unit disappears.
* [composite](/concepts/composite) — composite is recursive uniform containment; modularity is constrained coupling and local change, independent of topology.

## Examples

<AccordionGroup>
  <Accordion title="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" defaultOpen={true}>
    Parnas compared two decompositions of a Key Word In Context index. The first followed the processing sequence—input, circular shift, alphabetize, output—so multiple stages depended directly on shared representations. A change to how lines or characters were stored could therefore force changes across the pipeline. The second decomposition assigned each likely-to-change design decision to a module and exposed it through an interface. Line storage hid its representation; circular shifting and alphabetizing could change internally without requiring their consumers to change.

    **Inference**: A process diagram is not automatically a module diagram. To localize future change, draw boundaries around volatile decisions and make other units depend on their contracts rather than their representations.
  </Accordion>

  <Accordion title="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" defaultOpen={true}>
    Ulrich distinguished modular product architectures from integral ones by how functional elements map onto physical components and how component interfaces couple them. In his trailer example, functions such as connecting to the vehicle and carrying cargo can be assigned to distinct components with decoupled interfaces. Provided the interface remains fixed, a component can change without requiring corresponding changes throughout the product, and alternative components can be recombined into product variants.

    **Inference**: The payoff does not come from having many parts. It comes from choosing interfaces that let the parts vary independently along dimensions users or designers actually need to change.
  </Accordion>

  <Accordion title="Herbert A. Simon, “The Architecture of Complexity,” Proceedings of the American Philosophical Society 106(6), 1962, 467–482 · business">
    Simon’s parable contrasts two watchmakers assembling thousand-part watches in interruption-prone work. Tempus builds each watch as one long sequence, so an interruption destroys nearly all accumulated work. Hora first builds stable subassemblies, then combines those into larger subassemblies. An interruption loses only the current small unit. Simon uses the case to motivate nearly decomposable systems: interactions within a subsystem dominate in the short run, while interactions among subsystems are weaker or slower.

    **Inference**: Stable intermediate units do more than organize work. They bound the amount of progress, state, or reasoning that a disturbance can erase.
  </Accordion>

  <Accordion title="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">
    Wagner, Pavlicev, and Cheverud describe biological modules as relatively autonomous, internally connected components. One empirical case is the mouse mandible: the tooth-bearing alveolar process and the ascending ramus involved in muscle attachment and articulation form distinct developmental and functional regions. Traits within a region covary more strongly, while the regions retain enough relative independence to vary and evolve without every change propagating uniformly through the whole jaw.

    **Inference**: Modularity is not unique to designed interfaces. Selection and development can produce the same interaction topology when local integration is useful but global entanglement would prevent parts from adapting independently.
  </Accordion>
</AccordionGroup>
