我有一个名为Organisation的模型，另一个名为Account。DDD与其他字段的多对多关系
Organisation是创建新的Account的总根。
的Organisation至少有一个Account 的Organisation至少有一个Account这是主人
一个Account必须属于至少一个Organisation 的Account需要拥有至少一个Organisation
所以我想引入一个叫OrganisationAccount的模型
OrganisationAccount将持有与Organisation相关联的所有Accounts，并跟踪其中一个是否为所有者。
这是一个糟糕的设计？什么是更好的方法？网上有一些文章指出DDD与多对多的关系可能非常糟糕。
在Organisation模型中维护两个IEnumerable<Account>属性会更好吗？
在没有Organisation的情况下，是否有意义处理Account？如果是，则Organisation不应该是包含Account的聚合的根。你说Account需要属于至少一个Organisation;它可以属于多个？如果是这样，它不能成为Organisation聚合的成员。现在听起来好像Account和Organisation只是两个独立的相关实体。
您可能需要努力一点才能发现这里工作中的底层领域概念;我试图通过挑战你的模型来充实和Account之间的关系。 Organisation可以更换车主吗？ Account可以更改Organizations吗？可以每个Account属于一个Organisation拥有它吗？一个Account可以拥有比另一个Organisation更多的“份额”吗？
对我而言，你现在设计中的大气味是Organisation和Account之间的密切关系。这种关系是非常对称的，它告诉我一个不应该是包含另一个的聚合体的根。事实上，根据你的措词，填充一个空洞宇宙的唯一有效方法是在同一时间创建一个Organisation和Account，它们已经相互关联。这很好，如果他们真的属于相同的聚合，但然后只有方式来访问Account必须要问一个Organization谁的Owners和... Guests（？）是;除Organization聚合成员外，没有人被允许参照Account！这排除Account与多个组织关联（因为那么一个组织将持有对属于另一个组织的引用）。
是OrganisationAccount是专家们熟悉的术语吗？这听起来像数据库中关联表的名字，但是你应该避免让这样的单词进入你的无处不在的语言，除非它们对模型有用。我想到的术语是Organization和Account之间的Partnership，听起来好像至少有几种不同类型的合作伙伴关系：一个意味着Ownership，一个意味着Membership。如果我处于你的位置，我会向我的领域专家建议术语Partnership，这并不是因为我认为它是正确的，而是因为我想仔细聆听他们不可避免的“呃，这不是真正的伙伴关系，更像是[模型演化的下一步]。“
感谢您的详细解答。这正是我正在寻找的反馈。当在系统上注册一个'Account'时，他们还需要选择他们的'Organisation'，这可能是一个新的或现有的。一旦创建了Account，它就会根据它所在的组织'Organisation'赋予它权限。这个'Account'可以改变'Organisation'，从'Ownership'上升或下降。 DDD对我来说是非常新的，所以仍然试图去适应它。再次感谢您的反馈。 –
你应该关注行为，而不是结构。查看有界的上下文，在这种上下文和事务边界应该支持的用例。然后确定在这些用例中需要哪些类型的信息并创建一个支持这些用例的模型。确保一个聚合拥有它的所有信息（但没有它不需要的）。除非有非常有说服力的理由，否则不要与其他有界的环境共享模型。请注意，DDD！= ER设计具有标准化。 – Alex