引用自http://www.jdon.com/jivejdon/forum/messagelist.shtml?thread=32093&count=15&start=30
什麼是dao，repository?
在repository情況下，dao其實是多餘的，repository可以完全替代dao。
以jivejdon3打個比喻： forummessage中包含forum和forumhread，這三者是一致性，必須保持不變，在這個系統中必須同進同出，你通過repository獲得乙個forummessage時，它必須將forum和forumhread從各自資料表中讀取後，嵌入forummessage中，形成乙個完整的一致的forummessage。
同理，你對forummessage進行修改時，也必須對其內嵌也就是高聚合的子物件forum和forumhread進行更新，crud都是要這樣。在crud時，你不能單獨對forummessage對應的資料表進行操作，這就破壞物件的不變性。
然而dao則沒有這些規定，就是簡單的資料訪問封裝，至於你是以資料庫為中心的程式設計思路，還是以oo為中心，都不管，實際它更多帶有資料庫思路，所以我也是主張摒棄dao的。
在倉儲也包含crud操作，這些操作必須包括完整聚合關係，保證不變性，比如帖子和論壇之間就是不變性，汽車和汽車發動機和車身都是不變性的，這些都要在倉儲完成，比如儲存汽車時，必須對汽車發動機和車身一同做儲存，而且必須依賴事務全部鎖定，只有乙個使用者才能操作；查詢汽車時，也必須給汽車組裝好汽車發動機等，當然這裡面涉及工廠模式和builder模式。
總之，從倉儲出來的都是像樣的領域模型，倉儲中這種主物件和從物件的一致性也可以通過框架，比如jpa/hibernate實現，不必自己做了。而dao則和資料表結構有關係，屬於資料庫派的；而倉儲是地道的領域物件派
ddd的了解
所謂的 ｄｄｄ無異於將所有的業務抽象到領域層，所有的都是物件，所有的物件對自己負責，具體實現時，我的思路是這樣的：
首先對業務領域建模，擯棄以往的以資料為中心的思想，首先不考慮哪些需要持久化，儘管根據業務流程進行建模，建模完成後，到了我們考慮哪些資料需要持久化了。從領域物件中找出需要持久化的資料模型，再次審視所有的業務物件的職責，或者通俗的說，把握乙個尺度，對於所有與持久化相關的操作，如果是簡單的ｃｒｕｄ則放到對應ｄａｏ中，涉及查詢等放到倉儲中查詢，使用工廠進行物件建立，如對於lay-load之類的問題則可以通過倉儲和工廠解決。大顆粒度操作抽象到對應服務中。最後就是再次在更高的層次審視整個模型，必要時使用ｆａｃａｄｅ 模式，在系統最上方加一層，如果涉及團隊或老系統整合，在必要的context中新增anti-corruption層
關於DDD的學習資料彙總
ddd domain driven design 領域驅動設計，第一次看到ddd是在學習abp時，在其中的介紹中看到的。what,ddd是個什麼鬼，我不是小白，是大白，沒聽過。於是乎，度娘查查查，找到了相關的部落格和文件，然後開始學習的道路。dax.net的領域驅動設計系列文章彙總 netfocus...
DDD 概念中的DDD
領域驅動設計，它是對物件導向的的分析和設計 object orient analysis design 的乙個補充，對技術框架進行了分層規劃，同時對每個類進行了策略和型別劃分。領域模型是領域驅動的核心 採用 的設計思想，業務邏輯不再集中在幾個大型的類上，而是在大量相對小的領域物件上，這些類具有自己的...
DDD 子龍關於聚合的總結
聚合的劃分是需要細心設計的，聚合劃分時除了根據聚合本身的定義外還應該能保證聚合內部元素的一致性，當外界通過聚合根對聚合內的元素進行修改時能使改變的元素與其他元素之間保持設定的一致性，確保概念上的不變。聚合設計大多數時候都會受到主觀因素的影響，有的人喜歡設計大聚合 聚合包含的實體和值物件數量太多 因為...