AXON Framework синхронный ответ

Question

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

Здесь на стороне команды и на стороне запроса 2 разных микро-сервисов, и мы используем Rabbit Mq для техники, управляемой событиями.

Заранее спасибо

Answer 1

Я не уверен, что полностью понимаю вашу проблему (особенно часть микросервиса :)), но если ваша проблема связана с обновлением стороны запроса после выполнения команды, то вы можете иметьвзгляд на этот проект .

В этом примере вы можете видеть, что он использует SubscriptionQueryResult в сочетании с QueryUpdateEmitter ( см. здесь )

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

Таким образом, вы можете избежатьвозможная последовательность.

Answer 2

@ Mzzl Серия действий

Командная сторона:

1. Request from frontend handled by a Controller class and creates an corresponding command
2. The above command is invoked and handled by a command handler which in return create corresponding event
3. The above event is then published through rabbit mq event bus.

Запросная сторона:

4. The event that is published in the step 3 is consumed by the event handler in query side.
5. The event handler has the logic to perform db transaction (lets assume add a user). Once a user is added then a success message or failure message (lets assume user already available in the DB so could not create duplicate entry) should flow from query side to command side and eventually back to UI as a repsonse.

Answer 3

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

Если вам нужно проверить, существует ли пользователь, вам нужно сделать это на командной стороне в вашем агрегате.Агрегат может хранить список всех существующих имен пользователей и выдавать исключение, если задана неверная команда.Ответ команды (подсказка: использование метода sendAndWait () в CommandGateway возвращает ответ) может затем использоваться в качестве системы для информирования вашего пользователя об успехе / неудаче его действия.

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

Командная сторона:

1. Запрос из внешнего интерфейса обрабатывается классом Controller и создает соответствующую команду
2. Вышеприведенная команда вызывается и обрабатываетсяобработчиком команды, который создает соответствующее событие, или выдает исключение, если пользователь уже существует.
3. Вызывающий команду информируется об успешном выполнении команды или обрабатывается исключение, иошибка, показанная пользователю.
4. Указанное выше событие публикуется через шину событий rabbit mq, если команда была выполнена успешно.

Сторона запроса:

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

Answer 4

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

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

Рекомендуется, чтобы агрегат с обработчиком команд располагал всей доступной информацией, чтобы решить, может ли команда быть успешно обработана, и когда событие применяется, это сигнал о том, что это произошло,и другие сервисы (в данном случае это сторона запроса) должны быть проинформированы.Для модуля запросов не рекомендуется отменять это («вы говорите, что это произошло, я говорю, что этого не произошло»).Если в стороне запроса есть ошибка, вы исправляете ее и воспроизводите событие.

Если это действительно ошибка в обработчике событий, о которой должна знать вся система, то это действительно отдельное событие.Вы можете применить такое событие непосредственно к шине событий и уведомить всю систему.Как то так:

 @Autowired
 private EventBus eventBus;

 (...)

 CatastrophicFailureEvent failureEvent = new CatastrophicFailureEvent("OH NO!");
 eventBus.publish(GenericEventMessage.asEventMessage(failureEvent));