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