Правило зависимостей

Два разных потока: поток управления и зависимость в исходном коде

Путаница, порождающая большинство проблем с зависимостями, — это смешение двух различных вещей, происходящих в коде одновременно: flow of control и flow of source-code dependency.

Flow of control — это то, что выполняется в runtime. Когда модуль billing вызывает orderService.getOrder(id), управление переходит от billing в order service. Это путь выполнения — кто вызывает кого.

Flow of source-code dependency — это то, что видит компилятор. Когда billing содержит import { OrderService } from '../order/orderService', billing имеет зависимость в исходном коде на модуль order. На этапе компиляции, если orderService.ts изменит свой экспортируемый интерфейс, billing потребует перекомпиляции. Это путь зависимости — кто знает о ком.

Эти два потока независимы. Они могут указывать в одну сторону, а могут — в противоположные. Правило зависимостей касается второго потока, а не первого. Управление всегда будет течь туда, куда диктуют runtime-вызовы. Но ты выбираешь, в каком направлении движется знание — импорт, requires, ссылка на тип — между модулями.

Критический вопрос: если модуль изменится, какие другие модули вынуждены знать об этом?

Правило зависимостей: указывай в сторону стабильности

Правило зависимостей Роберта Мартина, впервые сформулированное в контексте Clean Architecture, — это принцип, формализующий направление зависимостей в исходном коде:

Зависимости в исходном коде должны указывать в направлении стабильности.

Стабильность здесь имеет конкретное значение: модуль стабилен, если он маловероятно изменится. Две силы делают модуль стабильным:

• Высокий afferent coupling (Ca): на него зависит много модулей, поэтому он испытывает сильное давление оставаться на месте — его изменение ломает слишком много вызывающих.
• Абстрактность, а не конкретность: он определяет интерфейс или контракт, а не реализацию. Интерфейсы не меняются из-за деталей реализации; они меняются только тогда, когда сам контракт должен эволюционировать.

Правило зависимостей следует из этого: если модуль A зависит от модуля B, то при каждом изменении B модуль A может быть вынужден измениться тоже. Чтобы минимизировать принудительные изменения, A должен зависеть от вещей, которые меняются реже всего — от стабильных, абстрактных — а не от вещей, которые меняются чаще всего — от volatile, конкретных.

На B2B-платформе модуль billing должен зависеть от концепции «что-то, предоставляющее данные о заказе» — интерфейса — а не от конкретного PostgresOrderRepository, который реализует это сегодня. Если реализация переключится на другую БД или команда order проведёт рефакторинг внутренностей репозитория, billing останется нетронутым. Зависимость billing — на контракт, который стабилен, а не на реализацию, которая volatile.

Конкретное зависит от абстрактного, но не наоборот

Практическая форма правила зависимостей: конкретные вещи зависят от абстрактных, никогда наоборот.

Абстрактный модуль (интерфейс, протокол, порт в терминологии hexagonal) — это контракт. Он определяет, что что-то делает, не уточняя как. Он меняется только когда контракт эволюционирует — что происходит редко и намеренно.

Конкретный модуль (класс, сервис, реализация репозитория) — это единица выполнения. Он реализует контракт с использованием конкретной технологии, алгоритма или внешней зависимости. Он меняется каждый раз, когда нужно изменить реализацию — что происходит часто.

Если конкретный модуль A зависит от другого конкретного модуля B, A должен меняться при каждом изменении реализации B. Это создаёт цепочки принудительных изменений, распространяющихся по кодовой базе. Разворот направления — конкретное зависит от абстрактного — разрывает цепочку.

Зависимость billing от IOrderRepository вместо PostgresOrderRepository — пример: PostgresOrderRepository реализует IOrderRepository. Цепочка зависимостей:

BillingService → IOrderRepository ← PostgresOrderRepository

Оба — billing и реализация Postgres — зависят от интерфейса. Ни один не зависит от другого. Реализацию можно подменить тест-дублером, другой БД или REST API клиентом — и billing не изменится.