Skip to content
Software Architecture Guide

Split Module

Explanation

Section titled “Explanation”

A module is a unit of code with a defined job. Some modules carry several jobs that change for different reasons. Such a module is pulled in several directions at once. A change to one job risks the others.

Split Module addresses this. You break the module into smaller modules, so each one has a single reason to change. A change then touches only the part it concerns. (The article Coupling and Cohesion explains these terms.)

When to split

Split when a module’s responsibilities change for different reasons. The deciding question is what changes, and why. Do not split just to make pieces smaller.

Code that is already cohesive and changes as one unit gains nothing from a split. The split only adds boundaries. So the split must follow change.

How to judge the split

Ousterhout advises deciding on overall complexity. Choose the structure with the best information hiding, the fewest dependencies, and the deepest interfaces. Information hiding means keeping a module’s details private (see Information Hiding).

Signs that pieces belong together:

  • They are closely related.
  • They share information, for example both depend on the syntax of one document type.
  • They are used together, but only if the relationship runs both ways.

Unrelated pieces are better apart.

Example

Section titled “Example”

A “Reports” module both formats invoices and calculates tax. Tax rules change each year. Invoice layout changes when the brand changes. The two jobs change for different reasons.

The team splits it into “Tax Calculation” and “Invoice Layout”. A new tax rule now touches only the first module.

Suppose both parts also had to read the same document format. That shared information would be a reason to keep them together.

Trade-offs

Section titled “Trade-offs”

Subdividing usually creates more components and more interfaces, and every new interface adds complexity. A split that does not follow change adds boundaries and no benefit. Joining closely related pieces can lower complexity. So compare the complexity of both structures before you decide.

Checks

Section titled “Checks”
  • Each module split is justified by responsibilities that change for different reasons.
  • Cohesive code that changes as one unit has not been split.
  • The decision to split or join is based on overall complexity, not size.
  • The added interfaces from a split are acknowledged.
Section titled “Related”

Sources

Section titled “Sources”