CQRS/事件源/事件总线/定时

Question

我在CQRS/ES设计中有一个计时案例。为了便于讨论，让我们以Microsoft关于这个主题的示例会议管理为基础(https://msdn.microsoft.com/en-us/library/jj554200.aspx)。

• 假设在第1分钟创建会议（最大座位数为20）。
• 在第4分钟，事件到达order mgmt上下文，因此创建了一个座位可用性。
• 在第7分钟，用户下了一个订单（通过订单管理），购买了整个20个座位。（这也应该从订单管理传达到conf管理，以便conf管理人员能够做出正确的决定）。
• 在第8分钟，conf admin更改了座位可用性（在conf mgmt上下文中），将其减少到15.
• 订单管理部门的通知（关于所有20个座位都已售出的事实）在第9分钟到达。
• 现在怎么办？（在conf MGMT？当你已经收到20个座位的付款时，你不应该把座位减少到15个；但在第8分钟，管理员不知道这件事）。

那是第一个案子。

现在第二种情况：

null

添加注意：或者可能…，在订单管理上下文中，我们可以简单地对购买座位的命令进行排队，直到我们知道已经从会议管理上下文中收到了最新/最后的事件。我是说，事件都有时间戳，对吧？因此，我们可以将从conf mgmt上下文接收的最后一个事件的时间戳与座位购买命令的时间戳进行比较。如果最后一个事件的ts小于命令的ts，我们只是推迟命令的执行，直到我们收到一个ts大于命令ts的事件。这类事情将由流程经理（saga）负责。

那样行吗？是正确的做法吗？

添加注意：相关线程>在CQRS http应用程序中实现SAGA/Process Manager。我想我们和流程经理的关系是对的。正如回答者所说：“你根本不会立即回答‘订单确认’。看看亚马逊和其他购物网站是如何做到的：在提交订单时，你只会收到一个”订单接受确认（例如，HTTP代码202接受）“。

谢谢，拉卡

Answer 1

三种可能

首先，你接受最终的一致性。正如评论中所指出的，在许多最终的一致性场景中，如果及时意识到问题，业务将有一种方法来缓解问题--因此，您需要一些东西来监视从模型中出来的事件，注意到预订的座位数和售出的座位数之间存在差异，也许还需要一个基于任务的UI来允许人类做正确的事情[tm]。

其次，检查业务，看看您是否真正正确地建模了真实的业务流程。例如，你可能在购买座位时错过了几个阶段；订单管理可能需要在确认订单前预订座位。

这是假设会议管理部门应保持一个不变量，即保留的席位数目少于分配的席位数目。在你的生意中，这可能不是真的。此外，能够跟踪客户试图预订超过可用座位的次数，这对业务可能是有用的。

第三，可能是你的服务边界划错了地方。乌迪·达汗写道

任何数据或规则必须仅由一个服务拥有。

如果会议管理中的席位和顺序管理中的席位是一回事，那么它们可能属于一起（相同的服务边界）。

我的建议是，基于自动化应该能够在需要时避开领域专家的原则，您应该主要考虑第一种方法--您是否能够将问题浮出水面并将其控制权移交给业务专家。如果你做对了这一点，你很可能会有一个成功的项目。