Events 我们真的可以使用事件源和CQR（一种用于电子商务结账漏斗的事件驱动体系结构）吗？

假设Checkout具有以下服务：

订单服务，创建订单，收集发货、付款和下订单，并管理订单的生命周期

库存服务，提供产品的可用性

运输服务，提供交付选项和成本

客户档案服务，提供客户信息

信用服务、付款授权

预订服务进行预订

以下是订单创建流程：

创建订单，用户提供发货地址，计算发货选项，收取付款，下订单，并向用户显示确认信息

许多零售商的结帐是同步和订单服务编排

假设我们使用事件源、CQRS和事件存储，订单服务将创建订单事件并在事件存储中持久化，发布域事件和订阅到事件存储的所有其他服务，因为它们需要更新交付选项、运输成本，支付完成订单的费用，并使用CQR通知用户每个步骤的状态，供其查看

我试图理解：

结帐应用程序与结帐的所有域事件（如添加装运地址、预订、交付选项选择、添加付款和完成订单）的复杂程度如何

这会比安排结帐请求的订单服务的同步操作更快吗

---

如果失败，最终的一致性会是什么？如何处理每个实际一致性？

我们可以使用事件源和CQR进行签出过程。正如您所说，您将发起活动，订阅的服务将对此作出反应。问题不是有多复杂或容易，在你的情况下值得吗？事件源和CQR是一种复杂的模式，有很多好处，但您需要以正确的方式实现它

---

为了最终的一致性，您可能必须依赖于Saga模式，在出现故障的情况下，您必须为回滚提出补偿措施

谢谢你，伊姆兰。是的，值得做吗？这是一个正确的问题。事件源可能不是一个好的选择，那么事件驱动架构呢？这是一个很好的结账设计吗？我喜欢舞蹈模式而不是编排。你可以使用事件驱动架构。舞蹈是一种提供的方法。由于签出过程非常关键，所以您需要设计适合UI的签出过程。e、 g.您提出事件处理付款。用户将有等待屏幕付款处理。现在，如果支付服务宕机，MessageBroker就会宕机，那么您将要做什么？最终服务会来处理，但你不能让你的用户保持那么长的时间，如果你超时，用户会认为交易被取消，但在某个时候你的支付事件将被处理，你可能会向客户收费。所以你必须考虑所有方面。分布式事务是复杂的，您必须在设计时牢记系统将崩溃。在这种情况下，事件源和CQR很好，因为您拥有跟踪任何订单的所有日志。