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

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

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

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

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

Ответ 1

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

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

Ответ 2

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