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