Actors and axes of change

An “axis of change” is a direction along which requirements move independently — and each axis has an owner who pushes it. Forget counting methods. Ask instead: what kinds of change request land on this code, and do they arrive separately? A pricing service typically faces at least three: marketing changes how prices are displayed (currency, locale, rounding); finance changes how tax or discount is computed (the business rule); platform/ops changes how results are stored (schema, datastore, audit columns). Those three requests come from three different people on three different schedules. Each is an axis. The owner of the axis — the “actor” in Uncle Bob’s phrasing of SRP — is who you’d go ask when that kind of change is needed.

The point of naming the actor is that it makes the boundary objective. “Is formatting a separate responsibility from tax math?” is a matter of taste. “Does the person who changes formatting differ from the person who changes the tax rule?” has an answer, and on most teams the answer is yes.

When two axes share a module, a change on one axis risks breaking the other — that is coupling across axes, and it is the cost SRP attacks. Consider this service, where presentation policy, a business rule, and persistence all live in one method:

class InvoiceService {
  render(invoice: Invoice): string {
    // business rule (finance owns this)
    const tax = invoice.subtotal * 0.2;
    const total = invoice.subtotal + tax;
    // persistence (ops owns this)
    db.execute(
      "UPDATE invoices SET total_cents = ? WHERE id = ?",
      [Math.round(total * 100), invoice.id],
    );
    // presentation policy (marketing/locale owns this)
    return `Total: $${total.toFixed(2)}`;
  }
}

Three actors are now entangled in one method. When finance changes the tax rule, the diff also sits next to the SQL and the $-formatting — a reviewer from finance has to read code they don’t own, and a careless edit to the rule can shift the rounding written to the database. The three concerns don’t just coexist; they share state and execution order, so each is exposed to the others’ mistakes.

Separating by axis means a change on one axis touches exactly one module — this is the cure for shotgun surgery. Shotgun surgery is the smell where one logical change forces edits scattered across many places. SRP’s specific claim is that the scatter is caused by mixing axes: if tax math is smeared across rendering, storage, and reporting, then changing tax math is a shotgun. Pull each axis into its own seam and the scatter collapses:

// axis 1: the business rule — finance's module
class InvoicePricing {
  total(invoice: Invoice): number {
    const tax = invoice.subtotal * taxRate(invoice.region);
    return invoice.subtotal + tax;
  }
}
// axis 2: persistence — ops's module
class InvoiceStore {
  saveTotal(id: string, totalCents: number) {
    db.execute("UPDATE invoices SET total_cents = ? WHERE id = ?", [totalCents, id]);
  }
}
// axis 3: presentation policy — locale's module
class InvoiceFormatter {
  line(total: number, locale: Locale): string {
    return format(total, locale); // currency, rounding, symbol position
  }
}

Now a tax-rule change is one edit inside InvoicePricing; a datastore migration is one edit inside InvoiceStore; a locale change is one edit inside InvoiceFormatter. None of them can break the others, because they no longer share a body.

Cohesion is the same principle from the other side: things that change together live together; things that change apart live apart. SRP is often taught as “split things up”, but the deeper rule is grouping, and the grouping criterion is co-variation. Code that always changes for the same reason has high cohesion — keep it in one place even if it is several functions. Code that changes for different reasons has low cohesion when forced together — that is precisely the entanglement above. So SRP doesn’t tell you to make modules small; it tells you to make each module’s reasons-to-change singular. A 200-line module that only ever changes when the tax rule changes is more cohesive — and more SRP-compliant — than a 20-line module that changes for tax, formatting, and storage reasons.

This is why “one responsibility” and “one axis of change” and “high cohesion” are three names for one design target: align module boundaries with the boundaries between independent change requests.