事件溯源 - 聚合建模

Question

两个问题 1）如何对它们之间的聚合和引用进行建模 2) 如何组织/存储事件以便有效地检索它们

以这个典型用例为例，我们有 Order 和 LineItem（它们是聚合，Order 是聚合根）和 Product 聚合。 由于 LineItem 需要知道哪个 Product，所以有两个选项 1) LineItem 直接引用 Product 聚合（这似乎不是最佳实践，因为它违反了聚合作为一致性边界的想法，因为我们可以直接从 Order 更新 Product 聚合聚合）2）然后LineItem只有ProductId。

看起来第二个选项是要走的路……你怎么看？

但是，另一个问题出现了，即构建订单读取/查看模型。在这个 Order 视图模型中，它需要知道哪些产品在 Order 中（即 ProductId、Type 等）。典型的用例是报告，CommandHandler 也可以使用这个 Product 对象来执行逻辑，例如是否有太多特定的产品等。为了做到这一点，鉴于这些数据在两个单独的聚合中，那么我们需要 1 次以上的数据库往返。由于我们使用事件来构建模型，所以伪代码如下所示 1) 对于给定的订单 id (guid, order aggregate id)，我们为其加载所有事件； -- 第一次数据库访问 2）然后构建一个Order聚合，那么我们就知道Order中引用了哪个ProductId； 3) 对于 ProductIds 列表，我们为其加载所有事件； -- 第二次数据库访问

如果我们构建一个非常大的对象图（很多不同的聚合），那么最终可能会导致更多的数据库访问（每个都很慢）...您的想法是什么？

谢谢

Answer 1

以这个典型用例为例，我们有 Order 和 LineItem（它们是聚合，Order 是聚合根）和 Product 聚合。

按照您描述的方式，Order 聚合是有意义的。 “产品聚合”比较可疑；是询问模特是否允许更改产品，还是告诉模特产品已更改？

如果产品可以在不事先咨询订单的情况下更改，则 LineItem 必须不包含该产品。对产品的引用（又名 ProductId）是可以的。

如果我们构建一个非常大的对象图（很多不同的聚合），那么最终可能会导致更多的数据库访问（每个都很慢）...您的想法是什么？

对于读取、报告等——您不会在历史记录中添加新事件——一个可能的答案是提前完成缓慢的工作。异步进程侦听事件存储中的写入，然后将这些事件发布到总线。订阅者在观察到新事件时构建新版本的报告，并缓存结果。 （搜索关键字：cqrs）

当客户要求提供报告时，您可以从缓存中给他们一份。所有的工作都完成了，所以很快。

对于命令处理程序，答案更为复杂。业务规则应该在域模型中，因此让命令处理程序尝试验证命令（与域模型相反）有点不妥。

命令处理程序可以加载产品以查看状态可能是什么样子，并将该信息与命令数据一起传递给聚合，但不清楚这是一个好主意——如果客户端要发送命令要运行，你需要用产品数据充实订单命令，为什么不直接将产品数据添加到命令中，跳过中间人。

CommandHandler 也可以使用这个 Product 对象来执行诸如特定产品是否过多等逻辑。

这个例子有点含糊，但可以猜测一下：如果可用库存不足以完成订单，您会阻止下订单。

对于现实世界的库存 - 仓库中的实体书 - 这可能是错误的做法。一是模型本身是错误的；如果你想知道仓库里有多少产品，你应该查询仓库，而不是产品。其次，物理仓库不受模型的限制——在仓库聚合上调用 addProduct 方法不会导致产品神奇地出现在那里。

第三，无论如何，它可能与您的领域专家想要的不太匹配。如果模型说仓库没有足够的产品，你认为利益相关者希望系统吗

1. 告诉购物者在其他地方购买产品，或者...
2. 接受订单，并联系供应商以获取新的交货。

提示：如有疑问，请仔细查看 amazon.com 是如何做到的。