Контекст
Микросервисы и интеграция
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 не размазываются между несколькими сервисами.
Связанные главы
Monolith to Microservices
Практические стратегии выделения сервисов из монолитной системы.
Learning Domain-Driven Design
DDD-подход к границам домена и bounded context decomposition.
Паттерны межсервисной коммуникации
После декомпозиции нужно выбрать устойчивые паттерны взаимодействия сервисов.
Service Discovery
Рост числа сервисов требует управляемого обнаружения и маршрутизации трафика.
Микросервисы и интеграция: обзор
Вводный контекст и место decomposition в общей архитектурной картине.