Межагрегатная связь в источнике событий CQRS + DDD +
как отдельной агрегатные корни (AR) общайтесь друг с другом в среде, построенной на принципах DDD, используя агрегатный сервер с источником событий?
например, у меня есть Facility aggregate root (AR), который имеет заводской метод, ответственный за создание Booking AR. The Booking-чувствительная ко времени комбинация a Person AR и A Facility AR. А Person можно забронировать только в одном Facility.
в DDD я бы ссылки на Booking на Person и Person на Facility. Однако при генерации событий для использования в event-sourcing я думаю, что попытка обработать десериализацию событий из back-end станет запретительной. Поэтому я взял только ссылки на уникальные идентификаторы на основе объекта value. Это вызывает новую проблему, однако, когда метод на AR должен вызвать другой метод на другом AR - как вы справляетесь с этой ситуацией? Нажмите репозиторий источника событий из домен AR?
каков общий вариант использования в этом сценарии? Я неправильно к этому подхожу?
2 ответов
агрегатные корневые границы определяют границу согласованности. Внутри агрегата, последовательность гарантирована. Внешний... это не так. Поэтому у вас не должно быть операций, которые охватывают несколько агрегатов и должны быть согласованными. Если вам нужна транзакция, охватывающая два агрегата, вы должны просмотреть свои границы агрегатов.
для вещей, которые происходят за пределами aggregate, у вас должен быть обработчик событий, который отправит команду другим агрегатам. Если логика действий между агрегаты сложнее, вы можете определить процесс, государственную машину, которая будет прослушивать события и отправлять команды агрегатам. Процессы могут использоваться для определения длительных транзакций (с компенсацией вместо отката) или принятия бизнес-решений на основе того, что происходит в системе в больших масштабах (даже между ограниченными контекстами).
при использовании Event Sourcing и CQRS самым элегантным (по крайней мере, на мой взгляд) способом взаимодействия между AR является обмен сообщениями. Вы можете посмотреть Ncqrs проект (это будет проще, если вы парень .NET), особенно ветка "обмен сообщениями". Идея в том, что ARs реализует интерфейс IMessageHandler для каждого типа сообщений, который они обрабатывают, и базовый класс AR предоставляет метод Send для отправки туда сообщений. С помощью этого API клиенты могут вызывать поведение модели, а сама модель может взаимодействовать (между Арс).