我正在构建一个非常以数据为中心的系统 . 我有大型的分层数据集，但没有业务规则 . 系统的输出来自对数据和一些报告进行的一些计算 . 我需要有一个完整的审计跟踪（出于监管原因），并能够从过去的任何一点对数据集运行计算 .
出于这些原因，我认为使用CQRS的事件源系统是可行的方法 . 我见过的所有例子都围绕创建聚合来做ES . 我遇到的问题是因为每个数据都是一个大的相关集合，我会有少量的大量聚合 . 替代方案似乎是将设置拆分为它的部分，并将每个部分称为聚合 . 但是，为了进行任何计算，我必须加载数十万个聚合 .
我的问题是，是否有人拥有以数据为中心的CQRS ES系统的经验以及可能是什么样的？
有没有更好的方法来存储数据集的历史而不使用ES？
谢谢你的帮助 .
2 回答
语言检查：聚合只存在于写模型（C）中 . 计算和报告来自读取模型（Q） . 毕竟，当您报告事件历史记录时，您不会更改/追加事件历史记录 .
这听起来有点像库存跟踪系统 . Greg Young评论说“in most inventory systems there are no commands.”
因为“记录簿”是现实世界，而不是模型，“命令”没有意义 - 模型不允许拒绝现实 . 没有命令，聚合就会消失;没有业务规则来强制执行 . 只是宣布改变现实世界的事件 .
CQRS ES的基本模式仍然有效，也就是说您将事件历史记录写入持久层（这是您的审计跟踪），并从该记录中发布事件，以便您的其他预测可以更新 .
您需要考虑适合您情况的事件流数量 . 在域模型是记录簿的CQRS解决方案中，每个聚合通常写入独占事件历史（减少争用）;需要来自多个流的数据的模型将它们连接在一起 . 因此，您可能希望为不同的外部事件源做类似的事情 . 或者，您可以将它们全部发布到单个事件流中，然后让读取模型过滤掉它们不需要的事件 .
自从我熟悉事件采购理念以来，我总是使用事件存储来存储我正在使用的系统中发生的事情 . 我把它称为'event sourcing lite'，当你没有真正构建聚合但是遵循贫血的模型路线时，只需将所有逻辑放在Application Services层中（比如Onion） .
我很少看到不遵循“精简版”的“事件采购”的理由 . 这就像审计日志记录，但随着代码的增长，应用程序的范围要大得多 . 只有当您的域丰富时，您才可以考虑开始构建聚合和快照，在内存中缓存它们等 . 对于浅域，如果您需要最大性能和巨大负载，也可以使用聚合 . 正确构建ES聚合需要技能和时间进行分析和实验 . 在开始这项冒险之前，请确保拥有它 .