Большинство проблем микросервисов рождается не на этапе RPC, а в тот момент, когда систему режут по неверным границам.
Для реального проектирования глава помогает увидеть, как bounded context, business capability, team topology и data ownership влияют на качество декомпозиции сильнее, чем схема репозиториев или язык реализации.
Для интервью и инженерных разборов она полезна тем, что помогает проверять decomposition на риск distributed monolith, дорогих кросс-сервисных транзакций и orchestration-сцепления между командами.
Практическая польза главы
Практика проектирования
Разделяйте систему по бизнес-capabilities, а не по техническим слоям и репозиториям.
Качество решений
Оценивайте варианты разреза через data ownership, team topology и частоту кросс-сервисных транзакций.
Interview articulation
Объясняйте, почему выбранный cut снижает связность и ускоряет автономные релизы.
Failure framing
Проверяйте decomposition на риск distributed monolith и дорогое orchestration-сцепление.
Контекст
Микросервисы и интеграция
Decomposition - это фундаментальный шаг, который определяет последующие коммуникации и операционную сложность.
Стратегии декомпозиции определяют, где проходят границы сервисов, кто владеет данными и как быстро команды смогут поставлять изменения. Ошибка на этом шаге обычно приводит к дорогой реорганизации архитектуры через 1-2 года.
Драйверы декомпозиции
- Независимая поставка изменений разными командами без блокировок друг друга.
- Разделение зон ответственности (domain ownership) и снижение когнитивной нагрузки.
- Наличие разных профилей нагрузки и требований к масштабированию по подсистемам.
- Нужна изоляция отказов и возможность деградировать отдельные capabilities, не весь продукт.
Оси декомпозиции
Business capability
Разделение по бизнес-возможностям: billing, catalog, fulfillment, identity. Обычно лучший стартовый ориентир.
Bounded context (DDD)
Граница сервиса совпадает с domain model и ubiquitous language. Снижает конфликтные трактовки данных.
Team topology
Сервисы проектируются так, чтобы ownership и runtime-ответственность были у одной команды.
Data ownership
Каждый сервис владеет своим хранилищем и схемой; cross-service join заменяется API/events.
Migration
Monolith to Microservices
Книга Sam Newman дает прикладные шаги и риски миграции от монолита к сервисам.
Стратегии миграции
Strangler Fig: постепенно выносите потоки из монолита за API-gateway/route layer.
Branch by Abstraction: сначала внедряется абстракция, затем плавно меняется реализация под ней.
Extract by volatility: выносите сначала самые изменчивые и независимые части домена.
Migration by seams: выделяйте технические и доменные швы (authentication, notifications, reporting).
Типичные антипаттерны
Nano-services: слишком мелкие сервисы с высокой связностью и сложной координацией.
Shared database как основной контракт между сервисами.
Декомпозиция по техническим слоям вместо бизнес-границ (service A = API, service B = DB).
Преждевременная декомпозиция без наблюдаемости, CI/CD и ownership-модели.
Пратический чеклист
- Каждый сервис имеет явного владельца и контракт SLA/SLO с соседями.
- Границы сервисов отражают domain boundaries, а не структуру кода в монолите.
- Cross-service зависимости задокументированы и имеют fallback/degradation поведение.
- Для каждого extraction шага есть rollback-стратегия и метрики успеха миграции.
- Данные и write-path ownership не размазываются между несколькими сервисами.
References
Связанные главы
- Monolith to Microservices - Практические стратегии выделения сервисов из монолитной системы.
- Learning Domain-Driven Design - DDD-подход к границам домена и bounded context decomposition.
- Паттерны межсервисной коммуникации - После декомпозиции нужно выбрать устойчивые паттерны взаимодействия сервисов.
- Service Discovery - Рост числа сервисов требует управляемого обнаружения и маршрутизации трафика.
- Микросервисы и интеграция: обзор - Вводный контекст и место decomposition в общей архитектурной картине.