没有 DDD 的 CQRS + 事件溯源

Question

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

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

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

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

感谢您的帮助。

Answer 1

但是，为了进行任何计算，我必须加载数十万个聚合。

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

这是一个资产管理系统。每个资产有 100k+ 件设备。

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

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

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

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

Answer 2

自从我熟悉事件溯源理念以来，我一直使用事件存储来存储我正在使用的系统中发生的事情。我称之为“事件溯源精简版”，当您不真正构建聚合而是遵循贫乏的模型路线时，只需将所有逻辑放在应用程序服务层（如在 Onion 中）。

我很少看到在它的“精简”版本中不遵循“事件溯源”的理由。这就像审计 + 日志记录，但随着代码的增长，应用程序的范围要大得多。 只有当您的域很丰富时，您才可以考虑开始构建聚合和快照，将它们缓存在内存中等。对于浅域，如果您需要最大性能和巨大的负载，您也可以使用聚合。正确构建 ES 聚合需要分析和实验的技能和时间。在开始这项事业之前，请确保您拥有它。