История про modular monolith полезна тем, что возвращает право не спешить в микросервисы только потому, что это звучит современно.
Для реального проектирования глава помогает увидеть, как границы модулей, дисциплина зависимостей и осознанный переход к сервисам могут дать тот же выигрыш в управляемости без мгновенного роста операционной сложности.
Для интервью и инженерных разборов она полезна тем, что помогает обсуждать преждевременную декомпозицию, перегруз команд и ложное ощущение зрелости, которое часто прячется за словом microservices.
Практическая польза главы
Практика проектирования
Отделяйте реальные ограничения домена от hype-driven решения «сразу в микросервисы».
Качество решений
Используйте modular monolith как этап, когда team size и нагрузка еще не оправдывают распил.
Interview articulation
Показывайте зрелость: выбор формы архитектуры по контексту, а не по моде.
Failure framing
Предупреждайте anti-pattern: преждевременная декомпозиция и операционный перегруз команд.
Modular Monoliths and Other Facepalms
Разбор доклада о том, почему "модульный монолит" - это не новый стиль, а возвращение к инженерной дисциплине: информационное сокрытие, границы модулей и проверяемые зависимости.
Доклад
Modular Monoliths and Other Facepalms
Выступление Kevlin Henney на NDC London о модульности, границах и цене распределенности.
Главная мысль
Проблема чаще в декомпозиции, а не в формате деплоя
Микросервисы не лечат плохие границы автоматически, а только повышают стоимость ошибок.
Ограничение
Таймкоды оценочные
Без официального транскрипта смысловые блоки видео разобраны приблизительно и отмечены отдельно.
Источник
Microservices
Определение microservices и базовые trade-offs independent deployability.
Основные тезисы доклада
"Modular monolith" - это возвращение к инженерной базе
Фокус на том, что модульность, information hiding и компонентность существовали задолго до микросервисов.
Микросервисы часто выбирали как forced partitioning
Частый мотив: принудительно разделить систему, когда внутри монолита уже нет здоровых границ.
Ложная дихотомия: "монолит vs микросервисы"
Архитектура оценивается по качеству границ и зависимостей, а не по количеству процессов.
Исторические принципы декомпозиции по-прежнему актуальны
Пэрнас, ADT и компонентное мышление как практические опоры для архитектуры сегодня.
Распределенность усиливает плохую архитектуру
Перенос плохой структуры в сеть порождает тот же хаос, но дороже в эксплуатации.
Практический вывод: сначала модульный монолит
Старт с модульного монолита и инкрементальное выделение сервисов по устойчивым драйверам.
Визуализация таймлайна
Эволюция "модульности" как дисциплины (в терминах первоисточников)
D. Parnas — критерии декомпозиции, information hiding
Формализация идеи, что модуль должен скрывать детали реализации и фиксировать стабильные границы.
Liskov & Zilles — abstract data types (ADT) и расширяемые абстракции
Усиление подхода к проектированию через абстракции данных и контрактный стиль взаимодействия.
Foote & Yoder — паттерн Big Ball of Mud (антипаттерн эволюции)
Показано, как без дисциплины и границ система естественно скатывается в комок зависимостей.
Lewis & Fowler — определение microservices как набора independently deployable services
Подчеркивает, что ценность микросервисов связана с независимым деплоем, а не с модным ярлыком.
Simon Brown — "distributed big balls of mud" как риск распределенной деградации
Распределенность увеличивает цену архитектурных ошибок, если границы не выстроены заранее.
"Modular monolith" как маятник/ребрендинг обсуждения модульности
Рефрейм: это возврат к базовой инженерной дисциплине, а не появление нового архитектурного стиля.
Выводы для разработчиков
- Модульность - свойство зависимостей и контрактов, а не инфраструктуры и числа сервисов.
- Превращайте архитектуру в проверяемые правила: циклы, запрет обхода слоев, направление импортов.
- Называть систему modular monolith недостаточно: границы должны быть жестко выражены в коде и CI.
- Выделяйте сервисы только по стабильным бизнес-границам и явной потребности в независимом деплое.
Выводы для техлидов
- Сделайте modular monolith дефолтной стратегией, а микросервисы - обоснованной инвестицией.
- Закладывайте бюджет на стоимость распределенности: observability, security, delivery-platform, data-consistency.
- Управляйте архитектурой метриками структуры: запрещенные зависимости, циклы, drift между модулями.
- Формализуйте ownership модулей и политику архитектурных нарушений (baseline + план снижения долга).
Практический план на 2-4 недели
- 1Зафиксируйте 3-7 модульных границ и соберите граф зависимостей по коду.
- 2Добавьте 5-10 архитектурных правил в CI (слои, cycles, forbidden imports).
- 3Включите baseline-подход: запрет роста нарушений + план их поэтапного сжигания.
- 4Проверьте кандидатов на выделение в сервисы только там, где есть независимые SLA/релизные циклы.
Когда оставаться в монолите, а когда выделять сервисы
Modular monolith как дефолт
Если независимый деплой не является устойчивым требованием, лучше инвестировать в модульные границы, тесты архитектуры и ownership внутри одного процесса.
Микросервисы как осознанный шаг
Выделяйте сервисы, когда есть четкие драйверы independent deployability, отдельные SLA, масштабирование по частям и готовность к стоимости распределенности.
Риски и ограничения
- Таймкоды по сценам доклада носят реконструктивный характер и не являются стенограммой.
- Переход в микросервисы без зрелых границ часто приводит к distributed monolith и росту операционной нагрузки.
- Ярлык "модульный монолит" без тестируемых правил зависимостей быстро превращается в маркетинговую формулировку.
Связанные главы
- Monolith to Microservices (short summary) - Пошаговый migration-playbook: Strangler Fig, branch by abstraction и безопасное выделение сервисов из legacy-монолита.
- Building Microservices (short summary) - Целевое состояние сервисной архитектуры и операционные компромиссы после перехода от модульного монолита.
- Стратегии декомпозиции - Практика выбора bounded contexts и контроль межмодульных зависимостей, чтобы не получить distributed monolith.
- Зачем нужны микросервисы и интеграция - Системная рамка, когда микросервисы реально оправданы и какие интеграционные контуры придется поддерживать.
- Learning Domain-Driven Design (short summary) - DDD-основа для доменных границ и ownership, которая делает модульный монолит устойчивой архитектурной базой.
- Эволюционная архитектура на практике - Как зафиксировать архитектурные границы в виде fitness-функций и управлять структурной деградацией в CI.