在 CQRS http 应用程序中实现 Saga/Process Manager答案

【问题标题】：Implementing a Saga/Process Manager in a CQRS http application在 CQRS http 应用程序中实现 Saga/Process Manager
【发布时间】：2015-09-15 18:38:35
【问题描述】：

以下示例：https://msdn.microsoft.com/en-us/library/jj591569.aspx（图 3）

它如何适应 http 应用程序？

用户应该向 PlaceOrderController 执行一个 http 请求，它将发送一个 PlaceOrderCommand，但是 Order Process Manager 将如何向用户回答“9. Order Confirmed”？控制器如何意识到这一点，以便将此信息返回给用户？

谢谢

【问题讨论】：

标签： domain-driven-design process-management saga

【解决方案1】：

您根本不会立即回答“订单已确认”。看看亚马逊和其他购物网站是如何做到的：在提交订单后，您只会收到“订单已接受确认”（例如，HTTP 代码 202 已接受）。当订单流程经理处理了实际订单时，会收到“订单”通过单独的消息/渠道（例如电子邮件）向用户发送“已确认”通知。

【讨论】：

以及如何在网络上显示“您的购买成功”消息？ ://
@fj123x 可能是通过发送电子邮件或页面轮询后端或通过 websocket 发送消息
投票在哪里？一个充当“收件箱”的控制器，以便在上一个 http 请求之前获取所有消息？（在第一个请求中等待进程管理器完成是不是正确的？）

【解决方案2】：

@Hippoom 为您指明正确的方向。

CQRS 之旅（你在读什么）说：

团队后来更换了这个机制来检查系统是否使用 Post-Redirect-Get 的实现保存订单图案。以下代码示例显示了新版本的 StartRegistration 操作方法。有关更多信息 Post-Redirect-Get 模式见文章Post/Redirect/Get on 维基百科。
[HttpPost]
public ActionResult StartRegistration(string conferenceCode,
OrderViewModel contentModel)
{
...
this.commandBus.Send(command);
return RedirectToAction(
"SpecifyRegistrantDetails",
new { conferenceCode = conferenceCode, orderId = command.Id });
}
action 方法现在重定向到 SpecifyRegistrantDetails 视图在它发送命令后立即。以下代码示例显示 SpecifyRegistrantDetails 操作如何轮询订单返回视图之前的存储库。
[HttpGet]
public ActionResult SpecifyRegistrantDetails(string conferenceCode, Guid orderId)
{
var draftOrder = this.WaitUntilUpdated(orderId);
...
}
第二种方法的优点，使用 Post-Redirect-Get 模式而不是在 StartRegistration 发布操作中是它配合浏览器的前进和后退导航按钮效果更好，它给了

这里我们讨论的是毫秒或最坏情况下几秒的最终一致性。所以 P-R-G 模式非常适合。

无论如何，here 和 here 在那里，您可以阅读有关最终一致性 UI 的文章，而不是对您有所帮助。

发表评论编辑：

Here Udi Dahan 说：

什么时候应该避免 CQRS？

答案是大多数时候。

这是我能告诉你的最有力的迹象，表明你是正确执行 CQRS：您的聚合根是 sagas

所以，我认为您的问题不是发现 CQRS 如何用于 HTTP 应用程序。您的问题是，对于您所质疑的流程和用例，您应该避免使用 CQRS。

【讨论】：

“这里我们讨论的是毫秒或最坏情况下几秒的最终一致性。所以 P-R-G 模式非常适合。”好的，所以： 1. 您提交订单 (P) 2. 您重定向到 G 3. 如果订单尚未确认会发生什么（因为第三方的延迟，无论如何），您是否应该重复 R（重定向到 G ) 直到有结果？
如果你想立即响应，你应该考虑同步命令处理。否则，使用某种异步通知系统（例如 StackOverflow 上的消息通知）。
cqrs/es 应用程序中的同步命令处理是否正确？我读了lostechies.com/jimmybogard/2012/06/26/…，他们说“如果您的用户必须等待更新视图模型才能看到他们的结果，那么您构建了错误的用户界面。结果应该是即时的。您是否收到我的命令？是的“是吗？我的命令状态如何？这就是你应该有的互动。”他们说不。顺便说一句：在某些情况下，信息无法伪造（例如“旋转获胜等”）

【解决方案3】：

您的 Web/REST api 独立于您的域模型，但会根据您的用例和用户代理需求映射到它。一种方法是提交一个“作业”，然后轮询该作业的进度。有许多权衡需要考虑。例如，根据您的基础设施发送通知可能是最好的方法。如果你想要 REST/HTTP，你可以试试这个：

用户代理：

POST /jobs/registrations
..content..

源服务器：

HTTP/1.1 303 See Other
Location /jobs/registration/<some-job-id>

用户代理：

GET /jobs/registration/<some-job-id>
..content with job status..

【讨论】：