CQRS：写模型可以消耗读模型吗？

Question

在阅读 CQRS 时，经常提到写入模型不应依赖于任何读取模型（假设有一个写入模型和最多 N 个读取模型）。这很有意义，特别是因为读取模型通常只会最终与写入模型保持一致。此外，我们应该能够在不破坏写入模型的情况下更改或替换读取模型。

但是，读取模型可能包含跨写入模型的许多实体聚合的有价值信息。这些聚合甚至可能包含重要的业务规则。可以很容易地想象一个业务策略，它评估读取模型拥有的一条信息，并通过写入模型更改一个或多个实体。但是这个政策应该在哪里定位/实施呢？这不是将来自特定读取模型的信息与写入模型紧密耦合的关键业务逻辑吗？

当我想在不将写入模型与读取模型耦合的情况下实现上述策略时，我可以想象以下策略：在写入模型中包含一个物化视图，该视图会在相关部分同步更新所涉及的实体发生变化（使用 DDD 时，这可以通过域事件来完成）。然而，这将写入模型反规范化，实际上是嵌入在写入模型本身中的特殊读取模型。

我可以想象 DDD 纯粹主义者会说这样的政策不应该存在，因为它代表了一个包含多个实体（又名聚合）的业务不变量/规则。理论上我可能会同意，但在实践中，我还是经常遇到这样的要求。

最后，我的问题很简单：您如何处理根据某些条件更改数据的要求，这些条件的评估需要读取模型？

Answer 1

首先，任何验证命令的写入模型都是读取模型（因为在某些时候验证命令需要读取），尽管它是为验证命令而优化的。所以我不确定你在哪里看到写模型不应该依赖于读模型。

其次，域事件隐含地是对事件消费者的命令：“处理/考虑/合并此事件”，在这种情况下，写入模型处理器可以订阅来自不同写入模型的事件：从从订阅写入模型的角度来看，这些只是命令。

Answer 2

阅读了很多关于该主题的内容并自己认真思考过，我尝试回答我自己的问题。

首先，澄清所使用的术语。写入和读取模型自身从不相互依赖。相应的命令和查询组件可能有。因此，我将命令组件及其写入模型的整体称为命令端，将一个特定查询组件及其读取模型的整体称为查询端（其中可能有很多）。

因此，请考虑一个负责评估和执行业务策略的命令处理程序。它接受一个命令 DTO，对其进行验证，将部分写入模型加载到内存中，并在一个原子事务中对其应用更改。具体的问题是，是否允许此处理程序查询其中一个查询方，以便通知其决定在写入模型中做什么。

答案将是响亮的NO。原因如下：

• 命令端将依赖于一个特定的查询端（是否将依赖项隐藏在接口后面并不重要——它仍然存在），因此查询端不能独立更改。
• 谁真正保证命令处理程序在必要时运行？查询端当然不是负责的，客户端也不是。
• 执行嵌套查询请求会延长命令请求，这可能会损害性能。

相反，我们可以执行以下操作：

• 使用写入模型引发的域事件，在评估策略的命令端注册域事件处理程序。这样就可以保证在需要的时候执行策略。
• 如果性能允许，此域事件处理程序可以简单地加载所需的写入模型，以评估业务状况。不要过早优化——也许实体很小，很容易加载到内存中。
• 如果性能不允许，非规范化写入模型并使用域事件维护所需的统计信息。没有人说写入模型本身不能包含面向查询的数据。作为一个写模型只是说它是一个被设计用来写的模型，这也必然包括一些读取的方法。
• 最后，如果应用策略不是域逻辑本身的一个组成部分，而只是一个用例，请考虑将调用它的责任放到客户端或其他微服务中，首先查询我们的查询端，然后使用适当的参数调用我们的命令端是完全可以的。