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

Question

我们正在使用一个存储单个聚合的事件存储 - 用户的订单（想象一下亚马逊订单，而不是客户或电子商务公司的任何人在实际调度之前随时更新的订单）。

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

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

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

我应该在内部包含“微观事件”的“宏观”事件吗？我是否应该将命令的id附加到事件中，这样我就可以很容易地推断出同一事件发生了什么，哪些事件不发生（另一种选择是依赖于时间戳......但这很令人作呕）。

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

谢谢

Answer 1

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

鉴于上述情况，我原本预计显示事件流应该没问题。但我完全明白为什么在某些情况下它可能并不理想。即它可能太详细了。在这种情况下，可能会创建一个“夏季”阅读模型。

Answer 2

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

Answer 3

事件（过去时）并不总是捕获人类或系统用户的意图。命令（命令式情绪）呢。由于所有命令数据都不能轻易地从它生成的事件中回溯，因此保持命令的结构化日志在这里看起来是个不错的选择。