Инверсия зависимостей

Две половины DIP

Принцип инверсии зависимостей Роберта Мартина состоит из двух утверждений, и оба должны выполняться:

1. Высокоуровневые модули не должны зависеть от низкоуровневых. Оба должны зависеть от абстракций.
2. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Первое утверждение привычно — это правило зависимостей из предыдущего урока в форме модулей. Высокоуровневые модули (billing на B2B-платформе) содержат политику: бизнес-логику, определяющую, что должно произойти. Низкоуровневые модули (репозиторий заказов, платёжный шлюз) содержат механизм: техническую сантехнику, которая делает это возможным. Политика не должна быть связана с механизмом.

Второе утверждение тоньше — и именно его нарушила вводная история. Размещение интерфейса в пакете низкоуровневого модуля делает абстракцию деталью низкоуровневого модуля. Высокоуровневый потребитель импортирует интерфейс из низкоуровневого модуля. Низкоуровневый модуль по-прежнему может сломать потребителя, реструктурировав пакет, переименовав интерфейс или разбив его на несколько. Абстракция технически присутствует, но владение не инвертировано.

DIP требует, чтобы высокоуровневый модуль владел абстракцией, от которой зависит.

Кому принадлежит интерфейс?

Владение интерфейсом — это суть DIP. Интерфейс принадлежит тому, кто его определяет и контролирует его эволюцию. Когда спрашиваешь «должен ли этот интерфейс измениться?», ответ должен исходить из потребностей потребителя, а не из удобства реализации поставщика.

На B2B-платформе модуль billing нуждается в данных заказов. Интерфейс, который ему нужен — IOrderProvider или IOrderPort — должен жить в пакете billing (или в выделенном пакете границы, который billing контролирует). Он объявляет ровно то, что нужно billing: getConfirmedOrder(id: string): Promise<ConfirmedOrderDTO>. Не больше. Модуль order затем реализует этот интерфейс, написав класс, удовлетворяющий контракту billing.

Стрелки зависимостей теперь:

BillingService   ──imports──→   IOrderPort   (принадлежит billing)
                                      ↑
                              implements
                                      │
                         PostgresOrderRepository   (в модуле order)

Репозиторий модуля order зависит от интерфейса billing — а не наоборот. Если нужды billing изменятся, интерфейс меняется и репозиторий должен обновиться. Если команда order меняет внутренний способ получения данных заказов, она обновляет реализацию репозитория; интерфейс billing не трогается.

Compile-time граница vs runtime граница

DIP по сути — о проведении границы, которую может соблюдать компилятор. На одной стороне: высокоуровневый модуль и принадлежащий ему интерфейс. На другой: низкоуровневый модуль, реализующий его. Ни одной стороне не нужно знать о конкретных деталях другой.

Различие между тем, что известно на этапе компиляции, и тем, что разрешается в runtime, — ключ к модульности:

На этапе компиляции BillingService знает только об IOrderPort. Он знает сигнатуры методов, типы параметров, возвращаемые типы. Он знает контракт. Он не знает, что PostgresOrderRepository существует. Компилятор не видит PostgresOrderRepository из контекста billing.

В runtime что-то должно связать IOrderPort с PostgresOrderRepository. Это работа dependency injection: composition root или контейнер разрешает, какая конкретная реализация удовлетворяет какому интерфейсу, и передаёт её в billing. В этот момент управление течёт от billing через интерфейс к реализации репозитория.

Это разделение — суть того, что делает hexagonal architecture (unit 04) и clean architecture (unit 05) структурно соблюдаемыми. Гексагон в hexagonal architecture — высокоуровневый домен, окружённый принадлежащими ему определениями интерфейсов (портами). Адаптеры — конкретные реализации — живут вне гексагона и зависят от портов внутрь. Концентрические круги в clean architecture — слои, где каждый внутренний круг владеет интерфейсами, которые реализуют внешние. DIP — механизм, делающий эти паттерны структурно соблюдаемыми.

DIP на B2B-платформе: до и после

До DIP платформа имела такую структуру:

• billing/ импортирует order/infra/postgres-order-repo.ts → конкретное к конкретному
• billing/ импортирует payment/stripe-gateway.ts → конкретное к конкретному
• order/ импортирует db/postgres-driver.ts → конкретное к конкретному

Каждый модуль мог сломать каждый другой через изменения реализации. Добавление нового платёжного провайдера требовало изменений в billing. Замена БД требовала затронуть всё.

После DIP:

• billing/ports/IOrderPort.ts — принадлежит billing; определяет getConfirmedOrder
• billing/ports/IPaymentPort.ts — принадлежит billing; определяет chargeCustomer
• order/adapters/BillingOrderAdapter.ts — реализует IOrderPort, живёт в модуле order, но зависит от интерфейса billing
• payment/adapters/StripePaymentAdapter.ts — реализует IPaymentPort, живёт в модуле payment, но зависит от интерфейса billing

Billing теперь не имеет compile-time знания о внутренностях модуля order или модуля payment. Модули order и payment зависят от определений границы billing. Добавление нового платёжного провайдера означает написание нового адаптера, реализующего IPaymentPort — сам billing не меняется.