Прочитал текст Александра Никитина про монолиты и микросервисы. Он прав: границы важнее технологий. Его чек-лист из 5 вопросов отличная диагностика.

Представим: мы распилили систему на 3 микросервиса, над каждым команда из 4 разработчиков. Прогоним те же 5 вопросов через мясорубку микросервисов. Спойлер: лекарство иногда страшнее болезни.

Инверсия чек-листа 1. Можем ли за 5 минут нарисовать схему зависимостей без документации? Микросервисы: Ха! В распределённой системе это «нереально». Каждая команда ведёт документацию как хочет: Swagger, Confluence, Notion или голова Васяна. Собрать картину целиком квест «Найди 10 отличий» между API-контрактом и реальностью.

2. Сколько человек одобряют PR на изменение логики оплаты? Больше двух — границы размыты. Микросервисы: Одобрение PR зависит от процессов команды, не от архитектуры! В Команде А строгий TDD, ревьюят двое. В Команде Б сеньор смотрит один: «я же говорил». В Команде В собирают 15 человек на дейли, чтобы обсудить одну колонку в БД. Это культура, не архитектура.

3. Как часто релизы откладываются из-за конфликтов в смежных фичах? Микросервисы: Собираем новые грабли! Команда 1 делает Шлюз платежей v2.0, Команды 2 и 3 — платёжные решения на v1.0. Шлюз обязан поддерживать обе версии. Релиз тормозится. Конфликты сместились с кода на сетевые контракты.

4. Есть ли модули, которые никто не хочет трогать? Микросервисы: Всё так же! Только у «дракона» теперь свой репозиторий, CI/CD и сервер. «Не лезь в `legacy-billing-core`, он на COBOL, документация потеряна в 2018-м». Микросервисы не убивают легаси, они дают ему квартиру с евроремонтом в Docker.

5. Хотят ли части продукта развиваться с разной скоростью? Микросервисы: Они обречены развиваться по-разному. Админка стабильна, API — каждую неделю. Но какой смысл в админке, если она не может отобразить новые фичи API, потому что контракт менялся три раза за день? Рассинхрон размывает бизнес-ценность.

Настоящий враг: не архитектура, а процесс Микросервисы часто имеют больше проблем, чем решений, если применять их как религию.

Работаю с монолитами и легаси регулярно. Вижу одну истину: сложно поддерживать не архитектуру, а плохие инженерные решения внутри неё.

Магазины на WordPress — Франкенштейн. К блогу на костылях прикрутили e-commerce, а потом ругают монолит WP. Проблема не в архитектуре, а в нецелевом использовании.

В микросервисах уходят в другую крайность: обмазываются Docker, Kubernetes, тратят 70% бюджета на инфраструктуру и DevOps, 30% — на фичи. Суть теряется за шумом сетевых вызовов.

Решение: Модульный монолит + Чистая архитектура Модульный монолит — проект из чётко ограниченных модулей. Каждый инкапсулирует бизнес-логику (DDD), общается через публичные интерфейсы, покрыт тестами (TDD).

Плюсы: 1. Поддерживать проще, чем лоскутное одеяло сервисов 2. «Выпилить» модуль в микросервис можно когда бизнес готов платить (независимые нагрузки, команда 15+ человек). До этого — просто папка в коде 3. Чистая архитектура критична. Проблемы создаёт отсутствие границ (Domain, Application, Infrastructure), не один процесс вместо десяти

Фактор человека Боль, которую не лечит архитектура — разное видение мира. PO: «Хочу красную кнопку на миллион». Разработчик: «Нужна абстракция, Стратегия и рефакторинг ядра». Компромиссы и неумение слушать убивают продукт. Микросервисы бессильны. Если бизнес и IT не говорят на одном языке — получите распределённое легаси. Миграция легаси без «сжигания ведьм»

Работает Strangler Fig Pattern — эволюционный вынос. Не переписываем с нуля. Берём критические узлы, выносим в модульный монолит. В легаси остаётся интерфейс и роутинг. Тяжёлая логика и новые фичи — в новой системе, которая становится «надстройкой» к легаси. Миграция становится скучной формальностью. Без остановок бизнеса и поиска виноватых.

Прежде чем пилить монолит, спросите: код не помещается в голову, или мы не умеем писать чистый код? Если второе — микросервисы умножат боль на сетевые задержки. Начинайте с границ в голове, DDD, тестов и модульного монолита.

Всем чистого кода и адекватных Архитекторов!