Монолит часто звучит почти как диагноз. Если система растёт, разговор быстро приходит к микросервисам: разделим приложение, дадим командам независимость, будем выпускать изменения отдельно.
Проблема в том, что вместе с независимостью мы покупаем распределённую систему — сеть, отдельные деплои, наблюдаемость, межсервисные ошибки, согласованность данных и гораздо больше операционной работы.
Иногда бизнесу всё это действительно нужно. А иногда достаточно хорошо разделить одну систему внутри.
Что такое Modular Monolith
Modular Monolith — это всё ещё одно приложение, которое обычно разворачивается как единое целое. Но внутри оно разделено на чёткие модули с понятными границами и правилами взаимодействия.
Например, заказы, платежи, каталог и клиенты могут жить в одной системе, но не должны свободно лазить во внутренности друг друга.
Главная идея проста: сначала создать архитектурную независимость внутри приложения и только потом, если появится реальная необходимость, переносить отдельные модули в отдельные сервисы.
Какую проблему мы решаем
Обычный монолит становится проблемой не потому, что он один. Он становится проблемой, когда в нём исчезают границы.
Изменение в одном месте неожиданно ломает другое. Несколько команд постоянно работают в одних и тех же кусках кода. Непонятно, кому принадлежит функциональность. Любая попытка что-то выделить требует распутывать годы зависимостей.
Modular Monolith пытается убрать именно эту связанность, не добавляя сетевую и инфраструктурную сложность раньше времени.
Что получает бизнес
Главная выгода для бизнеса — возможность дольше сохранять простую и относительно дешёвую архитектуру, не блокируя дальнейший рост продукта.
Компания меньше тратит на инфраструктуру и эксплуатацию распределённой системы, а команды меньше времени расходуют на техническую координацию между сервисами.
Это означает больше ресурсов на продуктовые изменения, пока масштаб бизнеса действительно не требует другого подхода.
Есть и второй эффект: переход к микросервисам можно делать постепенно. Если один модуль начинает мешать масштабированию, требует отдельного цикла релизов или за него отвечает самостоятельная команда, его можно выделить позже — не переписывая всю систему сразу.
То есть бизнес сохраняет возможность будущего разделения, но не оплачивает эту сложность заранее.
Что получает команда
Команды получают понятные границы внутри системы: где заканчивается один модуль и начинается другой, кто за что отвечает и через какие интерфейсы можно взаимодействовать.
При этом разработка остаётся проще, чем в микросервисной среде. Не нужно поднимать десятки сервисов локально, расследовать сетевые таймауты или поддерживать сложные схемы distributed tracing только для того, чтобы понять обычный бизнес-процесс.
Транзакции и работа с данными тоже часто проще, потому что система остаётся в одном процессе и может использовать одну инфраструктурную платформу.
Но это работает только при дисциплине. Если модули формально существуют, а код продолжает обращаться к чему угодно напрямую, через год останется всё тот же связанный монолит.
Что получает клиент
Клиент почти никогда не заметит, монолит перед ним или микросервисы. Он заметит другое: как быстро появляются изменения и насколько стабильно работает продукт.
Если более простая архитектура позволяет команде быстрее выпускать функции и реже создавать проблемы на стыках сервисов, для клиента это вполне реальное преимущество.
И наоборот, переход на микросервисы сам по себе не делает продукт быстрее или надёжнее. Иногда первые месяцы он делает ровно обратное.
Чем мы за это платим
Цена Modular Monolith — ограничения общей системы.
Нельзя независимо масштабировать каждый модуль так же свободно, как отдельный сервис. Сложнее использовать совершенно разные технологические стеки. Релиз обычно остаётся общим, а серьёзная проблема в одном процессе потенциально может повлиять на всё приложение.
Есть и организационный риск: команде легко решить, что раз всё находится в одном приложении, то границы можно нарушить «один раз». Именно из таких исключений постепенно рождается обычный большой монолит.
Когда пора смотреть в сторону микросервисов
Микросервисы начинают выглядеть разумнее, когда отдельные части системы действительно живут разной жизнью.
- Разные команды должны выпускать изменения независимо.
- Отдельные части требуют принципиально разного масштабирования.
- Сбой одного домена не должен влиять на остальные.
- У модулей сильно различаются технологические требования.
- Общий релиз и общая кодовая база уже заметно тормозят бизнес.
Ключевое слово здесь — уже. Не «когда-нибудь может понадобиться», а проблема уже существует и стоит компании денег или скорости.
Что стоит спросить перед решением
- Какая конкретная проблема монолита мешает бизнесу сегодня?
- Можно ли решить её модульными границами без распределения системы?
- Нужны ли командам действительно независимые релизы?
- Есть ли части системы с сильно отличающейся нагрузкой?
- Готова ли организация оплачивать observability, DevOps и эксплуатацию распределённой системы?
В итоге
Modular Monolith — не компромисс для тех, кто «не дорос» до микросервисов.
Это вполне сознательное архитектурное решение: сохранить простоту единой системы, но не превращать её в бесформенный комок зависимостей.
Если бизнесу пока не нужна реальная независимость сервисов, микросервисы могут оказаться не следующим уровнем зрелости, а просто более дорогим способом решить проблему, которой ещё нет.