Events CQRS：具有查询或查找服务的复杂事件处理程序

我相信关于填充读取模型/投影的事件处理程序的一般指导是保持它们的简单性

关于从事件处理程序执行查询，或者最好使用返回视图所需信息的查找域服务，有什么指导

我的具体示例是一个包含国家代码的事件，我希望它在读取模型中显示为国家名称（和其他国家信息）。即高度稳定的数据，尽管不能保证它在未来的某个时刻永远不会改变。一些想法：

• 选项1:我们可以在命令处理程序中进行查找，并在事件发布时添加到事件中。这确实意味着命令处理程序需要使用域服务来填充事件，并且可能需要将值传递给引发所述事件的写入模型。在我看来，这似乎污染了write模型，这是我想要避免的。对我来说，这是最不利的选择

• 选项2:查找由事件处理程序执行，该事件处理程序更新需要国家名称的读取模型/视图。风险：它将db read（通过域服务）添加到事件处理程序，这将创建额外的潜在故障点。重新运行事件以再次投影视图模型可能会导致不同的状态。那个国家已经不存在了。尽管风险很低，但在我的用例中，与陈旧的数据相比，这实际上可能是更好的结果

• 选项3:在查询处理程序中执行查找，并在请求时与视图组合。风险：使查询处理程序复杂化，并在读取点而不是写入/事件阶段增加性能影响

---

以前的经验是否会导致有人建议这些选项中的一个而不是另一个？

选项2是文献中常见的选择-我们运行一个异步过程，从一个或多个持久性存储中收集值，并组成一个新的表示形式，缓存以供只读用例使用

实际上，“我们”的数据和“他们”的数据几乎没有什么区别，我们从《史记》中读到了这些数据，而“他们”的数据已经过时了

风险：它将db read（通过域服务）添加到事件处理程序，这将创建额外的潜在故障点

那又怎样？我们将失败，稍后重试。我们的只读视图无论如何都是过时的副本；任何期待纳秒或更好延迟的人都是在开玩笑

换句话说，我们不关心失败，我们关心的是满足我们的服务级别目标，以及我们如何快速地完成错误预算

重新运行事件以再次投影视图模型可能会导致不同的状态。那个国家已经不存在了

无论如何，情况总是这样——从您决定进行分布式处理的那一刻起；陈旧的数据不可避免。建模时间有助于确保语义保持稳定（我们可以继续理解国家/地区代码的语义，即使该国家/地区不再存在）。

感谢您的回复：“那又怎么样？我们将失败，稍后重试。我们的只读视图无论如何都是过时的副本；任何期待纳秒或更高延迟的人都是在自欺欺人。