【问题标题】:Read Model in the domain在域中读取模型
【发布时间】:2016-10-03 15:20:56
【问题描述】:

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

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

【问题讨论】:

  • 如果引号是你的领域模型中的第一类实体——如果没有特别的证据,我希望它们是——那么产生一个引号就是一种写。
  • 是的,生产它们是一种写作,但获取生产它们所需的信息是个问题。这可能适用于任何写操作,您的逻辑依赖于其他聚合(即用户/帐户设置)来驱动域逻辑
  • 报价如何失效?如果您读取的汇率很快就会发生变化怎么办?如果这无关紧要,那么只需在域中声明一个 RateService 接口,然后实现可以从任何地方获取数据,它就变得无关紧要了。

标签: domain-driven-design cqrs ddd-repositories


【解决方案1】:

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

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

这意味着,如果您正在为“当我在此汇总中编写报价时如何从该汇总中获取当前费率”而苦苦挣扎,那么就大错特错了。

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

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

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

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

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

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

我的问题是我应该从域内访问读取模型,然后将它们映射到域对象。

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

【讨论】:

  • 我明白你在说什么,但在 REST 帖子中传递状态是不切实际的。在这种情况下,我不担心与其他状态的一致性。我的问题是我应该从域内访问读取模型,然后将它们映射到域对象。这是为了提高性能,因为通常您会通过 id 获得聚合,这比来自优化的只读存储要慢。
  • 另一个例子是操作和用户设置。您不会在帖子中传递这些内容,您需要从数据库/缓存(repo/read 模型)中获取这些内容,然后根据这些内容执行业务逻辑。我知道你的聚合应该有一个属性,比如操作列表,但如何加载是个问题。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2021-05-13
  • 1970-01-01
  • 2012-11-03
  • 2016-05-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多