Миграция монолитного приложения к микросервисам с применением DDD

Условие

Компания планирует перейти от монолитной архитектуры к микросервисной. Необходимо оформить процесс разбиения системы, используя подход Domain‑Driven Design, и охватить следующие аспекты:

• Подход к делению бизнес‑области на домены и субдомены;
• Выявление и оформление ограниченных контекстов (bounded contexts);
• Определение агрегатов и их корневых сущностей;
• Проектирование модели доменных событий для асинхронного взаимодействия сервисов;
• Обеспечение согласованности и целостности данных между отдельными микросервисами;
• Решение вопросов, связанных с распределёнными транзакциями;
• Стратегия тестирования с упором на интеграционные тесты;
• Перенос данных из монолита в новые микросервисы;
• Предложение архитектурных решений, учитывающих масштабируемость, сложность доменов и необходимость эволюционного развития системы.

Ответ

Начните с bounded contexts и владельцев данных, а не разбиения по таблицам. Выделяйте сервисы постепенно, сохраняя локальные инварианты агрегатов и явные межконтекстные контракты.

Вместе с бизнесом выделите основной, поддерживающие и общие субдомены, зафиксируйте язык каждого контекста и связи между ними. Внутри контекста определите агрегаты: их корни защищают инварианты в локальных транзакциях.

Доменные события описывают уже случившиеся факты, имеют версии и идентификаторы для дедупликации. Публикацию согласуйте с БД через outbox; межсервисные процессы реализуйте как последовательности шагов с компенсациями, не обещая общей ACID-транзакции.

Переносите по одному контексту: backfill, сверка данных, переключение владельца записи и постепенная маршрутизация. Нужны контрактные и интеграционные проверки, сценарии повторов и отказов, наблюдаемость и план отката. Bounded context не обязан сразу становиться отдельным процессом.