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