Cohesion is the degree to which the parts of a module belong together — how single-minded the module is about one responsibility. A cohesive module has one reason to change; a non-cohesive one is pulled in several directions at once, so every change risks the concerns it happens to sit beside.

Raising cohesion localises change. Splitting for cohesion often lowers coupling too, because the responsibilities you separate stop reaching into each other.

Two before-and-after rows. Top: a tangled Orders module holding pricing and invoicing responsibilities splits into a single-purpose Pricing module and a single-purpose Invoicing module. Bottom: a logging concern scattered as a stray piece across three modules is gathered into one cohesive Logging module.

How It Works

  • Split a module — when a module holds responsibilities that change for different reasons, refactor it into smaller modules that each serve one purpose.
  • Redistribute responsibilities — when a single responsibility is smeared across several modules, gather its scattered pieces into one place.
  • Draw the seam along a fracture line — group what serves one business capability, split what changes for different reasons.

Failure Modes

  • Splitting by layer or type rather than by responsibility scatters one feature across the new modules — every change still touches them all.
  • Over-splitting produces anaemic modules that do too little, so the coupling between them exceeds the cohesion gained.
  • A module accretes helpers over time; its stated purpose and actual contents drift apart.

Verification

  • Structural cohesion metrics improve — LCOM (lack of cohesion of methods) falls. Read LCOM with care: it captures only method-and-field links inside a class, not whether a module maps to a single business capability.
  • Change-coupling analysis of version history shows the split modules now change independently, not in lockstep.
  • A one-sentence responsibility statement fits each module without an “and” — a fuzzy line signals a further split.
  • Reduce Coupling is the complementary lever — see that page.
  • Domain-Driven Design applies cohesion at subsystem scale: a bounded context groups one business capability, and the context map shows how those contexts relate.
  • The Single Responsibility Principle restates cohesion at class scale: one reason to change.
  • Hotspot and change-coupling analysis point to which non-cohesive modules to split first.

References