domain-driven-design - CQRS + 没有 DDD 的事件溯源

Question

我正在构建一个非常以数据为中心的系统。我有大型分层数据集，但没有业务规则。系统的输出来自对数据进行的一些计算和一些报告。我需要有一个完整的审计跟踪(出于监管原因)，并且能够从过去的任何时间点对数据集运行计算。

由于这些原因，我认为拥有一个使用 CQRS 的事件源系统是可行的方法。我见过的所有例子都围绕着创建聚合来做 ES。我遇到的问题是因为每条数据都是一个大的相关集合，我会有少量的大规模聚合。另一种选择似乎是将设置分成几个部分，并将每个部分称为一个集合。但是，为了进行任何计算，我必须加载数十万个聚合。

我的问题是，有没有人有使用以数据为中心的 CQRS + ES 系统的经验？

有没有更好的方法可以在不使用 ES 的情况下存储数据集的历史记录？

谢谢你的帮助。

Answer 1

But, in order to do any calculation I would have to load hundreds of thousands of aggregates.

语言检查:聚合仅存在于写入模型 (C) 中。计算和报告来自读取模型 (Q)。毕竟，当您报告事件历史时，您并没有更改/附加到事件历史记录。

It's an asset management system. Each Asset has 100k+ pieces of equipment.

这听起来有点像库存跟踪系统。 Greg Young 评论说“ in most inventory systems there are no commands.”

因为“记录簿”是现实世界，而不是模型，所以“命令”没有意义——模型不允许拒绝现实。没有命令，聚合就会消失；没有要执行的业务规则。只是宣布现实世界发生变化的事件。

CQRS+ES 的基本模式仍然有效，也就是说您将事件的历史记录写入您的持久层(即您的审计跟踪)，并从该记录中发布事件，以便您的其他投影可以更新。

您需要考虑有多少事件流适合您的情况。在域模型是记录簿的 CQRS 解决方案中，每个聚合通常写入一个独占事件历史(减少争用)；需要来自多个流的数据的模型将它们连接在一起。因此，您可能希望为不同的外部事件源做一些类似的事情。或者，您可以将它们全部发布到单个事件流中，然后让读取模型过滤掉它们不需要的事件。