Modular Monoliths and Other Facepalms - Kevlin Henney - NDC London 2026 (Рубрика #Architecture)

Интересное видео Kevlin Henney, где он выступает евангелистом монолитов, модульных монолитов:) Если сокращать, то он говорит, что проблема была не в монолитах, а в запутанных зависимостях и размытых границах. Союственно, микросервисы не лечат плохую декомпозицию. Но они просто делают ошибки дороже (сеть, консистентность, наблюдаемость, эксплуатация). Забавно, что свой первый монолит в Т-Банке я начал пилить как раз для того, чтобы довести эту стоимость до предела и перейти Рубикон (первая бекенд система, что мне досталась была сделана фронтедерами для фронтендеров и напоминала лапшу - по-другому выставить границы было нельзя).Но если возвращаться к рассказу Кевлина, то его совет в том, чтобы начинать с хорошо структурированного модульного монолита → и только потом (если есть устойчивые драйверы) выделяйте сервисы.

Отдельно мне понравилась история вокруг эволюции подходов, так как я сам люблю так выстраивать сторителлинг для своих докладов
- 1972 - Дэвид Пэрнас: критерии декомпозиции + information hiding (прячем то, что часто меняется)
- 1974 - Лисков и Зиллс: abstract data types (ADT), работа с абстракциями данных
- 1997 - Foote & Yoder: антипаттерн Big Ball of Mud (система "уползает" в комок без дисциплины)
- 2014 - Fowler/Lewis: микросервисы как набор independently deployable сервисов (а не "мелкие модули по сети")
- 2014+ - Simon Brown: предупреждение про distributed big ball of mud

Если говорить про инсайты, то они примерно такие
🧩 Модульность - свойство кода и зависимостей, а не инфраструктуры
Если внутри одного процесса вы не удерживаете границы, микросервисы не спасут - они просто добавят частичные отказы и сложность диагностики.

🕸 Архитектура проявляется в зависимостях сильнее, чем в диаграммах
Значит архитектуру можно (и нужно) делать проверяемой: правила → CI → "ломаем билд" на нарушениях.

🧩 “Монолит” становится проблемой, когда он превращается в tangled monolith
То есть не "один деплой" плохо, а переплетённость (циклы, обход границ, случайные импорты, нарушение слоёв).

🤑 Микросервисы - это инвестиция (техническая + организационная).
Они оправданы, когда реально нужно независимо деплоить, изолировать изменения, масштабировать по частям, разводить ответственность команд.
Если драйверов нет - вы покупаете overhead без выигрыша.

Для разработчиков следуют такие практические выводы
- Цель: сделать “границы” реальными, а не декоративными
Модуль = единица эволюции, а не папка. Есть публичный API, есть скрытая внутрянка, есть запреты на “обход”.
- Направление зависимостей важнее названий слоёв
Следите за циклами, “обратными” ссылками, протеканием инфраструктуры в домен.

Для технических руководителей следуют такие практические выводы
Архитектурные ярлыки не заменяют управления границами. Если мотивация “давайте микросервисы, чтобы код разделился сам” - это красный флаг.
Сначала: границы, ownership, правила, ревью‑политики, архитектурные тесты. Микросервисы по определению увеличивают:
- Число deploy‑единиц
- Количество коммуникаций
- Требования к CI/CD, observability, security, data contracts

Стратегия, которая обычно работает лучше:
- Modular monolith - дефолт
- Microservices - осознанная инвестиция при устойчивых драйверах

P.S.
Как обычно, расширенная версия есть на system-design.space.

#Architecture #Software #DistributedSystems #Engineering #Management