由于也是初學DDD，難免有很多不足和認識錯誤的地方。多數(shù)內容來自其他網(wǎng)絡資料或者書籍。

參考：http://www.cnblogs.com/Leo_wl/p/4418663.html

希望多多提出寶貴意見，謝謝！！！

?

DDD是一套強大的思想工具，是需要根據(jù)業(yè)務進行劃分領域的，無論是否使用領域——對于公共的或獨立的內容都是需要抽象出來的，避免重復造輪子。

DDD可以應用于很多中不同的架構中，如：六邊形架構、SOA、REST、CQRS、事件驅動架構和基于數(shù)據(jù)網(wǎng)絡的架構等等。

REST==>來自百度百科
REST即表述性狀態(tài)傳遞（英文：Representational State Transfer，簡稱REST）是Roy Fielding博士在2000年他的博士論文中提出來的一種軟件架構風格。
它是一種針對網(wǎng)絡應用的設計和開發(fā)方式，可以降低開發(fā)的復雜性，提高系統(tǒng)的可伸縮性。
目前在三種主流的Web服務實現(xiàn)方案中，因為REST模式的Web服務與復雜的SOAP和XML-RPC對比來講明顯的更加簡潔，越來越多的web服務開始采用REST風格設計和實現(xiàn)。'
例如，Amazon.com提供接近REST風格的Web服務進行圖書查找；雅虎提供的Web服務也是REST風格的。

?

六邊形架構（也可以稱之為端口和適配器）：

對于每種外界類型，都有一個適配器與之對應，外界通過應用層API與內部進行交互。

其中的“六”具體數(shù)字沒有特殊的含義，僅僅表示一個“量級”的意思，六邊形的定義只是方便更加形象的理解。

分層架構的重要作用就是避免耦合的出現(xiàn)，經(jīng)典分層架構和六邊形架構都是分層架構的一種，但是所發(fā)揮的作用會有些不同，經(jīng)典分層架構更多的精力放在抽象的分離上，每個層的職責分的很明確，各個層的依賴關系更加抽象化，從而避免耦合的出現(xiàn)，而在六邊形架構中，是用“組件化”的形式來避免耦合的出現(xiàn)，每個業(yè)務單元盡可能的最小化，然后把這些業(yè)務組件集合起來，用一個錘子把他們都拍扁，所以，在整個集合中，這些小的業(yè)務單元都是“平等的”，這種方式用一個詞來概括，那就是“扁平化”。

經(jīng)典分層架構分為四層，而對于六邊形架構，一般會分成三層：

• 領域層（Domain Layer）：最里面，純粹的核心業(yè)務邏輯，一般不包含任何技術實現(xiàn)或引用。
• 端口層（Ports Layer）：領域層之外，負責接收與用例相關的所有請求，這些請求負責在領域層中協(xié)調工作。端口層在端口內部作為領域層的邊界，在端口外部則扮演了外部實體的角色。
• 適配器層（Adapters Layer）：端口層之外，負責以某種格式接收輸入、及產(chǎn)生輸出。比如，對于 HTTP 用戶請求，適配器會將轉換為對領域層的調用，并將領域層傳回的響應進行封送，通過 HTTP 傳回調用客戶端。在適配器層不存在領域邏輯，它的唯一職責就是在外部世界與領域層之間進行技術性的轉換。適配器能夠與端口的某個協(xié)議相關聯(lián)并使用該端口，多個適配器可以使用同一個端口，在切換到某種新的用戶界面時，可以讓新界面與老界面同時使用相同的端口。

在六邊形架構中，領域層和技術沒半毛錢關系，可以看作是業(yè)務的技術實現(xiàn)，端口層包裹在領域層在外，外部要向和領域層“交流”，則必須通過端口層的“首肯”，反過來，領域層向外面“交流”也是一樣，但這種方式一般是技術上的

?

CQRS就是指命令和查詢職責的分離。

?

DDD適用于比較復雜的項目，對于比較小而簡單的項目顯得太過繁瑣，同時對于開發(fā)人員的要求也比較高。

當然DDD的思想是無關項目大小的，而是教我們如何做好軟件...,也有一種說法，OO Done Right的說法——即DDD是以正確的方式來使用面向對象的。

瀑布式開發(fā)方式--》敏捷開發(fā)==》DDD

DDD這種思想，包含的內容也相當豐富，例如：領域、限界上下文、上下文映射圖、架構、實體、值對象、領域服務、領域事件、聚合、資源庫等等...

?

轉載于:https://www.cnblogs.com/YYkun/p/5666326.html

總結

以上是生活随笔為你收集整理的DDD学习笔记一的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。