Акторы и оси изменения

«Ось изменения» — это направление, вдоль которого требования двигаются независимо, и у каждой оси есть владелец, который её толкает. Забудь про подсчёт методов. Спроси вместо этого: какие виды запросов на изменение приходят на этот код и приходят ли они по отдельности? Сервис ценообразования обычно сталкивается как минимум с тремя: маркетинг меняет, как цены отображаются (валюта, локаль, округление); финансы меняют, как вычисляется налог или скидка (бизнес-правило); платформа/ops меняют, как результаты хранятся (схема, хранилище, колонки аудита). Эти три запроса приходят от трёх разных людей по трём разным графикам. Каждый — это ось. Владелец оси — «актор» в формулировке SRP у Дядюшки Боба — это тот, к кому ты бы пошёл спросить, когда такое изменение понадобится.

Смысл называть актора в том, что это делает границу объективной. «Является ли форматирование отдельной ответственностью от налоговой математики?» — вопрос вкуса. «Отличается ли человек, который меняет форматирование, от человека, который меняет налоговое правило?» — на это есть ответ, и в большинстве команд ответ «да».

Когда две оси делят один модуль, изменение по одной оси рискует сломать другую — это связанность между осями, и именно эту цену бьёт SRP. Рассмотри этот сервис, где политика представления, бизнес-правило и хранение живут в одном методе:

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)}`;
  }
}

Три актора теперь сплетены в одном методе. Когда финансы меняют налоговое правило, диф сидит рядом с SQL и $-форматированием — ревьюер от финансов вынужден читать код, которым не владеет, а небрежная правка правила может сдвинуть округление, записываемое в базу. Три заботы не просто сосуществуют; они делят состояние и порядок выполнения, поэтому каждая открыта ошибкам остальных.

Разделение по оси означает, что изменение по одной оси трогает ровно один модуль — это лекарство от shotgun surgery. Shotgun surgery — это запах, когда одно логическое изменение вынуждает править разбросанные по многим местам куски. Конкретное утверждение SRP в том, что разброс вызван смешением осей: если налоговая математика размазана по рендерингу, хранению и отчётам, то изменить налоговую математику — это shotgun. Вытяни каждую ось в свой шов — и разброс схлопывается:

// 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
  }
}

Теперь изменение налогового правила — одна правка внутри InvoicePricing; миграция хранилища — одна правка внутри InvoiceStore; изменение локали — одна правка внутри InvoiceFormatter. Ни одна из них не может сломать другие, потому что они больше не делят тело.

Связность — тот же принцип с другой стороны: то, что меняется вместе, живёт вместе; то, что меняется врозь, живёт врозь. SRP часто преподают как «разбей всё на части», но более глубокое правило — это группировка, и критерий группировки — со-вариация. Код, который всегда меняется по одной причине, обладает высокой связностью — держи его в одном месте, даже если это несколько функций. Код, который меняется по разным причинам, имеет низкую связность, когда насильно собран вместе, — это и есть та сплетённость выше. Так что SRP не велит делать модули маленькими; он велит делать причины-меняться каждого модуля единственными. Модуль на 200 строк, который меняется только когда меняется налоговое правило, более связен — и более соответствует SRP, — чем модуль на 20 строк, который меняется по причинам налога, форматирования и хранения.

Вот почему «одна ответственность», «одна ось изменения» и «высокая связность» — три имени одной проектной цели: выровнять границы модулей по границам между независимыми запросами на изменение.