Формы coupling

Afferent и efferent coupling

У каждого модуля системы есть два показателя coupling, которые важны по отдельности:

Afferent coupling (Ca) — количество модулей, которые зависят от данного: сколько других частей системы импортирует или вызывает его. Модуль с высоким afferent coupling широко используется. На него давит стабильность: если он изменится, сломается многое. Billing-движок в B2B-платформе имеет высокий Ca — от него зависят сервис заказов, финансовая панель, инструменты администрирования и ERP-интеграция.

Efferent coupling (Ce) — количество модулей, от которых зависит данный: сколько других частей системы он импортирует или вызывает. Модуль с высоким efferent coupling хрупок: он чувствителен к изменениям во многих других модулях. Модуль, импортирующий репозиторий заказов, tax-сервис, discount-движок и платёжный шлюз — высоко efferent. Любое изменение в любом из этих четырёх каскадирует в него.

Отношение Ce / (Ca + Ce) даёт грубую оценку нестабильности (метрика Роберта Мартина). Модуль с Ce = 8 и Ca = 2 имеет нестабильность ≈ 0.8 — он зависит от многих вещей, но зависит от него немного. Модуль с Ce = 0 и Ca = 20 максимально стабилен — ничто из его зависимостей не сломает его, но всё, что его использует, подвержено его изменениям.

Лестница coupling

Не весь coupling одинаков. Page-Jones (1988) и Yourdon & Constantine определили классическую таксономию, ранжирующую формы coupling от самой жёсткой до самой мягкой. Чем слабее coupling, тем независимее оба модуля могут эволюционировать.

Content coupling (самый жёсткий): модуль A напрямую обращается к внутренним структурам данных или деталям реализации модуля B. Функция расчёта налогов из открытой истории читала сырые строки БД модуля заказов — это content coupling. Любое изменение внутреннего устройства модуля заказов ломает функцию налогов. Coupling невидим на уровне интерфейса; он существует в коде, который полностью обходит интерфейс.

Common coupling: оба модуля разделяют глобальную изменяемую переменную или общее хранилище данных. Два сервиса, разделяющих таблицу БД и оба пишущих в неё напрямую — это common coupling. Любой из них может испортить общее состояние так, что это сломает другой, и ни один не контролирует контракт данных.

Control coupling: модуль A передаёт модулю B флаг или код, управляющий его поведением. processOrder(order, mode: 'dry-run' | 'live') — control coupling, если billing-движок ветвится по флагу mode. Вызывающий должен знать о внутренних путях выполнения вызываемого — coupling находится в потоке управления, а не только в данных.

Stamp coupling (или data-structure coupling): модуль A передаёт модулю B большую структуру данных, а модуль B использует только её часть. Передача полного объекта Order, когда billing нужны только order.items и order.customerId — stamp coupling. Модули связаны с формой общей структуры даже по полям, которые ни один из них не должен трогать.

Data coupling (самый мягкий): модули A и B общаются только через простые, чётко определённые параметры — ровно те данные, что нужны. Billing-движок принимает (items: LineItem[], customerId: string) и возвращает (invoiceId: string, amount: Money). Ни один модуль ничего не знает о внутренностях другого. Это золотой стандарт.

Почему слабее — не всегда лучше

Вот структурная ловушка: команды, понявшие лестницу coupling, иногда заключают «data coupling везде, всегда». Это неверно, и типичный сбой — фрагментация.

Рассмотрим сервис заказов в B2B-платформе. Агрегат Order содержит header, lineItems, pricing, taxDetails, approvalState и auditTrail. Если каждая внутренняя функция, обращающаяся к данным заказа, рефакторится так, чтобы принимать только минимальные нужные примитивы, получается:

• updateApprovalState(orderId, state, actorId, timestamp) — data coupled, чисто.
• recalcPricing(orderId, lineItems, customerId, discountCode) — data coupled, чисто.
• computeTax(lineItems, shippingAddress, taxClassification) — data coupled, чисто.

Теперь координация изменения, затрагивающего approval state, pricing и tax одновременно, требует оркестратора, вызывающего все три функции, собирающего результаты и пересобирающего обновлённый заказ. Оркестратор теперь жёстко связан со всеми тремя — он знает полный жизненный цикл заказа. Coupling переехал вверх по стеку вызовов, а не исчез.

Вопрос не «слабо ли это связано?», а «находится ли coupling в правильном месте и отражает ли он реальные инварианты, которые должны изменяться вместе?» Высокая cohesion (рассматривается в следующем уроке) — это противодействующая сила.