一、DDD分層架構
DDD分層架構中有很重要的依賴原則：每層只能與位於下方的層發生耦合，類似於網絡的7層或TCP/IP的4層模型架構，每一層各司其職，並且只關心向下一層的實現，而不會出現各層耦合。
DDD分層架構中包含四層：從上到下分別是用戶接口層，應用層，領域層和基礎層。
二、洋蔥架構
2008年Jeffrey Palermo已經提出了具有分層思想的洋蔥架構，如下圖，同心圓代表軟件的不同部分，從里向外依次是領域模型，領域服務，應用服務和外層的基礎設施和用戶終端。
洋蔥架構根據依賴原則，定義了各層的依賴關系，越往里依賴程度越低，代碼級別越高，越是核心能力。外圓代碼依賴只能指向內圓，內圓不需要知道外圓的情況，這種架構也是典型的分層架構，和DDD分層架構一樣，都體現了高內聚，低耦合的設計特性。洋蔥架構也常作為指導微服務設計的重要架構之一。
三、六邊形架構
2005年Alistair Cockburn提出了六邊形架構，在這個架構中，將應用分為內六邊形和外六邊形兩層，內六邊形實現應用的核心業務邏輯。外六邊形完成外部應用，基礎資源等的交互和訪問，對於與不同的外部系統交互，由外六邊形的適配器負責協議轉換，保證內六邊形業務邏輯的干凈。
這種架構也是典型的分層架構，和DDD分層架構一樣，都體現了高內聚，低耦合的設計特性。六邊形也常作為指導微服務設計的重要架構之一。
四、DDD分層協作
DDD各層的主要職責和怎么分工協作如下圖：
PO（數據持久化對象）：與數據庫字段映射的數據載體
DO（領域對象）：領域模型核心業務對象的載體，包括實體和值對象
DTO（數據傳輸對象）：用於前端和微服務交互的數據傳輸載體
用戶接口層：主要有facade接口，Assembler轉換器
- 微服務面向不同前端時，需要展示的數據可能不同，此時由於需要保持領域核心業務邏輯的穩定，不可能去定制開發各種領域服務和應用服務編排。因此，為避免暴露服務端業務邏輯，防止非必需的字段數據外泄 ，同時保證領域邏輯的干凈，用戶接口層的facade接口和Assembler轉換器就發揮作用了。
- facade接口用於封裝應用服務，適配不同前端需要的字段，提供不同要求的服務接口適配。Assembler根據不同前端的數據請求，完成DTO和領域DO對象的組裝，轉換，完成數據適配。
應用層：
- 應用層連接用戶接口層和領域層，主要協調領域層，面向用例和業務流程，協調多個聚合完成服務的組合和編排，在這一層不實現任何業務邏輯，只是很薄的一層
- 如何判定一個東西是否屬於業務邏輯？
很簡單，只需設想你和產品聊這個事情時，需不需要把這部分信息輸入給它？比如接口調用的處理，數據的轉換，是否加了緩存等等都不屬於產品關心的東西，所以不算是業務邏輯 - 應用層編排成應用服務后，被接口層facade封裝，完成接口和數據適配后，以粗粒度向API網關發布服務
- 應用層還負責事件的訂閱和發布，以及與其他外部服務的交互，事件的具體實現則在領域層
領域層：
- 領域層位於應用層之下，是領域模型的核心，主要實現領域模型的核心業務邏輯，體現領域模型的業務能力
- 領域層關注實現領域對象的充血模型和聚合本身的原子業務邏輯，至於用戶操作和業務流程，則交給應用層去編排。這樣設計可以保證領域模型不容易受外部需求變化的影響，保證領域模型的穩定
- 跨多個聚合的領域邏輯在領域層實現，由領域服務組織和協調多聚合的多實體，實現原子業務邏輯
基礎層：
- 基礎層貫穿了DDD所有層，包括第三方工具，API網關，消息中間件，分布式事務，消息最終一致性能力，數據庫，緩存能能力的提供。
- 基礎層有倉儲模式的代碼邏輯，通過倉儲接口和倉儲實現，解耦領域層和基礎層，保證領域核心業務邏輯的干凈，降低DB資源變化給領域層帶來的影響，這部分內容，請見下回分解。
參考書籍 ——《基於DDD和微服務的中台架構與實現》歐創新、鄧頔
參考書籍 ——《領域驅動設計》Eric Evans
參考書籍 ——《架構真經》Martin L. Abbott