domain-driven-design - 在域中读取模型

Question

我正在为我的读取模型而苦苦挣扎，因为它是域逻辑和读取模型之间的一种混合。想象一下获取酒店或航空公司的报价。在我的例子中，它正在运输。要获得报价，您需要阅读现有的费率表，然后计算费率。您可能会将其记录为报价，最终变成订单，但获取报价部分本质上是一个读取，具有一些逻辑(即获取当前燃料费率的服务)来考虑费率。聚合将是一个报价。

那么您会使用读取模型来获取契约(Contract)/费率表，并将其映射到域吗？请记住，读取将被优化，它不仅仅是一个简单的 GetByID ......并且最好来自读取存储以提高性能。

Answer 1

So would you use the read model to get the contract/rate table, and map that to the domain? Keep in mind the read is going to be optimized, it's not just a simple GetByID... and preferably coming from the read store for performance.

按照设计，聚合不需要立即与聚合边界之外的任何模型状态保持一致——“下一个”状态是当前状态和传入参数的函数。换句话说，理想化聚合不' 根本不依赖于读取模型，也不关心参数的状态来自哪里。

这意味着，如果您正在努力解决“当我在此汇总中编写报价时如何从该汇总中获取当前汇率”，那么就大错特错了。

但是，如果您不需要立即保持一致性(在大多数情况下，您不需要)，那么有很多可能性。

最直接的方法是客户端从读取模型中获取它需要的状态，然后将该状态传递给写入模型。将状态加载到命令中可以避免“困惑”，这也是 REST 如此成功的原因之一。

在某些情况下，您会希望模型其他部分的“最近”状态更及时。在这种情况下，您可能希望应用程序在将更改提交到聚合之前代表客户端查询模型。完全合理。

在某些情况下，您会希望聚合本身执行查询。实现这一点的最常见方法是通过域服务:向聚合传递一个查询对象，聚合以任何合适的状态调用查询，得到答案，然后自己选择如何将结果应用到它的目前的工作。

在所有这些中，您从模型中恢复的状态是最近的，不一定是当前的。例如，不能保证模型的其他部分当前不会以查询结果会发生变化的方式发生变化。

请注意，在所有这些情况下，调用者(尤其是聚合)与域服务提供的计算细节完全隔离——域服务是唯一需要知道返回的速率是否被计算的部分从写入模型，从读取模型计算，或者只是从缓存中提取。

My question is should I access the read model from within the domain, and then map those to domain objects.

不可以。写模型应该只与它自己的状态和它的参数交互。如果您需要在读取模型中查找数据来处理命令，那么其中一个参数应该是域服务接口(interface)，域服务的实现执行查找并将结果转换为域对象。