CQRS / ES - обработка ошибок проекции

Question

Я работаю над системой CQRS + ES, в основном использую инфраструктуру аксонов, но на самом деле этот вопрос относится к любой реализации.Итак, у меня есть обработчик команд и один или несколько обработчиков событий, работающих на разных JVM, контейнерах и т. Д., И в какой-то момент один из этих обработчиков сталкивается с ошибкой.

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

Таким образом, мой вопрос заключается в том, должна ли такая ошибка быть «разрешена» каким-либо образом в бухгалтерской книге, т. Е. Путем отправки новой команды «аннулирования», которая затем передается в прогнозы таким образом, чтобы событиеошибка теперь решена?

В качестве примера, скажем, у нас есть команда, которая обновляет кредит клиента.Событие публикуется, один прогноз обновляет свою статистику «Всего кредитов», другой публикует обновление некоторого веб-сокета для пользовательского интерфейса и, наконец, другой, который поддерживает состояние кредита - и этот последний обработчик завершается ошибкой.Должны ли мы отправить команду на откат бизнес-транзакции и снова вычесть кредит, снова обновить веб-сокет и т. Д.?А в случае аксона есть ли способ, которым это фиксируется как транзакция?

Answer 1

Я бы сказал, что принятие решения о том, является ли выполнение действия, то есть обработки команды, правильным, всегда должно приниматься Командной моделью / Агрегатом.Совокупность, находящаяся в неправильном состоянии для обработки действия, обычно приводит к «бизнес-исключению / ошибке».

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

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

С точки зрения Axon Framework, вы можете заключить CreditStateEventHandler в TrackingEventProcessor и вызвать сброс на этом обработчике событий, вызвав функцию TrackingEventProcessor#resetTokens().Эта позиция принята за то, что исключение, из-за которого ваш CreditStateEventHandler связан с ошибочным кодированием, в противном случае повтор приведет к точно такому же исключению.