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

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

Чтобы контролировать такие зависимости, внедрили Deptrac. В конфигурации описали слои и разрешённые направления зависимостей. Например: доменный код работает через контракт, а реализация доступа к кешу остаётся в инфраструктуре.

Проверку подключили к CI. При появлении запрещённой зависимости разработчик получает конкретное нарушение: какой класс использует компонент из недопустимого слоя.

Так у выделенных частей системы появились автоматически проверяемые границы. Рефакторинг оставался постепенным, а его результат закреплялся в правилах.

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

Такие дела!