趁著雙十一備戰封板，終於又有一些時間可以梳理一下最近的心得。最近這半年跟同事討論比較多的是分層架構，然後就會遇到兩個觸及靈魂的問題，一個是如何做好分層架構，二是DDD在架構層面該如何落地。 ...
前言
趁著雙十一備戰封板，終於又有一些時間可以梳理一下最近的心得。
最近這半年跟同事討論比較多的是分層架構，然後就會遇到兩個觸及靈魂的問題，一個是如何做好分層架構，二是DDD在架構層面該如何落地。
為了說好分層，我們需要瞭解架構的意義。
良好的架構是為了保證一下兩點：
- 治理應用複雜度，降低系統熵值；
- 從隨心所欲的混亂狀態，走向井井有條的有序狀態。
比如，你去圖書館借閱書籍，對於紛繁雜亂的各類書籍，如果不能很好的管理和分類，必然會導致圖書館管理混亂，效率低下，使得圖書館不能正常運維。而分層架構的意義也在於此，當我們面對複雜的業務需求時，需要更好的規劃我們的包結構和依賴規約，可以更好的治理我們的服務，提升服務的可維護性，可擴展性，做到我們的架構以業務為核心，解耦外部依賴，分離業務複雜度和技術複雜度。
傳統分層架構有MVC，而這些年流行的六邊形架構，也是伴隨著DDD的興起而逐步被大家所接受。如果說DDD和六邊形架構的關係，他倆屬於不同層級的概念，DDD更偏向方法論，註重領域建模和業務邏輯的設計，強調將業務需求和領域知識轉化為軟體設計；而六邊形架構更註重系統的整體架構和模塊化設計，強調分離內部和外部系統的交互。他們倆的結合是一種非常好的實踐經驗， DDD中的領域模型是核心，其他層（如應用層、基礎設施層）依賴於領域模型；而六邊形架構正好為DDD提供了一種非常好的分層落地。
淺聊DDD落地
對於DDD，並沒有一種所謂的框架或者腳手架能夠對應，其根本原因在於，DDD其實是一種方法論，而非所謂的框架，它給我們提供了一種應對業務複雜度時的方法：
- 通過架構設計來分離業務複雜度和技術複雜度；
- 通過限界上下文去做到分而治之，將大系統拆解為若幹個高內聚低耦合的子域；
- 通過面向對象的設計模式，將業務子域的知識進行抽象。
總結一下：
- DDD的戰略建模註重子域的劃分和限界上下文的定義。對應到落地就是包的拆解， 以及包之間的依賴和組合關係。
- 而DDD的戰術建模主要關註的是構造塊和柔性設計。構造塊就是我們常說的，類，對象，組合。而柔性設計就是我們面向對象的設計原則，得到一個高內聚低耦合的系統。所以說，DDD的戰術建模落地，一定伴隨著開發人員對設計模式的深刻理解和應用。
六邊形分層架構
1. App層
應用層是DDD中的頂層，負責協調和組織領域對象的交互。它接收來自用戶界面或外部系統的請求，並將其轉發給領域層進行處理。應用層負責定義應用的用例（Use Cases），處理事務邊界和協調領域對象的操作。它不包含業務邏輯，而是將請求轉化為領域對象的操作。應用層還可以包含獲取輸入，組裝上下文，參數校驗，異常定義，發送事件通知等。
2. Domain層
主要是封裝了核心業務邏輯，並通過領域服務（Domain Service）和領域對象（Domain Entity）的方法對App層提供業務實體和業務邏輯計算。領域是應用的核心，不依賴任何其他層次。同時領域層會有一個facade層，當領域服務對外部有調用依賴時，通過定義facade介面實現控制反轉。
3. Adapter層
負責與外部系統進行或者服務進行適配和集成，包括通信，數據緩存，介面適配等功能。
此外強調， RPC consumer調用放在適配器層。適配器層專註於與外部系統的集成和適配，將外部系統的介面和數據格式轉換為應用程式可以理解和處理的形式。將RPC調用放在適配器層可以更好地將與外部系統相關的技術細節與應用程式的業務邏輯和領域對象進行解耦，提高應用程式的可擴展性和可維護性。
對於所有出站適配層，都需要通過實現facade介面實現控制反轉。
4. 基礎設施層
負責提供支持應用程式運行的基礎設施，包括與具體技術相關的實現。基礎設施層通常包括與資料庫、消息隊列、緩存、外部服務等進行交互的代碼，以及一些通用的工具類和配置，也包括filter等實現。
基礎設施層和適配器層之間的關係是：
- 基礎設施層提供了與具體技術相關的實現，例如資料庫訪問、消息隊列連接、緩存操作等。適配器層可以使用基礎設施層提供的功能來與外部系統進行交互。
- 適配器層通過適配器模式或類似的機制，將外部系統的介面和數據格式轉換為應用程式可以理解和處理的形式。適配器層還負責將應用程式的請求轉發給基礎設施層進行具體的操作。
- 基礎設施層和適配器層一起工作，使得應用程式能夠與外部系統進行集成，並且將與外部系統相關的技術細節與應用程式的業務邏輯和領域對象進行解耦。這樣可以實現應用程式的可擴展性、可維護性和可測試性。
對於一些無複雜邏輯的，也可以直接讓上游掉基礎設施層，不必一定通過Adapter層。
腳手架的落地實踐
以上主要是理論介紹，基於以上的說明，在實踐中，我搭建了兩套分層架構的java腳手架。具體來說分為單module版本和多module版本。對於微服務系統來說，如果你的每個服務業務複雜度不高，建議使用單module版本；如果你是個複雜業務場景的單體應用，建議採用多module版本。
1. 單module腳手架
--root
--application: 應用層是程式的入口，整合和組合domain提供的能力。
--rpc: JSF provider對外提供的介面實現
--controller: springMVC提供的controller
--listener: MQ消息監聽器
--task: 調度任務
--translate: 將內部的BO映射為外部的VO/Entity
--model: VO對象
--adapter: 適配器層
--rpc: JSF consumer，外部服務
--mq: 消息隊列sender模塊
--translate: 將外部數據結構映射為內部的DTO/BO
--domain: 領域層
--service: 領域服務可以按照自己情況靈活設計
--facotry: 工廠
--event/command: 事件驅動
--model: 對象和實體
--translate: 對象實體映射轉換
--infrastructure:
--repository: 持久化層，包括db模型，sql讀寫等
--cache: Redis緩存讀寫
--producer: MQ消息生成，即發送MQ消息。
--config: 配置信息，例如ducc配置、資料庫、緩存配置等
--translate: 將存儲層的數據結構PO映射為內部的BO
--utils: 工具集合
--common: 公共層
--exception: 主要分為業務異常和系統異常。系統異常需要研發處理。業務異常需要具備監控能力。
--utils: 工具類
--enums: 枚舉類
--common: 全局公共常量池
--worker: 非同步服務
--client: JSF SDK
maven私服拉取腳本如下：
單module版本maven私服拉取腳本如下：
mvn archetype:generate \
-DarchetypeGroupId=com.jd.magnus \
-DarchetypeArtifactId=magnus-single-archetype \
-DarchetypeVersion=1.0.0-SNAPSHOT \
-DinteractiveMode=false \
-DarchetypeCatalog=remote \
-Dversion=1.0.0-SNAPSHOT \
-DgroupId=com.jdl.sps \
-DartifactId=bff-single-demo1
2. 多module腳手架
此處有一個建議，在多module版本下，因為是複雜單體應用，所以建議內部進行拆包處理。每層內也可以基於不同領域場景也可以進行拆包操作，每個場景下層級結構是一樣的。如下圖舉例,其中app層中分別有兩個業務場景，包括商品和訂單：
多module版本的maven私服拉取腳本如下：
mvn archetype:generate \
-DarchetypeGroupId=com.jd.magnus \
-DarchetypeArtifactId=magnus-multi-ddd-archetype \
-DarchetypeVersion=1.0.0-SNAPSHOT \
-DinteractiveMode=false \
-DarchetypeCatalog=remote \
-Dversion=1.0.0-SNAPSHOT \
-DgroupId=com.jdl.sps \
-DartifactId=bff-demo1
小結
本框架是結合了DDD思想和六邊形架構思想,但腳手架不會限制大家能力和發揮。
如果你精通DDD，你可以在domain層採用標準的充血模型和子域拆分模式編寫你的代碼； 如果你精通MVC，該框架也可以簡化為大家熟悉的MVC開發模式。對於model的處理，也可靈活應對，在不影響整體代碼架構的情況下，允許不過度設計及對象多度封裝，鼓勵敏捷迭代和定期重構。
但有一個核心思想需要謹記：
我們儘量保證我們的代碼開發符合開閉原則，能夠通過增加類和方法的方式實現新功能迭代，儘量就要避免頻繁修改某個方法或者某個類，包與包之間要保證高內聚，低耦合。因為DDD思想的核心就是子域的拆分和對設計模式的合理運用。
作者：京東物流 趙勇萍
來源：京東雲開發者社區 自猿其說 Tech 轉載請註明來源
