在聚合的DDD根中是檢索其子對象的唯一引用。聚合根的存儲庫僅負責提供根對象引用。如果我需要子對象，則需要調用聚合的getter方法來檢索導致DB查詢的子對象。在DDD中檢索聚合的子對象
考慮一個我從數據庫中檢索多個聚集的情況。所以在我的情況下，這種情況會導致多個數據庫查詢，從而導致請求非常緩慢。如何在DDD方面避免這種情況。爲了堅持，我遇到了一種叫做Unit Of Work的模式。是否有任何解決我的問題或任何其他方式來執行此操作的搜索模式。
首先，你的ORM解決了95％的問題（如果你碰巧使用關係數據庫）。
聚合根存儲庫應該（大多數情況下）返回一個完全加載的對象與所有子對象（實體）。延遲加載兒童應該是一個例外，而不是一個規則。
另一件事是，您應該避免一次加載並保持多個聚合。嘗試重新分區域，以便每個用戶交互只處理一個聚合。
並考慮一個文檔數據庫解決方案。它確實使得將整個聚集作爲文檔存儲在doc數據庫中變得十分合理。
Okey好像你有一個場景，你在一個用例中想要從幾個AR中讀取數據並將他們的狀態保存到數據庫中。讀操作需要很長時間嗎？或者它是讀取和寫入，需要時間？
您的域模型和聚合根應該部分通過用例間的交互來定義。我所說的是，該模型應該設計成適合您的客戶需求。這種情況似乎不像一個適合你的模型。
使用大數據視圖的報告或其他操作應繞過域模型。不要將DDD用於報告等。只需快速訪問數據。
二。如果您希望所有聚合參與交易，則工作單位是一種方法。
三。我會說，使用懶加載，但一些需要性能提升的用例，你可以做一個加載策略，這意味着你讓根加載一些子集合，而不必使用sql-sub-selection開火...... 看這篇文章http://weblogs.asp.net/fredriknormen/archive/2010/07/25/loading-strategy-for-entity-framework-4-0.aspx（即使它對於EF模式也適用於NH ORM）
然後最後總是可以提供數據庫索引，緩存等以提高性能，但是考慮到場景信息，您有許多錯誤的設計需求。我沒有全部的事實，但也許有些使用案例不適用於
如何將您的實體映射到數據庫？使用NHibernate，EF等？如果是，請指定您的ORM，以便我們可以提供具體的指導。 – 2011-05-23 13:15:57