Если я соберу рок-группу, она будет называться Modular Monolith.
Modular Monolith — это архитектурный стиль, при котором система остается единым приложением, но внутри разделена на независимые модули с четкими границами ответственности и минимальными зависимостями между ними.
Плюсы: 1) Взаимодействие модулей — без сетевых вызовов и дополнительной интеграционной логики. 2) Локальные транзакции — без распределенных транзакций и механизмов согласования. 3) Минималистичная инфраструктура — меньше сервисов, компонентов и операционных затрат. 4) Удобство тестирования и отладки — проще воспроизводить ошибки и проверять бизнес-сценарии. 5) Простота изменений — рефакторинг и изменение границ модулей обходятся значительно дешевле.
Минусы: 1) Масштабирование только целиком — модули нельзя масштабировать независимо. 2) Развертывание только целиком — модули нельзя релизить независимо. 3) Ограниченная независимость команд — общая кодовая база требует постоянной координации и дисциплины. 4) Единая точка отказа — сбой в одном модуле влияет на все приложение.
Вопреки распространенному заблуждению, Modular Monolith — не просто папки с кодом. Модуль строится вокруг границы ответственности. В терминах DDD такие границы часто совпадают с Bounded Context, хотя это необязательно.
Modular Monolith — оптимальный выбор на начальном этапе разработки, когда понимание предметной области еще формируется. На этом этапе приоритетом становится не масштабирование и не независимое развертывание, а гибкость: возможность быстро менять модель, уточнять требования и вместе с бизнесом находить правильные границы системы. Это позволяет понять, какие модули действительно важны, и осознанно инвестировать усилия команды.
Нет смысла угадывать идеальную архитектуру заранее. Сегодня тесты, фиксирующие поведение системы, и современные ИИ-инструменты для рефакторинга делают изменения архитектуры значительно дешевле. Это позволяет спокойно развивать систему по мере того, как понимание предметной области становится глубже.
Когда границы модулей становятся понятными и устойчивыми, выделение отдельных модулей в сервисы значительно упрощается. Но если начать разделять систему слишком рано, можно получить распределенный монолит — худший из возможных вариантов, который сочетает сложность распределенной системы с жесткой связанностью монолита.
