Domain driven design CQRS+；无DDD的事件源

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

出于这些原因，我认为使用CQR创建一个事件源系统是一个不错的选择。我所看到的所有例子都围绕着创建聚合来完成任务。我的问题是，因为每一段数据都是一个大的相关集合，我会有少量的大规模聚合。另一种选择似乎是将设置拆分为多个部分，并将每个部分称为聚合。但是，为了进行任何计算，我必须加载数十万个骨料

我的问题是，是否有人拥有以数据为中心的CQRS+ES系统的经验，以及这些系统的外观

有没有更好的方法来存储数据集的历史而不使用ES

---

谢谢您的帮助。

自从我熟悉事件源的想法以来，我总是使用事件存储来存储我正在使用的系统中发生的事情。我将其称为“事件源lite”，当您不真正构建聚合，而是遵循贫乏的模型路线时，只需将所有逻辑放在应用程序服务层（如洋葱中）

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

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

语言检查：聚合仅存在于写入模型（C）中。计算和报告来自read模型（Q）。毕竟，当您报告事件历史时，您并不是在更改/追加它

---

这是一个资产管理系统。每项资产拥有10万台以上的设备

这听起来有点像一个库存跟踪系统。格雷格·杨曾说过“

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

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

---

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

如果不知道数据集有多大，很难回答。计算是如何进行的，等等。这是一个资产管理系统。每项资产拥有10万台以上的设备。每个资产也有许多与之相关的项目。对于资产中的每件设备，每个项目都有一个1k+项目的层次结构。计算是针对一个项目进行的，需要设备（100k+项）加上项目中每个项目的所有数据。感谢您的回复。因此，我有一个资产对象（在本例中是sourcing lite idea），我有使用AssetId与特定资产关联的设备对象。这两个对象是不同的贫血模型。我使用的是CQR，在我的命令处理程序中，我希望迭代特定资产的所有设备。如果我只能通过命令端的ID加载对象，我如何知道要加载哪些设备？我是否将所有ID存储在资源中？我是否使用读取模型存储资产和设备的查找？我读到您不应该在命令处理程序中使用read模型，因为它不能保证一致性。有什么想法吗？我通常先用一种经典的方式（洋葱、贫血模型、rdbms）实现所有东西，所以你的命令是一致的，所有东西都按预期工作。您还可以编写和自动化负载测试，以更好地了解性能瓶颈。然后，您可以开始考虑优化高频命令和查询。你可以考虑为他们中的一些人实施CQRS和“ES满”。我的意思是，CQRS/ES正在成为流行语。你不能在没有充分理由的情况下盲目地应用这些原则。当您应用“完整”或“CQR”时，总是要付出代价，而且大多数情况下，这个代价是代码复杂性。在命令端，只要命令保持一致（如果您依赖于来自cqrs读取模型的陈旧数据，则并非如此），您就可以按自己喜欢的方式加载任何内容。您可以以命令执行时间为代价使读取模型同步。没有一个模型可以解决所有应用程序的所有问题。