2015-10-18 25 views
3

我正在实现一个具有Akka持久性的CQRS系统,并且我试图理解CQRS的请求响应位。如何向CQRS中的命令发送响应?

关于如何向客户端发送响应,SO上的答案很少,this article也提到了一些很好的模式。但是,不要泛泛而谈使用大词汇,有人可以解释我应该如何将响应发回CQRS中的客户端以用于以下简单用例。

使用情况

假设用户是显示用户配置文件,显示以下信息的页面上

  1. 用户名
  2. 地址
  3. 电话号码

在我的系统中,我有一个A.每个用户存储该用户的配置文件信息。

在UI用户要更新的地址和下面的事情发生:

  1. 用户进行AJAX REST调用来更新
  2. UpdateUserAddressCommand(address:String)产生
  3. UpdateUserAddressEvent(address:String)产生
  4. UserAddressUpdatedEvent(updatedAddress:String)的用户地址生成(UserActor状态更新)

现在我该如何发送UserProfile在系统中的完整状态?由于CQRS不鼓励为命令发送响应?

回答

2

关于CQRS模式,REST层可以被认为是使用CQRS的系统的客户端,因此您可以在不违反“原则”的情况下发送响应(从REST服务器到Web浏览器)。

对你来说,这是相当简单:

  1. REST调用/api/endpoint/1234 - > REST服务器生成与上述命令。
  2. Server返回代码“202接受”,并设置Location:头 像/api/user/profile/1234
  3. 客户端查询/api/user/profile/1234查询UserProfile的完整状态。

如果您使用异步查询端更新/最终一致性,您可以将3.与HTTP长轮询结合使用。

+0

这是有道理的。谢谢:)关于错误消息呢?他们是否也以这种方式进行处理或者在命令本身中发送诸如“地址无效”之类的错误也是否违反CQRS模式? – hajime

+2

一般的经验法则是避免命令处理程序中的任何错误。如果输入错误(如“地址无效”),客户端(REST层)可能会提前进行验证以避免命令处理程序中的错误。如果存在业务错误(如重复地址/用户等),而这些业务错误无法通过简单验证来捕获,则应采取补偿措施。如果它们很少发生,甚至可以手动进行补偿/修复。 –

+0

如果性能不是关键问题,为什么不让命令处理程序回复客户端?可以使用超时回退到“202 Accepted”状态,因为高负载的特殊情况会阻止整个循环在合理的时间内进行验证。否则,如果必须考虑一系列必须稍后纠正的持续错误状态,那么看起来域模型会真的炸毁。或者,也许我误解了“补偿行为”的含义。 – acjay