DDD：選擇聚合根

在我的情況下，我有兩個主要概念：用戶（系統的主要公民）和組。集團有兩個子集合：等級和角色。沒有團隊，等級和角色就沒有意義。當用戶被分配到該組時，我們還必須選擇1個角色和1個等級，並將其分配給用戶和組之間的這種關係。DDD：選擇聚合根

問：

多少總根嗎，我這裏？從用戶方面來看，它顯然是一個用戶（系統的主要概念），但它與組的關係呢？ AFAIK由DDD的規則禁止引用聚合根之外的實體。

2017-05-05 Arter Cadelanne

AFAIK由DDD的規則禁止引用聚合根外的實體。

嗯，我不會說這是「DDD的規則禁止」......有些時候你別無選擇。我必須考慮與根集合關聯的「實體」集合的大小。有時您可以在相同的聚合中維護關聯，並使用某種「延遲加載」來避免資源消耗。弗農的iDDD書[1]圍繞這個具體案例提供了一些建議和使用案例。看看他的博客文章[2]

[1] https://www.amazon.com.br/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577 [2] https://vaughnvernon.co/?p=838

來源

2017-05-05 22:10:49 Tuelho

或者可以使用最終的一致性 –

你至少有以下選擇，這取決於你的業務需求方面的一致性：

您有5個聚合根：用戶，組，排名，角色和UserAssignment。最後一個必須保護不變「我們還必須選擇1個角色和1個等級」。對於終身管理，您可以使用AR之間的最終一致性。例如，當您刪除一個組時，您還必須刪除孤兒排名，角色和用戶分配。
你有用戶（UserAssignment作爲嵌套實體）和Group（角色和秩作爲嵌套實體）。您在AR中具有很強的一致性（當您刪除用戶時，其所有分配也會被刪除）以及用戶和組之間的最終一致性。

你應該使用什麼？只有你可以決定。例如，如果您選擇第一個選項並刪除用戶，則可能會延遲幾秒/分鐘/小時，然後其分配也被刪除。

由於價格並不便宜，所以應使用強力套牌保護業務不變式real。

P.S.如果您需要從另一個AR中引用嵌套實體，那麼您應該重新考慮您的聚合根邊界，因爲您的設計很可能是錯誤的。

來源

2017-05-06 09:42:22

基本上，沒有其父組，兩個角色和等級都沒有意義。它就像：「你好，我是國王[角色]。」「什麼[羣]的王？」。「NullPointerException」。應用程序本身非常以用戶爲中心，一切都圍繞用戶的概念發展。在第二種選擇中，碰巧我們有2個聚合 - 用戶和組，對嗎？但用戶分配（用戶實體中的嵌套實體）引用組聚合中的嵌套實體。這是你的意思還是我不瞭解你？ –

然後使用選項1和2的組合。我還試圖讓您理解如何思考設計聚合：一致性邊界。沒有絕對的答案。 –

我們可以儘可能多地討論，以便了解，但沒有人可以確切地告訴您該做什麼 –

我要改變一些的話，我們將看看是否有幫助（假設）：

我有一個Order和Product。當我將Product添加到Order時，我必須選擇一個Store和Colour。

你會如何模型？

Colour很可能是一個Value Object，但Store不是。我會選擇一個OrderItem值對象，其中包含一個Colour值對象和一個StoreId值來捕獲關係。 Order將包含OrderItem條目的列表。

刪除Colour條目沒問題，因爲我們已將該位非規格化到OrderItem。我們可能有另一個值對象代表Store，但通常我們不會刪除存儲或有一些處理來處理刪除，或者更典型的，使用參照完整性約束來防止刪除已使用的Store。

如果您考慮刪除Order，則只會刪除OrderItem關聯。

在你的情況User和Group可能是總根源，我想補充一個UserGroup（或UserAssignment爲康斯坦丁使用）。 UserGroup包含關聯和相關位。你將不得不確定真正的域名結構。

來源

2017-05-08 06:54:20

DDD：選擇聚合根

回答

相關問題