System Design Space

    Глава 209

    Обновлено: 16 февраля 2026 г. в 00:50

    Modular Monoliths and Other Facepalms (short summary)

    Прогресс части0/17

    Почему modular monolith — это возвращение к инженерной дисциплине: границы, зависимости и осознанный переход к микросервисам.

    Modular Monoliths and Other Facepalms - YouTube cover
    Смотреть на YouTube

    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 и компонентное мышление как практические опоры для архитектуры сегодня.

    Распределенность усиливает плохую архитектуру

    Перенос плохой структуры в сеть порождает тот же хаос, но дороже в эксплуатации.

    Практический вывод: сначала модульный монолит

    Старт с модульного монолита и инкрементальное выделение сервисов по устойчивым драйверам.

    Визуализация таймлайна

    Эволюция "модульности" как дисциплины (в терминах первоисточников)

    1972

    D. Parnas — критерии декомпозиции, information hiding

    Формализация идеи, что модуль должен скрывать детали реализации и фиксировать стабильные границы.

    1974

    Liskov & Zilles — abstract data types (ADT) и расширяемые абстракции

    Усиление подхода к проектированию через абстракции данных и контрактный стиль взаимодействия.

    1997

    Foote & Yoder — паттерн Big Ball of Mud (антипаттерн эволюции)

    Показано, как без дисциплины и границ система естественно скатывается в комок зависимостей.

    2014

    Lewis & Fowler — определение microservices как набора independently deployable services

    Подчеркивает, что ценность микросервисов связана с независимым деплоем, а не с модным ярлыком.

    2014

    Simon Brown — "distributed big balls of mud" как риск распределенной деградации

    Распределенность увеличивает цену архитектурных ошибок, если границы не выстроены заранее.

    2026

    "Modular monolith" как маятник/ребрендинг обсуждения модульности

    Рефрейм: это возврат к базовой инженерной дисциплине, а не появление нового архитектурного стиля.

    Выводы для разработчиков

    • Модульность - свойство зависимостей и контрактов, а не инфраструктуры и числа сервисов.
    • Превращайте архитектуру в проверяемые правила: циклы, запрет обхода слоев, направление импортов.
    • Называть систему modular monolith недостаточно: границы должны быть жестко выражены в коде и CI.
    • Выделяйте сервисы только по стабильным бизнес-границам и явной потребности в независимом деплое.

    Выводы для техлидов

    • Сделайте modular monolith дефолтной стратегией, а микросервисы - обоснованной инвестицией.
    • Закладывайте бюджет на стоимость распределенности: observability, security, delivery-platform, data-consistency.
    • Управляйте архитектурой метриками структуры: запрещенные зависимости, циклы, drift между модулями.
    • Формализуйте ownership модулей и политику архитектурных нарушений (baseline + план снижения долга).

    Практический план на 2-4 недели

    1. 1Зафиксируйте 3-7 модульных границ и соберите граф зависимостей по коду.
    2. 2Добавьте 5-10 архитектурных правил в CI (слои, cycles, forbidden imports).
    3. 3Включите baseline-подход: запрет роста нарушений + план их поэтапного сжигания.
    4. 4Проверьте кандидатов на выделение в сервисы только там, где есть независимые SLA/релизные циклы.

    Когда оставаться в монолите, а когда выделять сервисы

    Modular monolith как дефолт

    Если независимый деплой не является устойчивым требованием, лучше инвестировать в модульные границы, тесты архитектуры и ownership внутри одного процесса.

    Микросервисы как осознанный шаг

    Выделяйте сервисы, когда есть четкие драйверы independent deployability, отдельные SLA, масштабирование по частям и готовность к стоимости распределенности.

    Риски и ограничения

    • Таймкоды по сценам доклада носят реконструктивный характер и не являются стенограммой.
    • Переход в микросервисы без зрелых границ часто приводит к distributed monolith и росту операционной нагрузки.
    • Ярлык "модульный монолит" без тестируемых правил зависимостей быстро превращается в маркетинговую формулировку.

    References

    Связанные главы: Monolith to Microservices, Building Microservices, Decomposition Strategies, Evolutionary Architecture Practice.