同一集合中的从属实体 [英] Dependent entities within same aggregate

查看:61
本文介绍了同一集合中的从属实体的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

情况:

我们有一个经典的 Order OrderLine s.每个 OrderLine 都有对 ProductId 的引用.

We have a classic Order with OrderLines. Each OrderLine has reference to the ProductId.

每个 Product 都有其 RelatedProduct .例如产品

class Product {
   string Id;
   string Name;
   string RelatedProductId;
   decimal RelatedProductQuantity;
   .
   .
   .
}

有一条业务规则,每当使用新的 OrderLine Product 添加到 Order 时,然后将 Product 添加到还应将 id = RelatedProductId 添加到 quantity = RelatedProductQuantity 中.

There is a business rule that whenever Product is added to Order with new OrderLine then Product with id=RelatedProductId should also be added in a quantity=RelatedProductQuantity.

问题:

  1. 如何将此规则保留在域内,以使其不会溢出到应用程序服务中,但同时又使 Order 聚合保持干净,从某种意义上讲不会通过注入存储库来毒害它或任何获取数据的东西?

  1. How to keep this rule within the domain so it doesn't spill over to application service but at the same time keep Order aggregate clean in a sense not to poison it by injecting repository or any data-fetching thing?

我们应该使用域服务吗?如果是这样,是否可以将域服务注入存储库,准备所有数据,创建 OrderLine (针对基本产品和相关产品),填写汇总并将其保存到存储库中?

Should we use domain service? And if so, can domain service have repository injected, prepare all the data, create OrderLine (for both, base and related products), fill in the aggregate and save it to repository?

如果以上都不是,建模的最佳方法是什么?

If none of the above, what's the best way to model it?

推荐答案

您将在这里看到两种常见的模式:

There are two common patterns that you will see here:

  • 在您的应用程序代码中获取信息的副本,然后将该信息作为参数传递给域模型
  • 将获取信息的功能作为参数传递给域模型

第二个选项是您经典的域服务"方法,即您使用无状态"实例来获取全局"副本状态.

The second option is your classic "domain service" approach, where you use a "stateless" instance to fetch a copy of "global" state.

但是,从正确的角度来看,您可能会认识到第一种方法是相同的机制-只有应用程序代码而不是域代码才能获取信息的副本.

But, with the right perspective you might recognize that the first approach is the same mechanism - only it's the application code, rather than the domain code, that fetches the copy of the information.

在这两种情况下,仍然是由域模型来决定如何处理信息的副本,所以没关系.

In both cases, it's still the domain model deciding what to do with the copy of the information, so that's all right.

可能的决胜局:

如果您需要复制的信息不是本地的(即:您正在使用分布式系统,并且该信息在本地缓存中不可用),则获取该信息将具有故障模式,并且您可能不想用一堆代码来污染域模型来处理该域模型(与不使用一堆数据库相关问题来污染域代码的方式几乎相同).

If the information you need to copy isn't local (ie: you are dealing with a distributed system, and the information isn't available in a local cache), then fetching that information will have failure modes, and you probably don't want to pollute the domain model with a bunch of code to handle that (in much the same way that you don't pollute your domain code with a bunch of database related concerns).

当很难预先猜测将传递哪些自变量来获取数据时,那么让域代码直接调用该函数可能很有意义.否则,您最终将需要向域模型询问参数的应用程序代码,然后将信息传递回模型中,这甚至可能会来回乒乓几次.

When it's hard to guess in advance which arguments are going to be passed to fetch the data, then it may make sense to let the domain code invoke that function directly. Otherwise, you end up with the application code asking the domain model for the arguments, and the passing the information back into the model, and this could even ping pong back and forth several times.

(并非无法完成:您可以使其正常工作-尚不清楚要保持代码的幸福程度.)

(Not that it can't be done: you can make it work - what's less clear is how happy you are going to be maintaining the code).

如果不确定,请使用感觉更熟悉的方法.

If you aren't sure... use the approach that feels more familiar.

这篇关于同一集合中的从属实体的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆