Jer*_*emy 2 domain-driven-design
在许多应用程序中，我与用户和金融公司打交道（作为示例），并且长期以来我一直在努力根据领域驱动设计原则对两者之间的关系进行建模。
在我的系统中我可以执行以下操作：
我相信两者都是聚合根源......财务公司和用户。
如何建模两者之间的关系？是 FinanceCompany.Users 吗？还是用户.FinanceCompanies？两者都不是吗？或者我是否缺少一些关键 DDD 概念的知识？问题是，如果我选择一种方式而不是另一种方式，则代码从一个聚合根入口点更容易理解/更清晰，但从另一个聚合根入口点则不然。有时，在某些情况下，导航到财务公司并向其添加用户更有意义，而在其他情况下，导航到特定用户并向该用户添加财务公司更有意义。
有没有更好的方法来解决这个问题，也许通过存储库方法？是否有一些我没有理解或理解的关键概念？假设财务公司和用户之间的关系属于 2 个 AR 中的任何一个，这感觉并不正确。当我存储关系时，我必须将其存储在名为 FinanceCompanyUsers 或 UserFinanceCompanies 的表中，但它似乎仍然不清楚。
我是否有诸如 FinanceCompany.AddUser() 和 User.AddFinanceCompany() 之类的代码？或者对于这样的关系有一些完全不同的方法吗？
您已经确定 和User都是FinanceCompany聚合，因此每个都有自己的生命周期。
许多领域的问题在于我们对其中的关系没有完整的理解。作为另一个例子，我们可以采用 anOrder和 a Product。两者都是聚合，但我们会有Order.AddProduct()或 吗Product.AddOrder()？在这种情况下，似乎很明显，anOrder包含有限的Product条目子集，而 aProduct很可能包含许多订单，并且我们对这种关系不太感兴趣，因为它是一种相当弱的关系。AProduct可以在不附加任何订单的情况下存在并有效，但Order如果没有至少一个产品条目，则 An 几乎毫无用处。这意味着Order对其OrderItem条目施加了不变量。除此之外，我们对这个陈词滥调的例子有足够的了解，我们知道我们将需要一个关联实体（用关系理论来说），因为我们需要有关关系的附加信息，并且进入竞争将是我们的OrderItem桌子。奇怪的是我没有看到它被称为OrderProduct.
我建议的指导是选择最合适的一方。
然而，如果没有一方是真正的赢家，并且两个聚合都可以在不与另一方存在不变量关系的情况下存在，那么关系本身就是一个聚合，正如您肯定提到的那样。也许它不仅仅是一个UserFinanceCompany聚合，而且也许领域专家提到的普遍语言中缺少一个概念。也许类似Auditor或类似的东西代表了这种关系。这类似于OrderItemor 的OrderLine概念，而不是OrderProduct。