从事件存储中的事件流推断用户意图。这甚至是正确的做法吗？答案

【问题标题】：Inferring the user intention from the event stream in an event store. Is this even a correct thing to do?从事件存储中的事件流推断用户意图。这甚至是正确的做法吗？
【发布时间】：2018-05-17 11:55:59
【问题描述】：

我们正在使用存储单个聚合的事件存储 - 用户的订单（想象一下亚马逊订单，在实际发货之前，客户或电子商务公司中的某人可以随时更新）。

我们将首次允许我们公司的员工查看订单的历史记录，因为到目前为止他们只能看到其当前状态。

我们现在意识到构成聚合根的事件并没有真正显示意图或用户实际做了什么。当顺序应用于空订单时，它们仅用于构建订单的当前状态。问题是：他们应该这样做吗？

假设一个用户最初拥有一本 X 书，然后将其删除并再次添加了 2。我们应该将其视为事件“用户添加了 1 本书”还是事件“用户删除了 1 本书”+“用户添加了 2 本书”（我们似乎已经遵循了这种方法）？
在某些情况下，我们有一个初始事件，然后是其他事件。我，开发人员，肯定知道所有这些事件都是由一个命令触发的，但是在动态生成这个“订单历史”功能供用户查看时，做出这种假设对我来说似乎非常脆弱。但如果我不将它们视为一个单独的操作，至少在订单历史功能中，看起来有很多订单修改，而实际上只有一个，大的。

我应该有包含“微事件”的“宏”事件吗？我是否应该将命令的 id 附加到事件中，这样我就可以轻松推断出同时发生了哪些事件，哪些没有（另一种方法是依赖时间戳……但这很恶心）。

处理这种情况的标准方法是什么？我希望能够随时查看聚合的历史记录并生成此报告（我不想每次更新订单时都以增量方式构建报告）。

谢谢

【问题讨论】：

标签： domain-driven-design cqrs event-sourcing

【解决方案1】：

理想情况下，命令名称应能描述意图。这应该意味着可以创建使原始意图清晰的事件名称。根据经验，事件流中的事件应该是相关业务成员可以理解的。这是一个很好的经验法则。它应该包含“cartUpdated”等内容。

鉴于上述情况，我原以为显示事件流应该没问题。但我完全明白为什么在某些情况下它可能并不理想。 IE。可能太详细了。在这种情况下，可能会创建一个“summeriser”读取模型来提供事件。

【讨论】：

【解决方案2】：

通常在结果事件的元数据中包含命令的 ID，以及可选的相关 ID（对于长时间运行的进程很有用）。这样可以更轻松地构建订单历史投影。或者，您可以使用事件时间戳以任何您想要的方式关联批次（如果它们发生在一个短窗口中，您可能只需要一个条目，即使是多个命令）。

【讨论】：

【解决方案3】：

事件（过去时）并不总是能捕捉到人类或系统用户的意图。命令（命令式语气）可以。由于所有命令数据不能总是从它生成的事件中轻松追溯，因此保留结构化的命令日志在这里看起来是一个不错的选择。

【讨论】：