我很努力与我的阅读模型，因为它是一种混合域逻辑和读取模型。想象一下获得酒店或航空公司的报价。在我的例子中，它正在出货。要获得报价，您需要阅读现有的费率表，然后计算费率。您可能会将此日志记录为报价，最终变成订单，但获取的报价部分本质上是读取，其中包含一些逻辑（即获得当前燃料费率的服务）以计入费率。汇总将是一个报价。阅读模型在域
那么你会使用读取模型来获取合同/费率表，并将其映射到域？请记住，读取将被优化，它不仅仅是一个简单的GetByID ...并且最好来自读取存储库以获得性能。
那么你会使用读取模型来获取合同/费率表，并将其映射到域？请记住，读取将被优化，它不仅仅是一个简单的GetByID ...并且最好来自读取存储库以获得性能。
在设计上，聚集应该不需要与任何模型状态的总边界之外立即一致 - “下一个”状态是当前状态的功能，参数传入在其他。单词，理想化的聚合根本不依赖于所读取的模型，并且不涉及其中参数的状态来自哪里的。
这意味着如果您正在努力“当我在此汇总中编写报价时，如何从该汇总中获得当前汇率”，那么某件事是非常错误的。
但是，如果你不需要立即一致性（在大多数情况下，你不需要），那么有很多可能性。
最直截了当的是，客户端从读取模型获取它需要的状态，然后将该状态传递给写入模型。将状态加载到命令中避免了“混淆”，这是REST取得如此成功的原因之一。
在某些情况下，您会希望模型其他部分的“最近”状态更加及时。在这种情况下，您可能更喜欢应用程序在将更改提交给聚合之前，代表客户查询模型。完全合理。
在某些情况下，您会希望聚合本身执行查询。实现此目的的最常见方法是通过域服务：将查询对象传递给聚合，聚合使用适当的状态调用查询，获取答案，然后自行选择如何将结果应用于其目前的工作。
在所有这些中，您从模型中返回的状态是最近的，不一定是当前状态。例如，不能保证模型的其他部分当前没有以查询结果会发生变化的方式进行更改。
请注意，在所有这些情况下，调用者（尤其是聚合）与域服务提供的计算细节完全隔离 - 域服务是唯一需要知道从写入模型计算返回率，从读取模型计算得出，或从缓存中提取。
我的问题是我应该从域内访问读取模型，然后将这些映射到域对象。
不可以。编写模型应该只与它自己的状态及其参数交互。如果您需要在读取模型中查找数据以处理命令，则其中一个参数应该是域服务接口，其中域服务的实现执行查找并将结果转换为域对象。
我明白你在说什么，但在REST帖子中传递状态是不现实的。在这种情况下，我并不担心与其他国家的一致性。我的问题是我应该从域内访问读取模型，然后将它们映射到域对象。这是为了提高性能，因为通常情况下，您可以通过id获得聚合，这是来自优化的只读存储的速度较慢。 –
另一个例子是操作和用户设置。您不需要在后期传递这些信息，您需要从数据库/缓存（回购/读取模型）中获取这些信息，然后根据这些信息执行业务逻辑。 我得到你的聚合应该有一个属性，说一个操作列表，但如何加载是一个问题。 –
如果引号是您的域模型中的第一类实体 - 并且没有非凡的证据，我会期望它们是 - 然后生成一个报价就是写。 – VoiceOfUnreason
是生产它们是写，但得到生产它们所需的信息是一个问题。这可能适用于任何写入操作，其逻辑取决于其他聚集（即用户/帐户设置）来驱动域逻辑 –
引用如何失效？如果你读了一个很快就会改变的比率呢？如果这并不重要，那么只需在域中声明一个RateService接口，然后实现可以从任何地方获取数据，则它变得无关紧要。 – plalx