域驅動設計中的根集合問題

Question

我有兩個Entities Publisher和SocialAccount，兩者都是獨立的並且具有多對多的關係。兩者都是根集合，現在我無法通過Publisher獲取社交帳戶，我想將M到M的關係轉換爲1到M.所以我介紹了另一個實體註冊，將{{PubID，SocID，CreateDate}。現在註冊和SocialAccount之間存在1到1的發佈者和註冊之間的關係，以及1到1之間的關係。所以發行商將具有

列表<註冊記憶> _Registrations {獲得;設置;}

但是，當我創建聚合邊界，發佈者是我的根，並根據總的原則，只有root合計將持有參考到另一個根集合。但是這裏註冊舉辦參考。

所以我違反了總體原則，因爲註冊是連接的社會帳戶實體。

Answer 1

您對聚合概念的使用看起來不正確。聚合中的對象實際上可以持有對其他聚合的引用。該規則是一個外部對象不能持有對聚合內某些東西的引用。

在註冊對象上，您似乎已經創建它以避免某些聚合到聚合關係。這不是你創建對象的原因。如果您的域中實際上存在註冊，則創建它並對其進行建模。如果它不在您的域中，請不要添加它來遍歷某個路徑。

添加註冊後，您說它無法持有對社交帳戶的引用，因爲它是Publisher的一部分。這不是規則，但更重要的是，註冊如何突然成爲發佈者聚合的一部分？憑藉僅具有註冊集合的Publisher？

聚合是一組對象，它們被視爲一個單位來維護狀態和不變量。關係本身的存在並不賦予聚合中的成員資格。

但現在看看對方。使用社交帳戶註冊爲1比1。如果我們刪除了社交賬戶，它是否有意義仍然有發佈商註冊？如果不是，則註冊可能實際上是SocialAccount聚合的一部分。這就是我們創建聚合的原因 - 確保在狀態更改後對象及其關係始終有效。如果刪除SocialAccount的狀態更改包括刪除與該帳戶關聯的所有註冊，我們希望將其包含在聚合中以實施該規則。

現在您確實違反了「聚合規則」 - 您與發佈商之間存在外部關係，即對象Registration，即SocialAccount聚合的內部部分。

這些概念不僅僅是規則，他們有理由。你需要回顧一下聚合的真正含義，理解規則的實際內容以及它們的真正含義，爲什麼它們首先存在。然後重新評估您的關係並相應地聚合定義。

Answer 2

首先我們需要一個抽象來在模型中封裝引用。

AGGREGATE是一組關聯對象，我們將其視爲一個單元用於數據更改。

每個AGGREGATE都有一個根和一個邊界。邊界定義了AGGREGATE內部的內容。根是AGGREGATE中包含的單個特定的實體。根是外部對象允許持有引用的唯一AGGREGATE成員，但邊界內的對象可以持有對彼此的引用。除root以外的實體具有本地身份，但該身份只能在AGGREGATE內區分，因爲外部對象無法將其從根實體的上下文中看出來。

你認爲這是什麼Ssyphus？