# Modularity

**In short:** Modularity means dividing a system into self-contained building blocks. The quality of the split depends on the criteria used to divide the system, so modularity is a design issue.

## Explanation

A module is a building block of a system. Modularity is the practice of dividing a system into such blocks. The arc42 building block view shows this static decomposition. See the article Module for the definition.

**The criteria matter.** Splitting a system into pieces does not make it modular by itself. How good the split is depends on the criteria used to divide the system. That makes modularity a design issue.

**Start from decisions likely to change.** One proposed approach is to begin with a list of difficult design decisions, or decisions likely to change. This replaces starting from a flowchart of processing steps.

**Hide the inner workings.** A module's interface should reveal as little as possible about what happens inside. This idea is called information hiding. See the article Information Hiding.

**Cohesion first.** arc42 advises that cohesion should be the main driver when forming building blocks. Cohesion describes how closely the parts of one block belong together. See High Cohesion.

**Use your language's constructs.** arc42 also advises mapping building blocks to the modularization constructs of your programming language.

**Structure erodes.** A Big Ball of Mud is a system with a casual, haphazard structure, organized by expediency rather than design. Even well-architected systems erode structurally. Left unchecked, the structure can degrade until the system must be abandoned. See Big Ball of Mud and Architecture Decay.

**Domain-oriented splits.** Domain-Driven Design divides a large system into Bounded Contexts. Each context has one unified model. This is a domain-oriented way to decompose a system. See Bounded Context.

## Example

A shop system lists the decisions most likely to change: how prices are calculated and how payments are made. The team gives each decision its own module. Each module offers a small interface and keeps its inner workings private. When the pricing rules change, only the pricing module changes.

## Trade-offs

Dividing a system well takes design effort up front. The criteria you pick decide the result, and a poor choice gives a poor split. Structure also erodes over time, even in well-designed systems, so the split needs ongoing attention.



## Checks

- Building blocks are formed mainly by cohesion.
- Building blocks map to the modularization constructs of the programming language.
- Module interfaces reveal as little as possible about their inner workings.
- The criteria used to divide the system into modules are stated.

## Related

- [Module](https://arc.fuet.ch/concepts/domain-driven-design/module.md)
- [Information Hiding](https://arc.fuet.ch/concepts/principles/information-hiding.md)
- [High Cohesion](https://arc.fuet.ch/concepts/principles/high-cohesion.md)
- [Coupling and Cohesion](https://arc.fuet.ch/concepts/principles/coupling-and-cohesion.md)
- [Separation of Concerns](https://arc.fuet.ch/concepts/principles/separation-of-concerns.md)
- [Big Ball of Mud](https://arc.fuet.ch/concepts/fundamentals/big-ball-of-mud.md)
- [Architecture Decay](https://arc.fuet.ch/concepts/fundamentals/architecture-decay.md)
- [Bounded Context](https://arc.fuet.ch/concepts/domain-driven-design/bounded-context.md)

## Sources

- [On the criteria to be used in decomposing systems into modules – the morning paper](https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-used-in-decomposing-systems-into-modules/) — blog.acolyer.org, accessed 2026-11-09
- [5 - Building block view | arc42 Documentation](https://docs.arc42.org/section-5/) — docs.arc42.org, accessed 2026-11-09
- [Big Ball of Mud](https://www.laputan.org/mud/) — laputan.org, accessed 2026-11-09
- [Bounded Context](https://martinfowler.com/bliki/BoundedContext.html) — martinfowler.com, accessed 2026-11-09