Большинство проблем микросервисов рождается не на этапе удалённого вызова, а в момент, когда систему режут по неверным границам.
Для реального проектирования глава показывает, как бизнес-возможности, ограниченные контексты, топология команд и владение данными влияют на качество декомпозиции сильнее, чем схема репозиториев или язык реализации.
Для интервью и инженерных разборов она помогает проверять решение на риск распределённого монолита, дорогих межсервисных транзакций и лишней координации между командами.
Практическая польза главы
Практика проектирования
Разделяйте систему по бизнес-возможностям и доменным границам, а не по техническим слоям.
Качество решений
Оценивайте границы через владение данными, топологию команд и частоту межсервисных транзакций.
Аргументация на интервью
Объясняйте, почему выбранная граница снижает связанность и ускоряет автономные релизы.
Анализ отказов
Проверяйте решение на риск распределённого монолита и дорогой координации между сервисами.
Контекст
Зачем нужны микросервисы и интеграция
Декомпозиция задаёт границы ответственности, данных и будущую цену интеграции.
В этой главе рассматривается вместе с , и . Сама по себе декомпозиция не делает систему лучше: она становится полезной только тогда, когда снижает связанность, уменьшает когнитивную нагрузку и закрепляет понятную зону ответственности.
Отдельно важно различать , , и риск . Если границы выбраны неверно, система получает сетевые вызовы, дежурства и сложность микросервисов, но сохраняет связанность старого монолита.
Почему декомпозиция решает судьбу микросервисов
Сервисная архитектура начинается с границ, а не с протоколов
Хорошая граница делает команду автономнее, снижает радиус поражения отказов и позволяет развивать модель без постоянных согласований. Плохая граница превращает сервисы в распределённый монолит: релизы общие, данные общие, а сетевых проблем стало больше.
Меньше согласований
команда меняет свой контур без очереди из зависимостей
Общие релизы
сервисы формально разделены, но всё равно выкатываются вместе
Кто владеет изменением
главный вопрос перед выделением новой границы
Драйверы декомпозиции
Скорость изменений
Разные части продукта меняются с разной частотой, и общая поставка начинает тормозить команды.
Снижение когнитивной нагрузки
Команда должна понимать свою область достаточно глубоко, не удерживая в голове весь монолит.
Разные профили нагрузки
Каталог, оплата, уведомления и отчётность часто требуют разных режимов масштабирования и отказоустойчивости.
Изоляция отказов
Сбой в одной области должен приводить к контролируемой деградации, а не валить весь пользовательский сценарий.
Карта стратегий декомпозиции
Карта стратегий декомпозиции
Граница вокруг результата, а не слоя кода
Один и тот же монолит можно разрезать по бизнесу, модели, командам, данным или миграционным швам. Хорошее решение обычно сочетает несколько линз.
Выберите линзу
Начинаем с того, что бизнес умеет делать устойчиво
Сервис появляется вокруг способности бизнеса: выставить счёт, принять заказ, управлять каталогом или проверить личность клиента.
Каталог
товары и цены
Заказы
оформление и статусы
Оплата
счета и возвраты
Профиль
клиент и доступ
Архитектурный результат
Когда подходит
- разные скорости изменений
- явные бизнес-владельцы
- слабая общая транзакционность
Где риск
- границы слишком крупные
- внутри остаются разные модели
- нет команды-владельца
Вопросы проверки
- Можно ли выпустить изменение этой области без соседей?
- Понятен ли бизнес-результат сервиса?
- Не смешали ли мы несколько разных языков домена?
Как выбрать границы сервиса
Бизнес-возможность
Используйте, когда: Есть понятный бизнес-результат, владелец и независимый темп изменений.
Проверьте риск: Не делите слишком крупно: внутри одной области могут жить несколько разных моделей.
Ограниченный контекст
Используйте, когда: Термины и правила предметной области начинают конфликтовать между командами.
Проверьте риск: Не превращайте DDD-словарь в физические сервисы без операционной готовности.
Топология команд
Используйте, когда: Главная боль — постоянные согласования, чужие релизы и размытая ответственность.
Проверьте риск: Оргструктура не должна быть единственной причиной технической границы.
Владение данными
Используйте, когда: Команды спорят за схему, запись в данные или скорость эволюции модели.
Проверьте риск: Копии для чтения требуют правил свежести, восстановления и поддержки совместимости.
Книга
Monolith to Microservices
Sam Newman подробно разбирает безопасные способы выделять сервисы из работающего монолита.
Стратегии миграции из монолита
Найдите шов
Начинайте с пользовательского потока, интеграции или доменной операции, где можно перехватить трафик.
Поставьте фасад
Стабилизируйте вход через шлюз API, адаптер или внутренний контракт, чтобы старый и новый контур могли сосуществовать.
Перенесите поведение
Вынесите логику маленьким обратимым шагом, сохранив метрики, трассировку и понятный резервный сценарий.
Разведите данные
Переходите к собственной схеме только после того, как понятны владелец записи, синхронизация и стратегия отката.
Проверка решения
Автономность
Можно ли изменить и выпустить сервис без координации с несколькими соседними командами?
Контракт
Понятно ли, что сервис обещает клиентам: данные, ошибки, совместимость и эксплуатационные ожидания?
Данные
Есть ли единственный владелец записи, или основным контрактом всё ещё остаётся общая таблица?
Отказы
Что произойдёт при тайм-ауте, недоступности соседа или частичном сбое бизнес-процесса?
Типичные антипаттерны
Делить по техническим слоям: отдельный сервис для API, отдельный для базы, отдельный для бизнес-логики.
Создавать слишком мелкие сервисы, которые релизятся вместе и требуют постоянной синхронной координации.
Оставлять общую базу данных главным контрактом между сервисами и называть это декомпозицией.
Выделять сервисы до появления CI/CD, наблюдаемости, дежурств и явной зоны ответственности.
Практический чек-лист
Рекомендации
- Сначала докажите границу на уровне модульного монолита, если команда и нагрузка ещё не требуют отдельного сервиса.
- Фиксируйте архитектурное решение: почему граница выбрана, какие альтернативы отброшены и когда решение пересматривать.
- Измеряйте не количество сервисов, а скорость безопасных изменений, автономность команд и радиус поражения отказов.
- Выносите первым не самый модный сервис, а самый понятный и обратимый шаг с измеримым выигрышем.
Перед тем как выносить сервис
- У сервиса есть владелец, понятный контракт и операционные метрики.
- Граница отражает доменную область, а не структуру пакетов или репозиториев.
- Соседи получают данные через контракт, событие или подготовленную модель чтения, а не через прямую запись в чужую схему.
- Для каждого шага выделения сервиса есть путь отката, критерии успеха и план удаления старого кода.
- Решение проверено на риск распределённого монолита: общая база, цепочки синхронных вызовов и общие релизы не остались скрытым центром системы.
Источники
Связанные главы
- Monolith to Microservices - Практические стратегии постепенного выделения сервисов из монолита.
- Learning Domain-Driven Design - Как ограниченные контексты и язык домена помогают выбирать границы.
- Паттерны межсервисной коммуникации - После декомпозиции нужно выбрать устойчивые способы взаимодействия сервисов.
- Обнаружение сервисов (service discovery) - Рост числа сервисов требует управляемого поиска, проверки здоровья и маршрутизации.
- Зачем нужны микросервисы и интеграция - Общий контекст раздела и место декомпозиции в архитектурной картине.