Modular Monolith: Is This the Trend in Software Architecture?
Разбор SGLR-paper о modular monolith: обещания архитектуры, ключевые характеристики, ограничения и уроки кейса Service Weaver.
Практика чтения для этого источника ещё не опубликована
Ниже доступен готовый редакционный brief из прежнего каталога. Он даёт контекст, но не засчитывается как lab.
Открыть оригиналГотовый редакционный разбор
Он сохранён из прежней версии каталога и расположен после самостоятельной практики, чтобы не подменять чтение оригинала готовым пересказом.
Whitepaper
Modular Monolith: Is This the Trend in Software Architecture?
Короткий whitepaper 2024 года с SGLR-анализом тренда modular monolith.
Whitepaper
Modular Monolith: Is This the Trend in Software Architecture?
Короткий whitepaper 2024 года с SGLR-анализом тренда modular monolith.
Рубрика #Architecture. В центре статьи вопрос: может ли modular monolith стать жизнеспособным компромиссом и дать "лучшее из двух миров" между простотой монолита и преимуществами модульного масштабирования.
Первая страница whitepaper (клик по изображению откроет PDF).
Основа главы
Telegram пост #3516
Ключевые тезисы paper и прикладная часть про Service Weaver.
Основа главы
Telegram пост #3516
Ключевые тезисы paper и прикладная часть про Service Weaver.
Что даёт SGLR-подход в этой работе
- Авторы используют Systematic Grey Literature Review (SGLR): анализ материалов вне классических коммерческих академических изданий.
- В такие источники входят отчёты ведомств и НКО, диссертации, доклады конференций, технические спецификации, preprint-репозитории и сайты проектов.
- SGLR помогает проверить ранние индустриальные тренды, но качество и сопоставимость источников могут различаться, поэтому выводы трактуются как практические, а не финальные.
Какие преимущества ожидают от modular monolith
- Сохранение скорости разработки, характерной для монолитов.
- Чёткие границы модулей, чтобы не скатиться в big ball of mud.
- Гибкость: самостоятельная архитектура или промежуточный этап перед микросервисами.
- Более простая отладка и тестирование за счёт единого процесса исполнения.
- Эффективное масштабирование команд через ownership модулей без обязательной service-decomposition на старте.
Ключевые характеристики modular monolith
Segregation of modules
Независимые модули с собственными слоями (Domain, Infrastructure, API) и явными контрактами взаимодействия.
Modularity
Слабая связность между модулями и сильная внутри модуля; коммуникация через API/события вместо прямых хаотичных зависимостей.
Unified Database Schema
Единая схема БД на приложение, в отличие от подхода database-per-service.
Monolithic deployment
Все модули запускаются в рамках одного deployment-контура: на одной VM или на выделенных VM без полного перехода к service-per-deploy.
Unified application process
Единый процесс приложения для разных масштабов и этапов эволюции системы.
Enhanced maintainability
Авторы фиксируют признаки лучшей поддерживаемости по сравнению с неструктурированными классическими монолитами.
Зачем исследование вообще появилось
Исследование напрямую мотивировано анонсом Service Weaver от Google: идея писать систему как модульный монолит с опцией микросервисного deployment. Это и стало проверкой гипотезы: действительно ли такой подход устойчиво масштабируется в реальных командах.
Примеры из индустрии
В обзоре отмечались компании, которые используют подходы, близкие к modular monolith, хотя без прямой зависимости от Service Weaver.
Контекст
Service Weaver
Фреймворк, который популяризировал идею modular binary -> microservices deployment.
Контекст
Service Weaver
Фреймворк, который популяризировал идею modular binary -> microservices deployment.
Что показал кейс Service Weaver
По публичной коммуникации проекта было два этапа: переход в maintenance mode 5 декабря 2024 и последующее архивирование 6 июня 2025. Это важный сигнал: сильная архитектурная идея сама по себе не гарантирует массовый adoption без понятного migration path и сильного platform fit.
В формулировке команды проекта: прямое внедрение оказалось сложным, потому что требовало переписывания существенных частей существующих систем.
- Низкий adoption rate: для внедрения требовалось переписывать крупные части существующих приложений, поэтому прямое использование оказалось ограниченным.
- Ограничение только на Go-стек заметно сужало целевую аудиторию.
- Опасность абстракции local/remote: локальный вызов мог стать RPC с другими NFR-свойствами (latency, retries, failover) в новом deployment-режиме.
- Недостаточная функциональность относительно зрелых платформ: не хватало из коробки маршрутизации/retries уровня service mesh, mTLS и удобной наблюдаемости.
- Внутренняя конкуренция со стеком Google Cloud (Cloud Run, GKE Autopilot + Istio, Functions): во многих кейсах проще было остаться на привычных инструментах.
Практические выводы для архитекторов
- Модульный монолит остаётся рабочим компромиссом, только если границы модулей реально enforce-ятся в коде и процессах.
- Переход к микросервисам лучше запускать по evidence-driven триггерам (организационные и нагрузочные bottleneck'и), а не по моде.
- Нужно заранее проектировать правила module ownership, API-контракты и dependency governance.
- Инструмент, который скрывает границу local/remote, обязан явно закрывать сетевые NFR-семантики, иначе цена абстракции быстро растёт.
Связанные главы
Monorepo and Polyrepo in Large Enterprises
Как границы кода и команд влияют на эволюцию архитектуры в крупных организациях.
API Governance at Scale
Стандарты и governance-практики, которые становятся критичными после декомпозиции.
What Is Your Definition of Software Architecture?
Подход к архитектурным границам, trade-offs и управляемой эволюции системы.
Рабочая формула: modular monolith полезен, пока он остаётся модульным не только в диаграмме, но и в enforce-правилах кода, ownership и dependency governance.
Источники
Для связанного контекста полезно посмотреть Measuring Productivity: All Models are Wrong But Some are Useful — как пример того, почему архитектурные решения нужно оценивать не только концептуально, но и по измеримым organizational outcomes.