C# DDD与其他字段的多对多关系

我有一个模型叫

组织

，另一个模型叫

账户

组织

是创建新的

帐户

的聚合根

组织

至少有一个

账户

一个

组织

至少有一个

帐户

，该帐户是所有者

帐户

需要至少属于一个

组织

账户

需要至少拥有一个

组织

所以我想引入一个名为

organizationaccount

organizationaccount

将保存与

组织相关的所有
账户
，并跟踪其中一个账户是否为所有者

这是一个糟糕的设计吗？什么是更好的方法？网上有一些文章表明，DDD的多对多关系可能非常糟糕

在
organization
模型中维护两个
IEnumerable
属性是否更好
 在没有
组织的情况下处理
账户
有意义吗？如果是，则
组织
不应是包含
科目
的聚合的根。你说一个
账户
需要至少属于一个
组织
；它能属于不止一个吗？如果是，则它不能是
组织
聚合的成员。现在听起来好像
账户
和
组织
只是两个独立的、相关的实体

您可能需要更加努力地工作，以发现在这里工作的底层领域概念；我会尝试通过挑战你的模型来明确
组织
和
账户
之间的关系。
组织能否更改所有者？
帐户
是否可以更改组织
？属于
组织的每个
账户
都能拥有它吗？一个
账户能否比另一个拥有更多的
组织的“股份”

对我来说，你现在设计的最大特点是
组织
和
账户
之间的相互依赖性。这个关系是非常对称的，这告诉我一个不应该是包含另一个的聚合的根。事实上，根据您的措辞，填充一个空宇宙的唯一有效方法是在完全相同的时间创建一个
组织
和一个
账户
，它们已经相互关联。如果他们真的属于同一个聚合，那没关系，但是访问
帐户的唯一方法必须是询问
组织的
所有者是谁，然后<代码>客人
（？）是；除了
组织的成员
聚合之外，任何人都不允许持有对
帐户的引用！这使得
帐户
无法与多个组织关联（因为这样一个组织将持有对属于另一个组织的帐户的引用）

OrganizationAccount
是领域专家熟悉的术语吗？这听起来像是数据库中关联表的名称，但是您应该避免让这样的词进入您的通用语言，除非它们对模型有用。我想到的术语是
组织
和
账户
之间的
合作关系
，听起来至少有两种不同类型的合作关系：一种意味着
所有权
，另一种仅仅意味着
会员资格
。如果我处在你的位置，我会向我的领域专家建议使用
合作关系
，不是因为我认为这是对的，而是因为我想仔细倾听他们不可避免的“好吧，这不是真正的合作关系，更像是[模型发展的下一步]。”
你应该关注行为，而不是结构。看看有界上下文、在这种上下文中应该支持的用例以及您的事务边界。然后确定在这些用例中需要什么类型的信息，并创建一个支持这些信息的模型。确保聚合拥有其所有信息（但不需要任何信息）。除非有令人信服的理由，否则不要与其他有界上下文共享模型。请注意，DDD！=ER规范化设计。感谢您的详细回答。这正是我想要的反馈。当
帐户
在系统上注册时，他们还需要选择其
组织
，这可能是新的或现有的组织。一旦创建了
帐户
，它将根据其所在的
组织
为其分配权限。
账户
可以改变
组织
，从
所有权
提升或降低。DDD对我来说很新，所以我仍在努力适应它。再次感谢您的反馈。