Сага, которые зависят от событий из прошлого

Question

У меня вопрос, как бороться с сагой, где принимаются решения зависит от события, которое было опубликовано до создания саги.

Вот пример, иллюстрирующий мою проблему:

Представьте, что у меня есть CustomerAR и OrderAR. Когда customerAR созданный процесс проверки запускается, результатом этого процесса является сумма заказа, которую клиент может потратить без особых затрат авторизации. Я не буду вдаваться в подробности об этом процессе, потому что это вне контекста. Когда сумма рассчитана, команда отправляется CustomerAR с рассчитанной суммой и CustomerAR публикует событие (CustomerMaxOrderAmountEvent) с этим значением. Так пока все хорошо.

Затем, через несколько недель, клиент размещает заказ. OrderAR является создал и запускает мою OrderSaga. Сага ждет пока заказ создан полностью, а затем должен принять решение, если ему нужно отправить AutorizationCommand для этого заказа. Чтобы принять это решение, оно должно знать, опубликован ли CustomerMaxOrderAmountEvent и значение количество. Обычно OrderSaga также подписывается на CustomerMaxOrderAmountEvent, но проблема в том, что это событие никогда не будет происходят потому, что это уже было в прошлом.

Как мне с этим бороться. Должен ли я запросить модель чтения, чтобы узнать значение, если я должен отправить команду, чтобы получить значение, я должен сделать ссылка на CustomerAR, если я буду воспроизводить все исторические события в сага, поэтому он уже знает историю.

UPDATE

Обратите внимание, что речь идет о концепции, а не об этом конкретном примере. Этот пример является чистым для прояснения проблемы: «2 несвязанных агрегатных корня, которые не являются частью одного и того же ограниченного контекста».

Благодарен за помощь.

Мелвин

Answer 1

Я бы выбрал более простое решение - просто добавьте эту информацию (например, в форме HasCustomerReachedMaxOrderAmount) к событию, которое запускает Сагу.

Второй вариант, который я выберу, - это подготовить модель чтения, предназначенную для использования с Sagas, и оттуда запросить данные, но я собрал бы всю необходимую информацию еще до запуска саги. Это обогащение может быть выполнено обработчиком исходного события, вызванного AR, поскольку это не является частью агрегированного / ограниченного контекста.

Однако в большинстве случаев достаточно опираться на данные, передаваемые с событиями, поскольку Sagas должен содержать бизнес-логику только в форме процесса. Это очень часто означает, что у вас может оказаться более одной саги (по вашему примеру OrderSaga и OrderWithMaxAmountSaga).

С учетом всего приведенного вами примера сценария, я думаю, решение о том, требует ли заказ авторизацию или нет, должно быть частью самого вашего домена и приниматься во время запуска саги.

Я бы смоделировал этот сценарий так: CustomerAR вычисляет максимальную сумму; клиент размещает заказ -> OrderAR создается с информацией о максимальной сумме для этого клиента, Order проверяет необходимость дополнительной авторизации -> Saga начать работу. Дело в том, что информация о максимальной сумме важна как для CustomerAR (где она может изменяться), так и для OrderAR (где она неизменна).

Answer 2

Я только начинаю баловаться с DDD и не собираюсь повторять то, что сказал kstaurch, но вот некоторые мысли, которые я рассмотрел в вашем сценарии:

1. Как насчет того, чтобы сделать максимальную сумму заказа частью платежной информации? Это должно быть где-то получено, и я уверен, что вы позаботитесь о состоянии, при котором обработка платежа запрещена.

2. Что если сага всегда посылает команду авторизации, но именно часть авторизации обрабатывает экран максимального заказа? Если вы говорите «Если сумма превышает $ X, то получите авторизацию», возможно, ваша бизнес-модель также думает об этом как «Если она ниже $ X, автоматически одобрите». Преимущество заключается в том, что все соображения об утверждении (в том числе вопрос о том, получить ли одобрение) могут быть перенесены в утверждающий субъект или в организацию.