出于这些原因,我认为有一个使用CQRS的事件源系统是要走的路.我见过的所有例子都围绕创建聚合来做ES.我遇到的问题是因为每个数据都是一个大的相关集合,我会有少量的大量聚合.替代方案似乎是将设置拆分为它的部分,并将每个部分称为聚合.但是,为了进行任何计算,我必须加载数十万个聚合.
我的问题是,是否有人拥有以数据为中心的CQRS ES系统的经验以及可能是什么样的？
有没有更好的方法来存储数据集的历史而不使用ES？
谢谢你的帮助.
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解决方案中,每个聚合通常写入独占事件历史(减少争用);需要来自多个流的数据的模型将它们连接在一起.因此,您可能希望为不同的外部事件源做类似的事情.或者,您可以将它们全部发布到单个事件流中,然后让读取模型过滤掉它们不需要的事件.