时间戳

首页 > 解决方案 > 多个聚合根之间的关系

domain-driven-design - 多个聚合根之间的关系

问题描述

在许多应用程序中，我与用户和金融公司打交道（例如），长期以来，我一直在努力根据领域驱动设计原则对两者之间的关系进行建模。

在我的系统中，我可以执行以下操作：

我相信两者都是聚合根......金融公司和用户。

我如何建模两者之间的关系？是 FinanceCompany.Users 吗？还是 User.FinanceCompanies？不是吗？还是我缺少一些关键 DDD 概念的知识？问题是如果我选择一种方式而不是另一种方式，则代码从一个聚合根入口点更容易理解/清晰，但不是另一个。有时导航到财务公司并向其添加用户更有意义，而有时导航到特定用户并向用户添加财务公司更有意义。

有没有更好的方法来解决这个问题，也许是通过存储库方法？是否有一些我在这里没有得到或理解的关键概念？假设财务公司和用户之间的关系属于 2 个 AR 中的任何一个都是不正确的。当我存储关系时，我必须将其存储在名为 FinanceCompanyUsers 或 UserFinanceCompanies 的表中，但它似乎仍然不清楚。

我会有 FinanceCompany.AddUser() 和 User.AddFinanceCompany() 之类的代码吗？还是有一些完全不同的方法来处理这样的关系？

标签： domain-driven-design

解决方案

您已经确定两者User和FinanceCompany都是聚合，因此每个都有自己的生命周期。

许多领域的问题是我们对关系没有完整的理解。作为另一个例子，我们可以采用 anOrder和 a Product。两者都是聚合，但我们会有Order.AddProduct()orProduct.AddOrder()吗？在这种情况下，很明显 anOrder包含有限的Product条目子集，而 aProduct很可能包含许多订单，我们对这种关系不太感兴趣，因为它是一个相当弱的关系。AProduct可以在没有附加任何订单的情况下存在并且有效，但如果Order没有至少一个产品条目，则 an 非常无用。这意味着Order有一个不变量OrderItem条目。除此之外，我们对这个陈腐的例子有足够的了解，我们知道我们将需要一个关联实体（在关系理论中），因为我们需要有关关系的更多信息，并且进入战斗将是我们的OrderItem表。奇怪的是我还没有看到它叫OrderProduct.

我建议的指导是选择最合适的一方。

但是，如果没有一方是真正的赢家，并且两个聚合都可以在没有与另一方的关系的情况下存在，那么关系本身就是您肯定提到的聚合。也许它不仅是一个UserFinanceCompany集合，而且可能是领域专家所引用的无处不在的语言中缺少的一个概念。也许类似Auditor或类似的东西代表了这种关系。这类似于OrderItemorOrderLine概念，而不是OrderProduct.

推荐阅读