История про модульный монолит полезна тем, что возвращает право не спешить в микросервисы только потому, что это звучит современно.
Для реального проектирования глава помогает увидеть, как границы модулей, дисциплина зависимостей и осознанный переход к сервисам дают выигрыш в управляемости без мгновенного роста операционной сложности.
Для интервью и инженерных разборов она помогает обсуждать преждевременную декомпозицию, перегруз команд и ложное ощущение зрелости, которое часто прячется за словом «микросервисы».
Практическая польза главы
Практика проектирования
Отделяйте реальные ограничения домена от желания «сразу уйти в микросервисы».
Качество решений
Используйте модульный монолит как этап, пока размер команды и нагрузка не требуют отдельного сервиса.
Аргументация на интервью
Показывайте зрелость: выбор формы архитектуры по контексту, а не по моде.
Анализ отказов
Предупреждайте преждевременную декомпозицию и операционный перегруз команд.
О докладе
Modular Monoliths and Other Facepalms
Разбор доклада о том, почему «модульный монолит» - не новый стиль, а возвращение к инженерной дисциплине: скрытию информации, границам модулей и проверяемым зависимостям.
Доклад
Modular Monoliths and Other Facepalms
Выступление Kevlin Henney на NDC London о модульности, границах и цене распределённой архитектуры.
Главная мысль
Проблема чаще в границах, а не в формате развёртывания
Микросервисы не исправляют плохую декомпозицию автоматически, а только повышают стоимость ошибок.
В этой главе рассматривается не как компромисс «между старым и новым», а как дисциплинированная архитектурная форма. Henney напоминает, что , и явные правила зависимостей должны появиться раньше, чем команда выбирает сервисов. Иначе распределение легко превращается в .
Источник
Microservices
Определение микросервисов и базовые компромиссы независимого развёртывания.
Основные тезисы доклада
возвращает к инженерной базе
Фокус доклада в том, что модульность, и появились задолго до моды на микросервисы.
Микросервисы часто выбирали как принудительное разбиение
выглядит соблазнительно, когда внутри монолита уже нет здоровых границ, но сеть не создаёт эти границы за команду.
Ложная дихотомия: монолит или микросервисы
Архитектура оценивается по качеству , контрактов и зависимостей, а не по количеству процессов в окружении.
Классические принципы декомпозиции по-прежнему актуальны
Parnas, и компонентное мышление дают практические опоры для архитектуры сегодня.
Распределённость усиливает плохую архитектуру
Перенос слабой структуры в сеть часто создаёт : та же связанность остаётся, но эксплуатация становится дороже.
Практический вывод: сначала укрепить модульный монолит
Начните с ясных модулей и выделяйте сервисы постепенно, когда появились устойчивые драйверы для .
Как развивалась идея модульности
История показывает, что разговор о модулях начался задолго до микросервисов и постоянно возвращался к одному вопросу: где проходит стабильная граница ответственности.
D. Parnas — критерии декомпозиции и
Формализована идея, что модуль должен скрывать детали реализации и удерживать стабильную границу.
Liskov & Zilles — (ADT)
Проектирование через абстракции данных усилило контрактный стиль взаимодействия между частями программы.
Foote & Yoder —
Показано, как без дисциплины и границ система постепенно превращается в комок зависимостей.
Lewis & Fowler — микросервисы как
Ценность микросервисов связывается с независимым развёртыванием, а не с модным названием архитектурного стиля.
Simon Brown — о распределённой версии Big Ball of Mud
Если границы не выстроены заранее, распределённость увеличивает цену архитектурных ошибок.
как возврат к теме модульности
Рефрейм: это возвращение к базовой инженерной дисциплине, а не появление нового архитектурного стиля.
Выводы для разработчиков
- Модульность - свойство зависимостей и контрактов, а не инфраструктуры или числа сервисов.
- Превращайте архитектуру в проверяемые : циклы, направление импортов и запрет обхода слоёв.
- Названия недостаточно: границы должны быть выражены в коде, 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, Branch by Abstraction и безопасное выделение сервисов из унаследованного монолита.
- Building Microservices (short summary) - Целевое состояние сервисной архитектуры и операционные компромиссы после этапа модульного монолита.
- Стратегии декомпозиции - Практика выбора ограниченных контекстов и контроль межмодульных зависимостей, чтобы не получить распределённый монолит.
- Зачем нужны микросервисы и интеграция - Системная рамка: когда микросервисы действительно оправданы и какие интеграционные контуры придётся поддерживать.
- Learning Domain-Driven Design (short summary) - DDD-основа для доменных границ и владения изменениями, которая делает модульный монолит устойчивой архитектурной базой.
- Эволюционная архитектура на практике - Как зафиксировать архитектурные границы в виде fitness-функций и управлять структурной деградацией в CI.