История про модульный монолит полезна тем, что возвращает право не спешить в микросервисы только потому, что это звучит современно.
Для реального проектирования глава помогает увидеть, как границы модулей, дисциплина зависимостей и осознанный переход к сервисам дают выигрыш в управляемости без мгновенного роста операционной сложности.
Для интервью и инженерных разборов она помогает обсуждать преждевременную декомпозицию, перегруз команд и ложное ощущение зрелости, которое часто прячется за словом «микросервисы».
Практическая польза главы
Практика проектирования
Отделяйте реальные ограничения домена от желания «сразу уйти в микросервисы».
Качество решений
Используйте модульный монолит как этап, пока размер команды и нагрузка не требуют отдельного сервиса.
Аргументация на интервью
Показывайте зрелость: выбор формы архитектуры по контексту, а не по моде.
Анализ отказов
Предупреждайте преждевременную декомпозицию и операционный перегруз команд.
О докладе
Modular Monoliths and Other Facepalms
Разбор доклада о том, почему «модульный монолит» — не новый стиль, а возвращение к инженерной дисциплине: скрытию информации, границам модулей и зависимостям, которые можно проверить в сборке, а не только пообещать на словах.
Доклад
Modular Monoliths and Other Facepalms
Выступление Kevlin Henney на NDC London о модульности, границах и цене распределённой архитектуры.
Главная мысль
Проблема чаще в границах, а не в формате развёртывания
Микросервисы не чинят плохую декомпозицию — они переносят её в сеть и делают каждую ошибку дороже в эксплуатации.
Команда упирается в монолит, который тяжело менять, и тянется к микросервисам как к лекарству. Здесь — не компромисс «между старым и новым», а дисциплинированная форма, которая решает ту же боль дешевле. Henney напоминает порядок действий: , и явные правила зависимостей должны встать на место раньше, чем команда выбирает сервисов. Пропустить этот шаг — значит получить : ту же связанность, но уже по сети.
Источник
Microservices
Определение микросервисов и базовые компромиссы независимого развёртывания.
Основные тезисы доклада
возвращает к инженерной базе
Доклад снимает ауру новизны: модульность, и придумали задолго до моды на микросервисы — менялся не принцип, а его упаковка.
Микросервисы часто выбирали как принудительное разбиение
Когда внутри монолита уже нет здоровых границ, по сети кажется выходом. Но граница, которую команда не провела в коде, не появится из того, что вызов стал сетевым.
Ложная дихотомия: монолит или микросервисы
Спор «монолит или микросервисы» уводит в сторону: архитектуру держат качество , контрактов и зависимостей, а не число процессов в окружении.
Классические принципы декомпозиции по-прежнему актуальны
Parnas, и компонентное мышление — это не история ради истории, а рабочие опоры, когда нужно решить, где провести границу прямо сейчас.
Распределённость усиливает плохую архитектуру
Слабую структуру сеть не лечит, а растягивает: получается — та же связанность, но теперь к ней добавлены сетевые сбои, задержки и счёт за эксплуатацию.
Практический вывод: сначала укрепить модульный монолит
Сначала наведите порядок в модулях внутри одного процесса, а сервисы выделяйте по одному — когда у конкретного куска появилась устойчивая причина для .
Как развивалась идея модульности
Разговор о модулях идёт с 1970-х и каждый раз упирается в один и тот же вопрос: где провести стабильную границу ответственности. Менялись названия, вопрос — нет.
D. Parnas — критерии декомпозиции и
Сформулирован критерий: модуль скрывает решение, которое может измениться, и держит стабильную границу. Меняется реализация — соседи не ломаются.
Liskov & Zilles — (ADT)
Проектирование через абстракции данных усилило контрактный стиль взаимодействия между частями программы.
Foote & Yoder —
Показано, как без дисциплины и границ система незаметно сползает в комок зависимостей, где любое изменение задевает всё сразу.
Lewis & Fowler — микросервисы как
Ценность микросервисов связывается с независимым развёртыванием, а не с модным названием архитектурного стиля.
Simon Brown — о распределённой версии антипаттерна Big Ball of Mud
Если границы не выстроены заранее, распределённость не убирает архитектурные ошибки, а делает каждую из них дороже в отладке и эксплуатации.
как возврат к теме модульности
Рефрейм: это возвращение к базовой инженерной дисциплине, а не появление нового архитектурного стиля.
Выводы для разработчиков
- Модульность живёт в зависимостях и контрактах, а не в инфраструктуре или числе сервисов — переезд на платформу оркестрации (Kubernetes) её не добавит.
- Опишите архитектуру как , которые проверяет сборка: нет циклов, импорты идут в одну сторону, обход слоёв запрещён.
- Граница, которая существует только в названии папки, не граница: её должны удерживать код, CI и , иначе она размоется за пару спринтов.
- Выделяйте сервисы только по устойчивым бизнес-границам и реальной потребности в .
Выводы для техлидов
- Пусть будет вариантом по умолчанию, а каждый микросервис — отдельным решением, которое команда обосновала и согласилась оплачивать.
- Считайте распределённость как отдельную статью расходов: наблюдаемость, безопасность, и придётся оплачивать постоянно, а не один раз при распиле.
- Управляйте архитектурой через , запрещённые связи, циклы и между модулями.
- Формализуйте и политику нарушений: текущая плюс план снижения долга.
Практический план на 2-4 недели
- 1Зафиксируйте 3-7 и соберите граф зависимостей по коду.
- 2Добавьте 5-10 архитектурных правил в CI: слои, циклы и .
- 3Зафиксируйте базу нарушений: новые нарушения запрещены, старые уменьшаются по понятному плану.
- 4Проверяйте кандидатов на выделение в сервисы только там, где есть отдельные соглашения об уровне сервиса (SLA), релизные циклы и понятный владелец изменений.
Когда оставаться в монолите, а когда выделять сервисы
как базовая стратегия
Пока независимое развёртывание не стало устойчивым требованием, дешевле вкладываться в границы модулей, архитектурные тесты и понятное владение изменениями внутри одного процесса — это даёт ту же чистоту структуры без сетевого счёта.
Микросервисы как осознанный шаг
Выделяйте сервисы, когда есть чёткие драйверы независимого развёртывания, отдельные соглашения об уровне сервиса (SLA), масштабирование по частям и готовность платить за распределённость.
Риски и ограничения
- Переход к микросервисам без зрелых границ даёт распределённый монолит: связанность остаётся, а сверху появляются сетевые отказы, распределённые транзакции и дежурства, которых раньше не было.
- Ярлык «модульный монолит» без проверяемых правил зависимостей быстро превращается в маркетинговую формулировку.
Источники
- YouTube - Modular Monoliths and Other Facepalms (Kevlin Henney)
- Martin Fowler - Microservices
- Simon Brown - Distributed Big Balls of Mud
- Big Ball of Mud (Foote & Yoder)
- Parnas paper (annotated copy)
- ArchUnit (Java)
- ArchUnitNET (C#)
- dependency-cruiser (JS/TS)
- import-linter (Python)
- Building Microservices, 2nd Edition (Sam Newman)
Связанные главы
- Monolith to Microservices (short summary) - Пошаговый план миграции: паттерн Strangler Fig, ветвление через абстракцию и безопасное выделение сервисов из унаследованного монолита.
- Building Microservices (short summary) - Куда движется сервисная архитектура после модульного монолита и за какие операционные компромиссы придётся платить, когда сервисы всё-таки выделены.
- Стратегии декомпозиции - Практика выбора ограниченных контекстов и контроль межмодульных зависимостей, чтобы не получить распределённый монолит.
- Зачем нужны микросервисы и интеграция - Системная рамка: когда микросервисы действительно оправданы и какие интеграционные контуры придётся поддерживать.
- Learning Domain-Driven Design (short summary) - DDD-основа для доменных границ и владения изменениями, которая делает модульный монолит устойчивой архитектурной базой.
- Эволюционная архитектура на практике - Как зафиксировать архитектурные границы в виде fitness-функций и управлять структурной деградацией в CI.