Границы доменов в модульном монолите

Модульный монолит работает только при строгих границах. Если модуль напрямую читает внутренности другого, архитектура деградирует так же быстро, как и в «обычном» монолите.

Проще говоря

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

Что считать границей

• публичный API модуля,
• собственная модель данных,
• явные правила зависимости.

Кейс из практики

Коротко про вводные.

Контекст: Команда разделила billing и subscriptions в отдельные модули, но оставила прямой доступ к таблицам. Через 3 месяца любое изменение в billing ломало subscriptions. После перехода на API-слой и события внутри монолита регрессии резко сократились.

Минимальный чеклист

• нет прямых кросс-модульных SQL-запросов
• зависимости проверяются архитектурным тестом
• публичные контракты версионируются

Короткая история из команды

В реальном проекте решение сработало только после того, как его закрепили в процессах команды, а не оставили на уровне договорённостей.

Вывод

Модульность — это не структура папок, а дисциплина границ и контрактов.

Как проверить, что границы реальные

Если изменение в одном модуле регулярно требует правок в трёх соседних — границы фиктивные. Полезный индикатор: количество кросс-модульных изменений в одном PR.

Снижение этого показателя обычно означает, что модульность работает и команда получает выигрыш в независимости поставки.

Как применять это в живом проекте

Обычно команда упирается не в идею решения, а в внедрение: кто владелец, где проверить эффект, как не сломать соседние модули. Поэтому лучше запускать изменения через один критичный поток, где есть понятная боль и измеримый результат.

Хорошая последовательность: сначала фиксируем baseline, затем внедряем минимально жизнеспособную версию решения, после чего смотрим на метрики 1–2 недели. Если эффект подтверждается, масштабируем на соседние сценарии. Если нет — откатываем без драм и пересобираем гипотезу.