Domain driven design 从事件存储中的事件流推断用户意图。这是正确的做法吗？

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

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

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

想象一个用户最初拥有一本书X，然后将其删除并再次添加2本。我们是否认为这是一个事件“用户添加1本书”或事件“用户删除1本书”+“用户添加2本书”（我们似乎已经遵循这种方法）？

在某些情况下，我们有一个初始事件，然后是其他事件。一、 开发人员，请确定所有这些事件都是由一个命令触发的，但在动态生成供用户查看的“订单历史记录”功能时，对我来说，做出这种假设似乎非常脆弱。但如果我不把它们当作一个单独的动作来对待，至少在订单历史功能中，看起来有很多订单修改，而实际上只有一个，很大的一个

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

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

---

谢谢

命令名最好是用来描述意图的。这意味着可以创建事件名称，以明确原始意图。根据经验，事件流中的事件对于业务的相关成员来说应该是可以理解的。这是一条很好的经验法则。它应该包含“cartUpdated”等内容

---

考虑到上述情况，我本以为显示事件流的效果应该很好。但我完全明白为什么它在某些情况下可能并不理想。也就是说，它可能太详细了。在这种情况下，可能会创建一个为事件提供信息的“Summerser”读取模型。

通常会在生成的事件元数据中包含命令ID，以及可选的关联ID（对长时间运行的进程有用）。这样就更容易构建订单历史投影。或者，您可以使用事件时间戳以您想要的任何方式关联批次（如果在短时间内发生多个命令，您可能只需要一个条目）。

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