Межагрегатное общение в CQRS + DDD + Event Sourcing

Question

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

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

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

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

Answer 1

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

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

Answer 2

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