DDD 与其他字段的多对多关系
DDD Many to Many Relationships with Additional Fields
我有一个模型叫 Organisation，另一个叫 Account。
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 只是两个独立的相关实体。
您可能需要更加努力地工作才能发现这里工作的基础领域概念；我会尝试通过挑战您的模型来充实 Organisation 和 Account 之间的关系。 Organisation 可以更改所有者吗？ Account 可以改变 Organizations 吗？属于 Organisation 的每个 Account 都可以拥有它吗？一个人 Account 可以比另一个人拥有更多 "shares" 的 Organisation 吗？
对我来说，您现在的设计中最大的问题是 Organisation 和 Account 之间的相互依赖。这种关系非常对称，这告诉我一个不应该是包含另一个的聚合的根。事实上，根据您的措辞，填充空宇宙的唯一有效方法是同时创建一个 Organisation 和一个 Account，并且它们已经相互关联。如果它们确实属于同一个集合，那很好，但是 仅 访问 Account 的方法必须是询问 Organization 谁是 Owners 和 ... Guests(?) 是；除 Organization 聚合的成员外，任何人都不得持有对 Account 的引用！这阻止了 Account 与多个组织相关联（因为这样一个组织将持有对属于另一个组织的帐户的引用）。
OrganisationAccount 是领域专家熟悉的术语吗？这听起来像是数据库中关联 table 的名称，但你应该避免让这样的词进入你的通用语言，除非它们对模型有用。我想到的术语是 Organization 和 Account 之间的 Partnership，听起来至少有几种不同类型的伙伴关系：一种暗示 Ownership 和一个简单地暗示 Membership。如果我处于你的位置，我会向我的领域专家推荐术语 Partnership，不是因为我认为它是正确的，而是因为我想仔细听听他们的 inevitable "well, it's not really a partnership, it's more like [the next step in the evolution of your model]."
我有一个模型叫 Organisation，另一个叫 Account。
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 只是两个独立的相关实体。
您可能需要更加努力地工作才能发现这里工作的基础领域概念；我会尝试通过挑战您的模型来充实 Organisation 和 Account 之间的关系。 Organisation 可以更改所有者吗？ Account 可以改变 Organizations 吗？属于 Organisation 的每个 Account 都可以拥有它吗？一个人 Account 可以比另一个人拥有更多 "shares" 的 Organisation 吗？
对我来说，您现在的设计中最大的问题是 Organisation 和 Account 之间的相互依赖。这种关系非常对称，这告诉我一个不应该是包含另一个的聚合的根。事实上，根据您的措辞，填充空宇宙的唯一有效方法是同时创建一个 Organisation 和一个 Account，并且它们已经相互关联。如果它们确实属于同一个集合，那很好，但是 仅 访问 Account 的方法必须是询问 Organization 谁是 Owners 和 ... Guests(?) 是；除 Organization 聚合的成员外，任何人都不得持有对 Account 的引用！这阻止了 Account 与多个组织相关联（因为这样一个组织将持有对属于另一个组织的帐户的引用）。
OrganisationAccount 是领域专家熟悉的术语吗？这听起来像是数据库中关联 table 的名称，但你应该避免让这样的词进入你的通用语言，除非它们对模型有用。我想到的术语是 Organization 和 Account 之间的 Partnership，听起来至少有几种不同类型的伙伴关系：一种暗示 Ownership 和一个简单地暗示 Membership。如果我处于你的位置，我会向我的领域专家推荐术语 Partnership，不是因为我认为它是正确的，而是因为我想仔细听听他们的 inevitable "well, it's not really a partnership, it's more like [the next step in the evolution of your model]."