DDD：我需要多少聚合根？

我有點困惑於DDD中的聚合根概念。該理論告訴它，它應該是一個與當前操作相關的聚合根。DDD：我需要多少聚合根？

例如，我有一個根帳戶，它代表一個公司。它具有地址，屬於該帳戶的用戶以及其他一些屬性。

而且我有幾頁;一個是管理一般信息，如姓名，電子郵件，電話... 另一個是維護地址。再一次顯示所有用戶（並編輯用戶信息，這可能也在帳戶對象下）

在第一種情況下，我不在乎地址，在第二個我不關心名稱，電子郵件.. ..

我需要兩個單獨的Account對象嗎？或者我只需要一個Account？（該模型可能比我描述的更復雜）

因此，舉例來說，我可能最終與類：BasicAccountInformation，AccountAddress，AccountUsers .... 或者只是一個單一的：帳戶其中包含的所有數據？

什麼是正確的DDD方法？我認爲，在某種情況下，我會得到一個非常複雜的類，其中包含很多屬性和邏輯;或者每班有2-10個屬性的很多簡單類。

來源

2016-07-25 Alex Shapovalov

也許你應該考慮你有界的上下文...... –

我想你會發現我的[Aggregate Explained]（http://blog.sapiensworks.com/post/2016/07/14/DDD-Aggregate-Decoded- 1）三部曲對你的問題有用。長話短說，你應該有一個聚合的根，每個商業案例。你可以擁有（你應該有）不止一個代表相同概念的聚合，對於涉及該概念的每個命令商業案例一個 – MikeSW

感謝MikeSW，博客文章增加了這個主題的清晰度。 –

我需要多少個聚合根？

至少有一個。

集合充當一致性邊界。如果您將整個域作爲單個聚合進行建模，並提供一個「聚合根」來確保您的業務不變量由每次寫入保持不變，那麼您就很好。

那麼，你很好走，慢慢來。聚合根是整個邊界中所有狀態的一種序列化瓶頸。如果您希望「同時」更新模型的兩個不同部分，那麼您將需要劃分業務不變的責任。

而且我必須頁;一個是管理一般信息，如姓名，電子郵件，電話......另一個是維護地址。

報告很棒。他們會告訴您需要爲您的模型收集哪些數據。

但是報告很不情願，告訴你你的聚合的位置 - 聚合的主要關注點不是讀取/顯示/報告你的數據，而是寫它。

您可以通過在執行編寫時查找需要分組在一起的模型上的數據來查找聚合。您需要哪些數據來執行業務不變量？

啓發式傾向於吸引CRUD域，因爲大多數模型的狀態與其他模式無關。

您可以查看實體關係;如果兩個集合「共享」一個實體，那麼該實體可能屬於第三個集合。

你可以看到的另一件事是實體生命週期。如果一個子實體能夠超過聚合根，那麼你知道你已經將它建模爲錯誤的。

根據你所描述的，這在這裏也沒什麼幫助;你已經有效地獲得了賬戶，以及其中的一些東西。

有時候所有這些都會失敗，並且最終會使用啓發式的「哪些數據我只想暫時加載一次」，並且您只需將它壓縮到關鍵值存儲區並返回到交付業務價值。

來源

2016-07-26 00:51:25 VoiceOfUnreason

據我理解，當我只需要讀取數據時，我不需要聚合根，並可以返回部分填充的對象，例如， Account GetBasicAccountInformation（accountid）; Account GetAccountWithAddress（accountId）; 或者當你提到報告時，它應該是絕對不同的對象？不是Account，而是AccountBasicInfoDto，AccountAddressDto？ –

使用DTO，而不是域對象。 – plalx

DDD：我需要多少聚合根？

回答

相關問題