CQRS（事件溯源）读取多个聚合答案

【问题标题】：CQRS (event sourcing) reading multiple aggregatesCQRS（事件溯源）读取多个聚合
【发布时间】：2018-12-28 15:29:18
【问题描述】：

我有 2 个聚合，它们具有一对多的关系。例如，我有一个问题列表，我想将其中一些添加到问卷中，其中一些是强制性的，必须添加到所有问卷中，有些则不是，由问卷的创建者选择。

假设我正在使用事件溯源和 CQRS。我创建了问题列表，并且我想将强制性问题添加到问卷中。通常我会这样做

questionaire.AssignQuestions(questions.Where(q => q.isMandatory).Select(q => q.Id))

类似的东西。但在 CQRS 中，我不应该为此使用查询模型。但是在命令模型中我使用的是事件存储，所以我必须重播所有问题的所有事件，这似乎不合理。

很可能我的模型不够面向事件，但在这一点上我真的没有更好的主意。我应该如何建模？

谢谢

【问题讨论】：

【解决方案1】：

您的命令处理程序可以查询读取模型以检索问题 ID 列表以形成问卷。

但在 CQRS 中，我不应该为此使用查询模型。

这只是一个错误的神话

【讨论】：

感谢您的回答从我目前听到的情况来看，命令和查询可能位于不同的微服务中。如果是，从命令处理程序访问读取模型的唯一方法是通过 web api。这违反了“不要问，告诉”
在命令端读取“读取模型”的问题，是只有你的聚合中包含的数据是一致的，每次你需要使用/读取聚合所有者之外的数据命令你不能相信它们是最新版本。基本上你有 2 种方法来解决这个问题： 1. 扩展聚合边界，使其包含命令执行所需的所有数据。 2. 查询聚合外部的数据并“容忍”它们可能过时的事实
您似乎处于可以“容忍”陈旧数据同时扩展聚合边界会在您的应用程序中创建大锁的情况（关于这一点，我在另一个问题中做了更好的解释@ 987654321@)
@rascio 是对的，但我只想补充一点，从您的写入模型中查询读取模型可能会引入最终的一致性问题\竞争条件。它可能很好，也可能没有。请注意这一事实。
@SKleanthous 是的，你是对的！这就是我容忍陈旧数据的意思。