Межсегментная связь в CQRS + DDD + Event Sourcing

Question

Как отделить связь aggregate roots (AR) друг от друга в среде, основанной на принципах DDD, используя встроенный сервер событий, основанный на событиях?

Например, у меня есть корень агрегата Facility (AR), который имеет фабричный метод, ответственный за создание Booking AR. Booking является чувствительной к времени комбинацией Person AR и Facility AR. A Person можно забронировать только в одном Facility.

В DDD, я бы провел ссылки на Booking в Person и Person в Facility. Однако при генерации событий для использования в event-sourcing я считаю, что попытка десериализации события из back-end станет непомерно высокой. Поэтому я взял только ссылки на уникальные идентификаторы, основанные на значении объекта. Это вызывает новую проблему, однако, когда метод AR должен вызывать другой метод на другом AR - как вы справляетесь с этой ситуацией? Хит репозиторий источника событий из домена AR?

Каков общий прецедент в этом сценарии? Я подхожу к этому все неправильно?

Answer 1

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

Для вещей, которые происходят за пределами агрегата, у вас должен быть обработчик событий, который отправит команду другим агрегатам. Если логика действий между агрегатами сложнее, вы можете определить процесс, конечный автомат, который будет прослушивать события и отправлять команды в агрегаты. Процессы могут использоваться для определения длительных транзакций (с компенсацией вместо отката) или принятия бизнес-решений на основе того, что происходит в системе в больших масштабах (даже между ограниченными контекстами).

Answer 2

При использовании Event Sourcing и CQRS наиболее элегантным (по крайней мере, на мой взгляд) способом межаргиональной связи является обмен сообщениями. Вы можете посмотреть проект Ncqrs (это будет проще, если вы являетесь участником .NET), в частности ветвь «Сообщения». Идея заключается в том, что ARs реализуют интерфейс IMessageHandler для каждого типа сообщений, которые они обрабатывают, и базовый класс AR предоставляет метод Send для отправки туда сообщений. С помощью этого API клиенты могут вызывать поведение модели, и сама модель может связываться (между AR).