@ Сервисная инъекция в агрегаты? - PullRequest
0 голосов
/ 27 января 2020

У меня есть совокупность Order со следующими командами:

  • CreateOrderCommand
  • PlaceOrderCommand
  • ... (остальные отредактированы по мере их не имеют отношения к вопросу) ...

PlaceOrderCommand относится к размещению Order на внешнем месте исполнения. Я зафиксировал поведение для размещения заказа на внешнем месте исполнения внутри отдельной (не CQRS) @Service. Тем не менее, я борюсь (из-за отсутствия опыта работы с Axon), как лучше связать мой @Service с совокупностью.

Мой обычный образ мышления мог бы заставить меня:

  • Вставить @Service в конструктор @Autowired агрегата.
  • Когда выдается PlaceOrderCommand используйте сервис, чтобы разместить заказ на соответствующем месте исполнения и, как только это будет сделано, отправить событие (OrderPlacedSuccessfullyEvent или ErrorInOrderPlacementEvent).
  • Изменить состояние агрегата в соответствующем @EventSourcingHandler.

Мой вопрос:

  • Имеет ли смысл приведенное выше описание того, как обрабатывать этот конкретный вариант использования с помощью Axon (в частности, введение @Service в агрегат выглядит немного не так, как надо) мне)?
  • Или есть другой лучший способ моделирования моего сценария при использовании CQRS / источников событий с Axon?
  • Axon требует пустого конструктора в совокупности. Как это согласуется с наличием @Autowired конструктора?

Другая вещь, которую я потенциально рассматривал, была:

  • с PlaceOrderInstructionCommand (вместо простого *) 1052 *), который испускает ReceivedPlaceOrderInstructionEvent, который ожидает отдельный прослушиватель событий.
  • , что в прослушиватель событий будет вставлен соответствующий @Service, и он будет выполнять размещение Order.
  • , после размещения Order он отправит команду (или должен ли он генерировать событие?) агрегату, информирующему его об обновлении своего состояния.

Не могли бы вы порекомендовать, что является наилучшей практикой для моделирования этого сценария?

1 Ответ

2 голосов
/ 27 января 2020

PlaceOrderCommand относится к размещению Заказа на внешнем месте исполнения.

Я предполагаю, что размещение Заказа во внешнем месте исполнения означает взаимодействие с внешней системой. Если да, то он не должен быть частью вашего домена. В этом случае вам нужно поднять Integration Event.

. Как вы упомянули, вы можете поднять Command как ProcessOrder со своего домена. В этом Command вы можете обновить Domain (например, установить OrderStatus на Processing) и вызвать событие интеграции, например OrderArrived, которое затем обрабатывается отдельным процессом.

От Документы Microsoft :

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

События интеграции должны основываться на асинхронной связи между несколькими микроуслугами (другими ограниченными контекстами) или даже внешними системами / приложениями.

Это событие интеграции вы обрабатываете как отдельный процесс (или рабочий). за пределами вашего Domain. Это где ваш @Service будет введен. Как только заказ успешно обработан, вы можете затем транслировать событие интеграции под названием OrderPlaced.

Теперь любой подписчик, имеющий отношение к размещению заказа, подписался бы на событие. В вашем случае ваш Domain заинтересован в обновлении состояния после размещения заказа. Следовательно, вы бы хотели Subscribe до OrderPlaced события в пределах вашего Domain, чтобы обновить статус Order.

Надеюсь, что это поможет.

...