Введение
Монолит (monolithic architecture) – архитектурный стиль, при котором приложение проектируется и развёртывается как единый, неделимый артефакт. Вся бизнес-логика, пользовательский интерфейс и слой доступа к данным компилируются в один процесс. Монолиты были доминирующей архитектурой до широкого распространения контейнеров и облачных платформ.
Вопреки негативным коннотациям, монолитная архитектура – вполне жизнеспособный и нередко оптимальный выбор для команд на ранних стадиях разработки продукта.
История и контекст
Монолитные приложения – исторически первая форма программных систем. До появления HTTP-микросервисов, Docker и Kubernetes большинство enterprise-систем строились именно как монолиты: ERP-системы, CRM, финансовые платформы. Понятие «монолит» как антипаттерн сформировалось в 2010-е годы на волне популяризации микросервисов, хотя такие компании, как Basecamp и Stack Overflow, успешно используют монолиты под высокой нагрузкой по сей день.
Мартин Фаулер ввёл понятие «Majestic Monolith» для обозначения хорошо структурированного монолита с чёткими внутренними модулями – как альтернативу хаотичному «big ball of mud».
Как это работает
В монолитном приложении все модули выполняются в одном процессе и общаются через прямые вызовы функций – без сетевого взаимодействия. Типичная структура:
- Presentation layer – контроллеры и шаблоны UI;
- Business logic layer – сервисы и доменная логика;
- Data access layer – репозитории, ORM, одна общая БД.
Развёртывание монолита – это деплой одного артефакта (JAR, WAR, Docker-образ). Масштабирование осуществляется горизонтально: запускаются несколько идентичных экземпляров приложения за балансировщиком нагрузки.
Модульный монолит
Современный подход – модульный монолит: приложение разбито на чёткие модули с инкапсулированными зависимостями, каждый из которых теоретически может стать микросервисом. Это сохраняет простоту монолита и обеспечивает переход к микросервисам без рефакторинга всего кода сразу.
Где применяется
- Стартапы и MVP – скорость разработки важнее масштабируемости;
- Внутренние бизнес-инструменты с небольшой командой;
- Приложения с предсказуемой нагрузкой без пиковых всплесков;
- Российские enterprise-системы: 1С-конфигурации, ERP-решения;
- Команды без зрелой DevOps-культуры, где операционная сложность микросервисов неоправдана.
Преимущества и ограничения
Преимущества: простота разработки и отладки (один процесс), нет сетевых задержек между компонентами, простое развёртывание, меньше инфраструктурных зависимостей, проще транзакционность (одна БД).
Ограничения: по мере роста кодовая база становится трудноуправляемой; изменение одного модуля требует перерелиза всего приложения; сложно применять разные технологии для разных компонентов; горизонтальное масштабирование всего монолита расточительно, если узкое место только в одном модуле.
Связь с другими понятиями
Монолит противопоставляется микросервисам – декомпозиция монолита по Bounded Context из Domain-Driven Design – самый распространённый путь миграции. Event-driven Architecture и CQRS могут применяться и внутри монолита. Практика «Strangler Fig Pattern» позволяет постепенно выносить части монолита в отдельные сервисы. Техдолг особенно опасен в монолитах из-за высокой связанности кода.
