事件溯源：内存读取模型，在读取期间应用事件是否有意义？答案

【问题标题】：Event sourcing: in-memory read model, does it make sense to apply events during read?事件溯源：内存读取模型，在读取期间应用事件是否有意义？
【发布时间】：2022-02-26 07:22:30
【问题描述】：

我正在开发一个使用事件溯源来存储数据的应用程序。由于许多原因，没有使用持久读取模型，因此我们需要实现内存读取方法。

这个想法是，聚合中的一些数据应该与当前日期一起读取，但也应与过去日期一起读取。因此，我正在考虑的方法是处理该聚合的所有事件和Apply 聚合中的事件，以便在指定日期获得状态。

但是，我在各种文章中读到 Apply 方法应该只在命令发出时使用，而不是在读取阶段。

在阅读阶段使用Apply 方法有意义吗？或者也许应该用不同的方法（某种处理器）复制相同的逻辑？

我没有在此处发布任何代码，因为我正在寻找的是了解正确的方法应该是什么，并更好地了解如何使用事件溯源。

【问题讨论】：

“阅读各种文章” -- 可以提供链接吗？
@VoiceOfUnreason 基本上我读过的所有文章都指出，虽然它们提供了不同的方法来创建阅读模型
所以你基本上需要读取聚合的状态，对吧？
@ConstantinGalbenu yew 基本上我需要读取聚合状态以提取一些属性。您认为在读取阶段读取聚合是正确的方法吗？

标签： domain-driven-design event-sourcing

【解决方案1】：

应避免读取聚合的 internal 和 private 状态，因为它会破坏其封装。此外，聚合存储它需要的任何状态以检查其不变量并查询该状态将强制聚合保持不需要的其他状态。

总之，避免读取写入端。

【讨论】：

你是对的，应该避免暴露聚合的内部和私有状态。谢谢

【解决方案2】：

我认为Apply 方法不一定只能在发出事件时调用。如果Apply 方法的目的是将事件加载到聚合中，那么它将在将聚合恢复到当前状态时调用。

似乎您需要处理您的聚合，以在某个窗口期（开始/结束日期）内代表它。可能更适合创建一个表示您感兴趣的位的读取模型并将它们存储为时间敏感数据，然后查询那个。

如果处理过于密集，您甚至可能想要发出一个命令，请求报告或排序视图，但仍然可以通过时间敏感读取模型，然后产生所需的输出。完成后，可以通知用户结果可供阅读。

正如@Constantin Galbenu 所说：您应该避免聚合的内部状态，这与不查询您的域模型有关。

【讨论】：

是的，这看起来是最好的选择。最后，永远不应在命令堆栈之外调用 Apply 方法，因此在某些情况下，我应该发送一个命令来生成我正在寻找应用事件的结果，然后通知用户。谢谢