why
通過對DDD結構的了解，方便在服務化實踐中更好的操作。
what
松散4層架構：
結構概圖如下：
User Interface為用戶界面層（或表示層），也可理解為對外接口層。負責向使用者顯示信息和解釋用戶命令；
Application為應用層，定義軟件要完成的任務，並且指揮領域對象來解決問題，並將domain的內容整合成具體業務需要的結果形式。應用層應該盡量簡單，其不包含業務規則或者知識，而只為下一層中的領域對象協調任務，分配工作。
Domain為領域層（或模型層），是業務軟件的核心，其負責表達業務概念、業務狀態信息以及業務規則。。雖然保存業務狀態的技術細節是由基礎設施層實現的，但是反映業務情況的狀態是由本層控制並且使用的。
Infrastructure層為基礎實施層，向其他層提供通用的技術能力，為應用層傳遞消息，為領域層提供持久化機制。礎設施層還能夠通過架構框架來支持四個層次間的交互模式。
系統結構：
實踐改造見后面的嚴格4層中的圖。
領域層實現核心業務邏輯，負責表達領域模型業務概念、業務狀態和業務規則。主要的服務形態有實體方法和領域服務。DDD 提倡富領域模型，盡量將業務邏輯歸屬到實體對象上，實在無法歸屬的部分則設計成領域服務。領域服務會對多個實體或實體方法進行組裝和編排，實現跨多個實體的復雜核心業務邏輯。
應用層的主要服務形態有：應用服務、事件發布和訂閱服務，沒有業務狀態。為了實現微服務內聚合之間的解耦，聚合之間的服務調用和數據交互應通過應用服務來完成。原則上我們應該禁止聚合之間的領域服務直接調用和聚合之間的數據表關聯。
特點：
領域層的實體方法和領域服務可以直接暴露給應用層和用戶接口層。松散分層架構的服務依賴關系，無需逐級封裝，可以快速暴露給上層。
嚴4層架構：
每一層服務只能向緊鄰的上一層提供服務。雖然實體、實體方法和領域服務都在領域層，但實體和實體方法只能暴露給領域服務，領域服務只能暴露給應用服務。
相對松散4層結構，Infrastructure只能由Domain層使用，並且Infrastructure依賴、繼承Domian層的數據交互接口repository（即為domain層服務）。具體的依賴關系如下圖：
依賴結構原因：業務領域模型低耦合，高內聚。防止數據依賴方的變化，特別是在商業化的項目中，客戶的數據源千變萬化。
系統中數據的層次關系：
數據持久化對象 PO(Persistent Object)：與數據庫結構一一映射，是數據持久化過程中的數據載體。
領域對象 DO（Domain Object）：微服務運行時的實體，是核心業務的載體。
數據傳輸對象 DTO（Data Transfer Object）：用於“前端與應用層”或者“微服務之間”的數據組裝和傳輸，是應用之間數據傳輸的載體。
視圖對象 VO（View Object）：用於封裝展示層指定頁面或組件的數據。
實際使用中的折中：
應用層實現接口、負責領域服務的編排和組裝外，還負責將中間結果數據直接轉為接口的DTO
數據交互如下：
domain層中的一個聚合對應一個聚合代碼目錄，聚合之間在代碼上完全隔離，聚合之間通過應用層協調。那么以后業務發展大了以后就可以方便拆分了。具體代碼如下：
六變形架構：
六邊形架構也稱為端口與適配器，如下圖：
六邊形每條不同的邊代表了不同類型的端口，端口要么處理輸入，要么處理輸出。對於每種外界類型，都有一個適配器與之對應，外界通過應用層API與內部進行交互；同時DDD戰術設計的建模元素Repository的實現看作是持久化適配器，該適配器用於訪問先前存儲的聚合實例或者保存新的聚合實例。
六邊型有很多演化，例如：
Jeffrey Palermo在2008年提出了洋蔥架構，六邊形架構是洋蔥架構的一個超集。
Robert C. Martin在2012年提出了干凈架構（Clean Architecture），這是六邊形架構的一個變體。
Russ Miles在2013年提出了Life Preserver設計，這是一種基於六邊形架構的設計。
參考學習文檔：https://cloud.tencent.com/developer/article/1837097