我有一個名爲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