【實踐篇】DDD 腳手架及編碼規範

一、背景介紹

我們團隊一直在持續推進業務系統的體系化治理工作，在這個過程中我們沉澱了自己的 DDD 腳手架項目。腳手架項目是體系化治理過程中比較重要的一環，它的作用有兩點：

  1. 可以對新建的項目進行統一的規範

  2. 對於指導老項目進行 DDD 的改造提供指導

本文主要是梳理和總結了 DDD 腳手架使用中的編碼規範以及遇到的問題。

二、腳手架的理論基礎

DDD 相關的應用架構有很多種，比如四層架構，洋蔥架構，六邊形架構，整潔架構等。這些應用架構都有各自的特點和不同。但是他們的總體思想都是相似的，主要是通過分層來實現功能和關注點的隔離。達到的目標是領域層不依賴任何其他外部實現，這樣就能保證核心業務邏輯的乾淨和穩定。

左圖是整潔架構的示意圖，左圖爲分層，右圖表示各個分層的變化頻率和抽象層級。整潔架構主要分爲 4 層：

  1. Frameworks&Drivers 層：這一層表示系統依賴的外部系統，比如數據庫、緩存、前端頁面等。這一層是變化頻率最高的，也是需要和我們的核心業務邏輯做隔離的。

  2. Interface Adapters 層：這一層是一個適配層，主要負責外部系統和內部業務系統的適配，這一層的主要作用就是外部系統和內部系統的適配和協議轉換。

  3. Application Business Rules: 應用業務規則層，可以理解爲用例層，這一層表示整個應用可以提供哪些用例級別的功能和服務。這一層也是對第 4 層中的核心業務規則的編排層。

  4. Enterprise Business Rules: 這一層就是最爲核心的業務邏輯層，這一層不包含任何和技術相關的內容，只包含業務邏輯。

三、腳手架介紹及應用

使用命令如下：

mvn archetype:generate     
-DarchetypeGroupId=com.jd.jr.cf     
-DarchetypeArtifactId=ddd-archetype     
-DarchetypeCatalog=local     
-DarchetypeVersion=0.0.1-SNAPSHOT     
-DinteractiveMode=false     
-DgroupId=com.jd.demo.test        //從這一行開始需要根據項目名稱修改 
-DartifactId=demo-test     
-Dversion=1.0.0     
-Dpackage=com.jd.demo.test     
-DappName=demo-test  -s D:/git/settings.xml      // 本地 git配置文件

生成完的項目結構如下：

|--- adapter                     -- 適配器層 應用與外部應用交互適配
|      |--- controller           -- 控制器層，API中的接口的實現
|      |       |--- assembler    -- 裝配器，DTO和領域模型的轉換
|      |       |--- impl         -- 協議層中接口的實現
|      |--- repository           -- 倉儲層
|      |       |--- assembler    -- 裝配器，PO和領域模型的轉換
|      |       |--- impl         -- 領域層中倉儲接口的實現
|      |--- rpc                  -- RPC層,Domain層中port中依賴的外部的接口實現，調用遠程RPC接口
|      |--- task                 -- 任務，主要是調度任務的適配器
|--- api                         -- 應用協議層 應用對外暴露的api接口
|--- boot                        -- 啓動層 應用框架、驅動等
|      |--- aop                  -- 切面
|      |--- config               -- 配置
|      |--- Application          -- 啓動類
|--- app                         -- 應用層
|      |--- cases                -- 應用服務
|--- domain                      -- 領域層
|      |--- model                -- 領域對象
|      |       |--- aggregate    -- 聚合
|      |       |--- entities     -- 實休
|      |       |--- vo           -- 值對象
|      |--- service              -- 域服務
|      |--- factory              -- 工廠，針對一些複雜的Object可以通過工廠來構建
|      |--- port                 -- 端口，即接口
|      |--- event                -- 領域事件
|      |--- exception            -- 異常封裝
|      |--- ability              -- 領域能力
|      |--- extension            -- 擴展點
|      |       |--- impl        -- 擴展點實現
|--- query                       -- 查詢層，封裝讀服務
|      |--- model                -- 查詢模型
|      |--- service              -- 查詢服務

整體的分層架構圖如下：

四、腳手架編碼規範

1、Api 模塊編碼規範：

Api 模塊是專門用於定義對外接口的模塊，所以這個模塊中只包含接口定義，出入參定義，儘量不依賴其他包。

2、Adapter/Controller 模塊編碼規範：

3、App 模塊編碼規範：

4、Domain 層編碼規範：

5、Adapter/Repository 和 Rpc 模塊編碼規範：

五、常見問題及解決辦法

Q1、Api 模塊對外提供的 jar 包中是否要引用其他應用的 jar 包？

A1：有一些場景，A 應用的 Api 接口的入參需要引用其他應用的包中的類。比如 A 應用發出了一個事件，B 應用提供了一個接口來處理這個事件，那 B 應用是否要引用 A 應用的包中的事件定義類呢？理想情況，最好是 B 應用定義一個自己的類，這樣 B 應用就不會依賴 A 應用的包。

Q2、Api 包中是否能包含枚舉類的定義？

A2：最好不要在 Api 包中對外暴露內部的枚舉值定義。因爲枚舉值是需要在 Domain 模塊中定義和使用的，不適合通過 jar 包的形式暴露給外部。如果確實有需求要暴露給外部應用 (比如爲了讓接口調用方方便的知道入參中的值有哪些)，可以將枚舉類的定義放在同一的 common 包中。這樣 Domain 模塊和對外提供的 jar 包都可以引用 common 包。

Q3、數據存儲是否要使用統一版本號？

A3：對於新應用，最好是使用統一的版本號，這樣在更新數據庫的時候就可以統一使用版本號當做樂觀鎖。但是對於遺留系統而言，啓用版本號的成本比較高，因爲需要梳理所有對實體進行變更的點，要求所有的點都統一使用版本號。所以要根據情況來確定是否使用。

Q4、對於一些偏流程性的業務，頻繁的調用外部 rpc 接口。如果每個 rpc 接口都添加一個防腐層對象的話，會降低開發效率。是否可以不定義防腐層對象？

A4：最好是定義防腐層對象，短期可能降低一些開發效率，但是從長期和代碼標準話的角度看，還是值得的。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/FpFmb_lDYRryqeUv9Be8IA

猜你喜歡