Я реализую систему CQRS с сохранением Akka, и я пытаюсь понять бит ответа на запрос CQRS.Как отправить ответ команде в CQRS?
Есть несколько ответов на SO о том, как отправить ответ клиенту, а this article также упоминает несколько хороших шаблонов. Но вместо обобщения с использованием больших слов кто-то может объяснить, как мне отправить ответ клиенту в CQRS для следующего простого варианта использования.
Используйте случай
Предположим, что пользователь находится на странице, которая отображает профиль пользователя, который отображает следующую информацию
- Имя пользователя
- Адрес
- Телефон
И в моей системе у меня есть один А ctor per User, который хранит информацию профиля пользователя.
На пользователя UI хочет обновить адрес и следующие вещи:
- Пользователь делает вызов AJAX REST, чтобы обновить адрес пользователя
UpdateUserAddressCommand(address:String)
генерируемыйUpdateUserAddressEvent(address:String)
генерироватьсяUserAddressUpdatedEvent(updatedAddress:String)
(состояние обновленного UserActor)
Теперь как отправить полное состояние UserProfile в систему? Поскольку CQRS не рекомендует отправлять ответ для команды?
Это имеет смысл. Спасибо :) Как насчет сообщений об ошибках? Они также обрабатываются таким образом или отправляют ошибки, такие как «адрес недействителен» в самой команде, также против шаблона CQRS? – hajime
Общее правило заключается в том, чтобы избежать ошибок в обработчиках команд. В случае ошибок ввода, таких как «адрес недействителен», клиент (слой REST) может выполнить преждевременную проверку, чтобы избежать ошибок в обработчике команд.В случае возникновения бизнес-ошибок (например, дублированных адресов/пользователей и т. Д.), Которые не могут быть пойманы простой проверкой, вместо этого следует выполнять компенсирующие действия. Если они происходят редко, может быть даже целесообразно выполнить компенсацию/фиксацию вручную. –
Если производительность не является критичной проблемой, почему бы не передать ответ обработчику команды клиенту? Тайм-аут может быть использован для возврата в состояние «Принимаемое состояние 202», в качестве особого случая, если, например, высокая загрузка предотвращает проверку всей петли за разумный промежуток времени. В противном случае, похоже, модель домена действительно взорвется, если вам придется рассмотреть кучу постоянных состояний ошибок, которые должны быть позже исправлены. Или, может быть, я не понимаю, что вы подразумеваете под «компенсационными действиями». – acjay