在许多应用程序中，我与用户和财务公司打交道（例如），并且我长期以来一直在努力根据域驱动设计原则对两者之间的关系进行建模。
在我的系统中，我可以执行以下操作：
我相信两者都是根源……财务公司和用户。
如何建模两者之间的关系？是FinanceCompany.Users吗？还是User.FinanceCompanies？都不是吗？还是我缺少一些关键DDD概念的知识？问题是，如果我选择一种方法而不是另一种方法，则从一个聚合根入口点开始，代码更易于理解/清除，而从另一根开始。有时在某些情况下导航到财务公司并向其添加用户更有意义，而在另一些情况下，导航到特定用户并向该用户添加财务公司更有意义。
是否有更好的方法可以解决此问题，例如通过存储库方法？这里有一些我没有理解或理解的关键概念吗？认为Finance Company和User之间的关系属于这两个AR中的任一个都不正确。当我存储关系时，我必须将其存储在名为FinanceCompanyUsers或UserFinanceCompanies的表中，但是看起来仍然不清楚。
我将拥有诸如FinanceCompany.AddUser（）和User.AddFinanceCompany（）之类的代码吗？还是有一些完全不同的方法来处理这种关系？
答案 0 :(得分：1)
您已经确定User和FinanceCompany都是聚合，因此每个都有其自己的生命周期。
许多域的问题是我们对关系没有完全的了解。作为另一个示例，我们可以采用Order和Product。两者都是集合，但是我们会有Order.AddProduct()或Product.AddOrder()吗？在这种情况下，Order包含有限数量的Product条目是很明显的，而Product可能包含很多订单，我们对这种关系并不是很感兴趣，因为这是一个微弱的关系。 Product可以存在并且有效，无需附加任何订单，但是Order在没有至少一个产品输入的情况下几乎没有用。这意味着Order的{{1}}项具有不变性。除此之外，我们对这个例子很了解，因为我们需要有关关系的其他信息，所以我们将需要一个关联实体（用关系论的话），因此我们的OrderItem表。奇怪的是我还没有看到它叫OrderItem。
我建议的指导是选择最合适的一面。
但是，如果没有一方是真正的赢家，并且两种总量都可以存在，而就不变性而言，彼此之间没有关系，那么关系本身就是您肯定提到的一种总量。也许它不仅是OrderProduct的集合，而且可能是领域专家所引用的通用语言中缺少的一个概念。也许像UserFinanceCompany之类的东西或代表这种关系的某种东西。这类似于Auditor或OrderItem的概念，而不是OrderLine。