所以我试图找出 CQRS+ES 架构的一般用例背后的结构，我遇到的问题之一是聚合在事件存储中的表示方式。如果我们将事件划分为流，那么流究竟代表什么？在跟踪一系列项目的假设库存管理系统的上下文中，每个项目都有一个 ID、产品代码和位置，我无法可视化系统的布局。
从我在互联网上收集到的信息来看，它可以简洁地描述为“一个聚合一个流”。所以我会有一个 Inventory 聚合，一个包含 ItemAdded、ItemPulled、ItemRestocked 等事件的单个流，每个事件都带有包含项目 ID、更改数量、位置等的序列化数据。聚合根将包含一个 InventoryItem 对象的集合（每个都有它们各自的数量、产品代码、位置等）这似乎允许轻松执行域规则，但我看到了一个主要缺陷；将这些事件应用于聚合根时，您必须首先重建该 InventoryItem 集合。即使使用快照，对于大量项目，这似乎也非常低效。
另一种方法是让每个 InventoryItem 有一个流跟踪与仅项目有关的所有事件。每个流都以该项目的 ID 命名。这似乎是更简单的路线，但现在您将如何执行域规则，例如确保产品代码是唯一的，或者您不会将多个项目放入同一位置？看起来您现在必须引入 Read 模型，但将命令和查询分开难道不是重点吗？只是感觉不对。
所以我的问题是“哪个是正确的？” 部分两者？两者都不？像大多数事情一样，我学得越多，我就越知道我不知道......