Разберите механизм, из-за которого цикл зависимостей препятствует независимой эволюции модулей. В системе заказов границы заданы так:
module Заказы
import Оплата
function создатьЗаказ() { Оплата.проверитьЛимит() }
module Оплата
import Заказы
function отменитьОплату() { Заказы.найтиЗаказ() }
Цикл превращает модули Заказы и Оплата в одну связанную компоненту: изменение любого из них потенциально требует анализа, сборки и тестирования другого. Поэтому они теряют независимость эволюции, а границы модулей перестают ограничивать распространение изменений.
Сам механизм — замыкание зависимостей по графу: путь из Заказы в Оплата и обратный путь образуют сильно связанную компоненту. Разорвать проблему можно изменением направления зависимости или выделением общего контракта, которым владеет отдельный стабильный модуль.
Модульность появилась как способ управлять сложностью больших программ: систему разделяют на части с локальной ответственностью и ограниченными связями. Для такой декомпозиции важно не только наличие отдельных файлов или пакетов, но и структура зависимостей между ними.
Принцип ацикличности зависимостей формализует практическое требование: граф модулей должен позволять двигаться от более зависимых частей к более стабильным без возврата в исходный модуль. Это уменьшает область изменений, упрощает сборку и делает выпуск частей системы более предсказуемым.
В примере Заказы вызывает Оплата, чтобы проверить лимит, а Оплата обращается к Заказы, чтобы найти заказ при отмене платежа. Каждая часть знает о внутреннем существовании другой, поэтому изменение публичного контракта одного модуля может потребовать синхронного изменения второго.
Неверно считать, что разбиение по каталогам автоматически создало независимые модули. При цикле тестирование, версионирование и поэтапный выпуск обычно приходится организовывать для всей связанной группы, а не для отдельного модуля.
Сначала строят граф зависимостей: вершины — модули, направленные рёбра — обращения к их контрактам. Если из одного модуля существует путь обратно, эти модули образуют сильно связанную компоненту. Внутри такой компоненты нельзя получить строго независимый порядок изменения: изменение границы в одной вершине может затронуть весь цикл.
Обычно цикл разрывают, перенося зависимость на абстракцию, принадлежащую более стабильной стороне. Например, модуль Заказы может публиковать факт изменения состояния заказа, а модуль Оплата будет реагировать на этот факт, не импортируя Заказы напрямую. Это меняет синхронную двустороннюю зависимость на однонаправленный контракт.
Другой вариант — выделить общий модуль с минимальным контрактом, например идентификатором заказа и результатом проверки. Он не должен содержать бизнес-логику Заказы или Оплата; иначе цикл лишь переместится в новый модуль.
События не являются универсальным лекарством. Они добавляют асинхронность, требования к идемпотентности, обработке повторов, наблюдаемости и согласованности данных. Если операция действительно требует немедленного ответа, лучше ввести направленный интерфейс или фасад, который владеет сценарием и скрывает взаимодействие модулей.
Минимальная схема разрыва цикла может выглядеть так:
Здесь Контракты не зависит от Заказы и Оплата, а между двумя бизнес-модулями нет прямого обратного импорта. Цена решения — необходимость явно определить семантику события и принять возможную задержку обновления состояния.
В системе подписок модуль Биллинг напрямую вызывал модуль Подписки для проверки статуса, а Подписки вызывал Биллинг для расчёта следующего платежа. Любое изменение модели подписки требовало совместного изменения обоих модулей, а изолированные тесты часто превращались в интеграционные.
Рассматривались три варианта. Общий модуль с моделями обоих доменов быстро устранял цикл, но усиливал общую связанность и размывал владение данными. Двусторонний фасад сохранял синхронность, но оставлял сложную координацию в одном месте и требовал строгого запрета на обход фасада. События уменьшали связанность, но требовали идемпотентных обработчиков и контроля задержки.
Выбрали фасад приложения, принадлежащий сценарию оформления платежа: он последовательно запрашивал Подписки и Биллинг, тогда как сами доменные модули больше не импортировали друг друга. Это сохранило синхронный ответ для пользователя, сделало направление зависимостей однонаправленным и позволило отдельно менять внутренние модели модулей.
Не обязательно: небольшой внутренний цикл может быть допустим внутри одной реализации, если его участники намеренно выпускаются и тестируются как единое целое. Проблемой он становится на границе предполагаемых независимых модулей, особенно когда участники имеют разные причины для изменения, владельцев или темп выпуска.
Поэтому оценивают не только наличие цикла, но и его стоимость: область регрессионного тестирования, сложность сборки, необходимость совместных релизов и распространение изменений. Если связанная группа осмысленно является одним модулем, правильнее явно объединить её, а не поддерживать искусственные границы.
Если интерфейс объявлен в одном из взаимозависимых модулей, второй всё ещё зависит от первого как от владельца контракта. Формальная замена конкретного класса интерфейсом не устраняет цикл, если направление зависимости в графе осталось прежним.
Контракт должен находиться на стороне, которая задаёт нужную политику, либо в отдельном стабильном модуле. Важно также уменьшить его до операций, необходимых потребителю: широкий интерфейс сохраняет скрытую связанность даже при отсутствии явного цикла.
Бизнес-взаимодействие само по себе не требует взаимных зависимостей. Например, Оплата может реагировать на событие от Заказы, а Заказы — получать отдельное состояние оплаты через направленный запрос или опубликованное событие.
Цикл появляется, когда оба модуля напрямую знают о контрактах друг друга и не определён владелец сценария или факта. Для диагностики фиксируют направление каждого вызова, владельца данных и требование к согласованности; затем выбирают фасад, запрос, событие или объединение модулей, исходя из этих условий.