我相信填充读取模型/投影的事件处理程序的一般指南是使其保持简单。
关于从事件处理程序执行查询的指南，或者最好是使用返回视图所需信息的查找域服务来执行的指南？
我的特定示例是一个包含国家/地区代码的事件，我希望在读取模型中将其显示为国家/地区名称（和其他国家/地区信息）。即。高度稳定的数据，尽管不能保证将来永远不会更改。一些想法：
Option 1：我们可以在命令处理程序中进行查找，并在事件发布时将其添加到事件中。这确实意味着命令处理程序需要纯粹使用域服务来填充事件，并且该值可能需要传递给引发该事件的写入模型。在我看来，这似乎在污染写模型，我想避免这种情况。对我来说，这是最不利的选择。
选项2：查找由事件处理程序执行，该事件处理程序更新了需要国家/地区名称的读取模型/视图。风险：它将db读取（通过域服务）添加到事件处理程序，这将创建一个额外的潜在故障点。重新运行事件以再次投影视图模型可能导致不同的状态。即。那个国家不复存在了。尽管风险很低，但与我的用例中的陈旧数据相比，这实际上可能是更好的结果。
选项3：查找在查询处理程序中执行，并在请求时与视图组合。风险：使查询处理程序复杂化，并在读取点（而不是写入/事件阶段）增加性能命中率。
以前的经历会导致某人建议其中一种选择而不是另一种？
选项2是文献中通常的选择-我们运行一个异步过程，该过程从一个或多个持久性存储中收集值，并组成一个新的表示形式，该表示形式被缓存以供您的只读用例使用。
[实际上，我们从记录簿中读取的“我们的”数据与我们拥有陈旧副本的“它们的”数据之间几乎没有什么区别。
风险：它通过事件服务将db读取（通过域服务）添加到事件处理程序中，从而创建了另一个潜在的故障点。
那又怎样？我们只会失败，然后稍后重试。无论如何，我们的只读视图是陈旧的副本。任何期望纳秒级或更短延迟的人都在自欺欺人。
换句话说，我们不在乎故障，我们关心的是达到服务水平目标，以及我们在多大程度上耗费了错误预算。
重新运行事件以再次投影视图模型可能导致不同的状态。即。那个国家不复存在了。
无论如何，情况总是如此-从您决定进行分布式处理的那一刻起；过时的数据变得不可避免。建模时间可以帮助确保语义保持稳定（即使该国家/地区不再存在，我们也可以继续理解该国家/地区代码的语义。）]