技術文章 » 【實踐篇】DDD腳手架及編碼規範

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

2023-08-24 12:00:59

一、背景介紹

我們團隊一直在持續推進業務系統的體系化治理工作，在這個過程中我們沉澱了自己的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模組是專門用於定義對外介面的模組，所以這個模組中只包含介面定義，出入參定義，儘量不依賴其他包。
  • Api中的介面定義類以xxxxResource(或者xxxxService)結尾。這條規範完全是為了和老的應用保持一致。
  • Api介面的入參儘量不要使用Java中的原子型別(Primitive Type)， 需要將入參定義為單獨的類。 最好是繼承現有的BaseRequest類。
  • Api介面的出參統一使用泛型類對真實的返回型別進行包裝。
  • 出入參類都以DTO結尾。
  • 出入參中儘量不適用列舉值型別的成員變數。

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

  • 這一層中需要將出入參的DTO和業務層的VO/DO物件進行轉換。
  • 這一層不要包含任何的業務邏輯，只包含引數轉換和業務無關的校驗邏輯。
  • 介面返回值快取類的邏輯，可以放在這個模組中實現，因為這個動作不包含業務邏輯。

3、App模組編碼規範：

  • 這個模組中的類統一以Case結尾。
  • 這一層主要是對底層業務邏輯進行編排。可以直接呼叫Domain層的port定義。跨域的服務呼叫也可以放在這個模組中。
  • 這一層可以直接呼叫Domain模組中定義的Repository服務。
  • 事務處理：如果是跨多個聚合的業務邏輯需要放在一個事務中，需要在這一層開啟和提交事務。

4、Domain層編碼規範：

  • DomainService命名統一以Service為字尾。
  • Entity實體類的命名不用字尾。 值物件類的定義統一以VO結尾。
  • DomainService邏輯中可以呼叫Repository和Port中定義的介面。
  • DomainService可以操作多個聚合，實體和值物件。
  • Entity實體類可以有建構函式，builder，getters。 不要直接放開所有屬性的setters，防止業務程式碼隨意修改實體的屬性。
  • 編寫業務邏輯需要遵守原則：優先將業務邏輯放在Entity和VO中，然後才是放在聚合中，最後才放在DomainService中。
  • 依賴反轉原則：Domain層依賴的外部介面都要定義在Domain模組的port包中。Domain層只面向介面程式設計，不依賴介面實現類。

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

  • Repository實現類中需要將介面入參中的DO物件轉換為PO物件後再呼叫資料庫儲存。
  • Repository和聚合的關係是一對一的關係。一個Repository有唯一的對應的聚合。
  • 如果Repository中需要開始事務可以在Repository實現類中開啟事務。
  • Rpc層最好是對外部介面的出參和入參定義一個防腐層物件，命名統一以DTO結尾。

五、常見問題及解決辦法

**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：最好是定義防腐層物件，短期可能降低一些開發效率，但是從長期和程式碼標準話的角度看，還是值得的。

作者：京東科技 史紀軍

來源：京東雲開發者社群 轉載請註明來源