我們團隊一直在持續推進業務系統的體系化治理工作，在這個過程中我們沉澱了自己的DDD腳手架項目。腳手架項目是體系化治理過程中比較重要的一環，它的作用有兩點：
-
-
本文主要是梳理和總結了DDD腳手架使用中的編碼規範以及遇到的問題。
DDD相關的應用架構有很多種，比如四層架構，洋葱架構，六邊形架構，整潔架構等。這些應用架構都有各自的特點和不同。但是他們的總體思想都是相似的，主要是通過分層來實現功能和關注點的隔離。達到的目標是領域層不依賴任何其他外部實現，這樣就能保證核心業務邏輯的乾淨和穩定。
左圖是整潔架構的示意圖，左圖為分層，右圖表示各個分層的變化頻率和抽象層級。整潔架構主要分為4層：
-
Frameworks&Drivers層：這一層表示系統依賴的外部系統，比如數據庫、緩存、前端頁面等。這一層是變化頻率最高的，也是需要和我們的核心業務邏輯做隔離的。
-
Interface Adapters層：這一層是一個適配層，主要負責外部系統和內部業務系統的適配，這一層的主要作用就是外部系統和內部系統的適配和協議轉換。
-
Application Business Rules: 應用業務規則層，可以理解為用例層，這一層表示整個應用可以提供哪些用例級別的功能和服務。這一層也是對第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 -- 查詢服務
整體的分層架構圖如下：
Api模塊是專門用於定義對外接口的模塊，所以這個模塊中只包含接口定義，出入參定義，儘量不依賴其他包。
-
Api中的接口定義類以xxxxResource(或者xxxxService)結尾。這條規範完全是為了和老的應用保持一致。
-
Api接口的入參儘量不要使用Java中的原子類型(Primitive Type)， 需要將入參定義為單獨的類。最好是繼承現有的BaseRequest類。
-
Api接口的出參統一使用泛型類對真實的返回類型進行包裝。
-
-
2、Adapter/Controller模塊編碼規範：
-
這一層中需要將出入參的DTO和業務層的VO/DO對象進行轉換。
-
這一層不要包含任何的業務邏輯，只包含參數轉換和業務無關的校驗邏輯。
-
接口返回值緩存類的邏輯，可以放在這個模塊中實現，因為這個動作不包含業務邏輯。
-
-
這一層主要是對底層業務邏輯進行編排。可以直接調用Domain層的port定義。跨域的服務調用也可以放在這個模塊中。
-
這一層可以直接調用Domain模塊中定義的Repository服務。
-
事務處理：如果是跨多個聚合的業務邏輯需要放在一個事務中，需要在這一層開啓和提交事務。
-
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應用的包。
A2：最好不要在Api包中對外暴露內部的枚舉值定義。因為枚舉值是需要在Domain模塊中定義和使用的，不適合通過jar包的形式暴露給外部。如果確實有需求要暴露給外部應用(比如為了讓接口調用方方便的知道入參中的值有哪些)，可以將枚舉類的定義放在同一的common包中。這樣Domain模塊和對外提供的jar包都可以引用common包。
A3：對於新應用，最好是使用統一的版本號，這樣在更新數據庫的時候就可以統一使用版本號當做樂觀鎖。但是對於遺留系統而言，啓用版本號的成本比較高，因為需要梳理所有對實體進行變更的點，要求所有的點都統一使用版本號。所以要根據情況來確定是否使用。
Q4、對於一些偏流程性的業務，頻繁的調用外部rpc接口。如果每個rpc接口都添加一個防腐層對象的話，會降低開發效率。是否可以不定義防腐層對象？
A4：最好是定義防腐層對象，短期可能降低一些開發效率，但是從長期和代碼標準話的角度看，還是值得的。
