Bra*_*ets 6 domain-driven-design ddd-repositories cqrs
我正在努力使用我的读模型,因为它是域逻辑和读模型之间的混合.想象一下获得酒店或航空公司的报价.在我的实例中它正在发货.要获得报价,您需要阅读现有的费率表,然后计算费率.您可以将此记录为报价,最终变成订单,但获取报价部分本质上是一个读数,其中一些逻辑(即获得当前燃料费率的服务)将其计入费率.汇总将是报价.
那么您是否会使用读取模型来获取合同/费率表,并将其映射到域？请记住,读取将被优化,它不仅仅是一个简单的GetByID ...并且最好来自读取存储以获得性能.
那么您是否会使用读取模型来获取合同/费率表,并将其映射到域？请记住,读取将被优化,它不仅仅是一个简单的GetByID ...并且最好来自读取存储以获得性能.
按照设计,聚合不需要立即与聚合边界之外的任何模型状态一致 - "下一个"状态是当前状态的函数,并且参数传入.换句话说,理想化聚合不会根本不依赖于读取模型,并且不关心参数的状态来自何处.
这意味着如果你正在努力"当我在这个聚合中写一个引号时如何从该聚合中获得当前的比率",那么就会出现严重错误.
但是如果你不需要立即一致性(在大多数情况下,你没有),那么有很多可能性.
最直接的是客户端从读取模型获取所需的状态,然后将该状态传递给写入模型.将状态加载到命令中可以避免"混淆",这是REST如此成功的原因之一.
在某些情况下,您会希望模型其他部分的"最近"状态更加及时.在这种情况下,您可能希望应用程序在将更改提交到聚合之前代表客户端查询模型.完全合理.
在某些情况下,您将希望聚合本身执行查询.实现此目的的最常见方法是通过域服务:将聚合查询对象传递给聚合,聚合以适当的状态调用查询,获得回复,然后自行选择如何将结果应用于其目前的工作.
在所有这些中,您从模型中返回的状态是最近的,不一定是最新的.例如,无法保证模型的其他部分当前不会以查询结果发生变化的方式进行更改.
请注意,在所有这些情况下,调用者(特别是聚合)与域服务提供的计算细节完全隔离 - 域服务是唯一需要知道返回的速率是否计算的部分来自写入模型,从读取模型计算,或从缓存中拉出.
我的问题是我应该从域中访问读取模型,然后将它们映射到域对象.
不可以.写模型应该只与自己的状态及其参数进行交互.如果需要在读取模型中查找数据以处理命令,则其中一个参数应该是域服务接口,其中域服务的实现执行查找并将结果转换为域对象.