多个聚合根之间的关系

Question

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

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

• 将用户添加到现有金融公司。
• 为现有用户添加财务公司。

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

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

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

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

Answer 1

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

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

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

但是，如果没有一方是真正的赢家，并且两个聚合都可以存在，而在不变量方面与另一方没有关系，那么关系本身就是你肯定提到的聚合。也许它不仅是一个UserFinanceCompany 聚合，而且也许领域专家所指的无处不在的语言中缺少一个概念。也许像Auditor 这样的东西代表这种关系。这类似于 OrderItem 或 OrderLine 概念，而不是 OrderProduct。