Skip to content
Software Architecture Guide

Modularity

Explanation

Section titled “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

Section titled “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

Section titled “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

Section titled “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.
Section titled “Related”

Sources

Section titled “Sources”