一、微服務搭建思路

大家看到的這張架構圖并不是空穴來潮，它是通過不斷演變出來的，我們要從DDD四層架構、微服務架構兩個維度去融合理解。

這里的DDD四層架構適用于單個服務的工程架構（如圖中的左下部分），就是單體應用的DDD四層架構的包劃分方式。

而微服務架構，則是從整體去看，整合多個單體應用，它們之間通過應用SDK工程進行RPC通訊。

二、微服務架構下的應用SDK

這個工程比較好理解，類似于我們傳統的理解的RPC包，或者叫API包，在Maven工程里，一般定義為一個子Module，里面主要定義的是Feign接口（如service.XxxFeignService），DTO對象（contract.dto.XxxRequest/XxxResponse）等等，此外還可以對FeignService返回的數據進行清洗與簡單通用的封裝（如util.XxxUtil），也就是說它還能封裝簡單的業務邏輯。

但需要特別注意：應用SDK要往一個大尺度獨立的聚合工程的方向去搭建，它里面的頂層包要按內部業務系統的維度去隔離，并且它和業務系統不是一對一的關系。

為什么要這樣設計？我講個例子你就明白了。

我們公司的業務系統在頂層劃分為SaaS應用和PaaS應用，那么PaaS應用對應的應用SDK可以命名為PaaSSdk，在PaaSSdk工程里，包括了消息中心、ChatAI、應用市場等PaaS應用的外部接口封裝與簡單業務邏輯封裝。

這樣做的好處顯而易見——SaaS應用需要用到PaaS應用的接口時，只需要引入PaaSSdk即可，原則上這個內部Sdk與我們平時引入的外部Jar包沒什么區別，可能只是網關和鑒權體系不一樣罷了。

而且，簡單的業務系統就用一個module就好了，沒必要再拆分多個module，要知道，每引入多一個東西就有更多的不確定性。

所以你也就能理解，為什么這里的應用Sdk與業務系統不是一對一的關系，如果是一對一，業務系統勢必要引入大量的Jar包，這在維護成本上是個災難。試想一下，如果要用到阿里云OSS的Jar包時，你會引入大量POM嗎？

三、DDD四層架構下的業務工程

DDD建模與落地的這幾年，收獲了不少好評，也著實為業務成功做出了貢獻，優化了大半年，如今終于可以跟大家正式見面了。

先談架構思想：

• 經典DDD四層架構：作為主要骨架，其他優秀架構思想作指導
• 整潔架構思想：應用到DDD領域層與基礎設施層，接口與實現拆到不同層，把技術代碼與業務代碼分離
• 菱形架構思想：內部以領域層的領域模型為核心，向南北兩個方向發散
• D3boot基礎框架：作為基礎設施，提供基礎CRUD接口、BOM依賴等基礎封裝，應用在各層，簡化鏈接，是快速搭建應用SDK、業務系統的粘合劑

DDD四層架構說明：

• 接入層：對外提供的系統入口/接口，如放Controller類，并按端劃分（這里的client包寫移動端接口，admin包寫管理端接口，open包寫開放接口）
• 應用層：跨聚合的服務編排service.XxxAppService、跨聚合領域事件監聽event.XxxListener，實體工廠factory.XxxFactory
• 領域層：定義核心業務規則，與具體技術無關，不依賴其他各層；服務內按領域聚合劃分，外部聚合external.xxx按限界上下文（微服務）劃分；model定義充血模型、值對象，repository定義倉庫接口，service定義聚合內的領域服務，event定義聚合內的領域事件監聽器；領域契約contract包含：API層特殊出入參dto.XxxRequest/dto.XxxResponse、數據查詢參數param.XxxParam、領域事件event.XxxEvent
• 基礎設施層：具體技術相關的代碼/框架、倉庫層實現repository.impl.XxxRepositoryImpl，包括數據聚合實現（fill方法）；external放外部服務實現，做接口防腐

四、集成D3boot基礎框架

領導讓你搭個業務系統，如果什么都從零開始的話，項目周期就太長了。我們在搭建系統的過程中，如果有這么一個框架，能夠快速解決CRUD、工程結構劃分等等問題就好了。

D3boot基礎框架的出現，正是為了解決這個問題。一般SpringBoot只能集成Spring體系內的技術棧，但作為心態更開放的我們，不應把目光聚焦在Spring體系內，每家企業都應該有自己的基礎框架。

D3boot，意為DDD工程快速啟動，其中融入了DDD領域驅動的架構思想，并且能處處體現充血模型帶來的CRUD上的便利，還支持SaaS應用的搭建（租戶隔離）。D3boot框架旨在快速搭建SaaS業務系統，減少繁瑣的CRUD定義，減少不必要的xml代碼書寫。

充血模型的思想體現在對Model的繼承，即可實現你想要的CRUD；而通過領域工廠（Factory的build、convert、fill等方式），又可以利用貧血模型思想的優勢，對復雜的對象進行構建、轉換、填充，彌補了充血模型的不足。

目前我已使用這套輕量級微服務基礎框架，在公司里的健康管理平臺、消息中臺、工單中臺、社交中臺、ChatAI等業務系統應用了起來，使用感受一個字：舒服。

而作為基礎框架，考慮的更多是不同框架集成的問題、功能邊界問題，接下來我給大家一一介紹。

以下是D3boot的結構：

1.base：基礎組件

可擴展的基礎組件，下面包括多個子模塊，包括：

base-core：基礎核心組件：

定義了基礎核心上下文（如SpringContext、ThreadContext、BaseContext）、核心契約（如R對象、Page對象、抽象領域事件、業務異常、統一狀態碼等）、核心工具類（如Bean轉換工具、Json轉換工具、業務斷言工具等）。

base-data：基礎數據組件：

定義了基礎模型（支持CRUD的充血模型）、基礎倉庫及MybatisPlus的倉庫實現、數據類型處理器等，支持通過@TenantId注解PO類租戶字段來隔離租戶數據等。用到數據庫的工程需要依賴此包。

base-mq：基礎MQ組件：

目前集成了Kafka消息隊列，可快速通過注解方式實現MQ消費。

base-kit：基礎工具箱：

工具類，底下按不同的能力又細分為緩存類、事件類、語言類、線程類、WEB類工具。

base-monitor：基礎監控組件：

集成HealthCheck接口、啟動打印代碼版本功能、日志告警功能（能把log.error的日志告警到企微機器人/釘釘機器人）。

base-web：基礎WEB組件：

定義了CRUD控制器基類CRUDController、按端劃分的模型控制器接口ModelController、全局異常增強、全局R對象包裝、全局Feign異常降級、各類WEB攔截器、基礎接口認證功能等。WEB工程需要依賴此包。

2.base-bom：基礎依賴組件

Maven的BOM（Bill of Materials）機制是Maven項目中的一個重要概念，它用于管理項目的依賴關系和版本控制。BOM機制可以幫助開發人員快速構建和維護項目，并且可以確保項目的穩定性和可靠性。

Spring有自己的bom文件，如spring-boot-dependencies，里面定義了構建SpringBoot工程所需要的依賴。

參考Spring的方式，我們把第三方的依賴統一在base-bom組件里進行管理，這樣一來，業務工程只需要引入對應的dependency即可（包括定義D3boot框架里的組件版本），不需要再在業務系統過多地指定用哪個版本，達到版本統一的效果。

3.base-contract-parent：業務Contract父工程組件

作為應用SDK工程的父POM，快速搭建應用SDK。

4.base-parent：業務父工程組件

作為業務工程的父POM，快速搭建業務系統。

5.ddd-demo：DDDDemo工程

基于D3boot框架搭建的DDD四層架構風格的業務工程，寫得比較粗糙，具體參考架構圖的實現為準。

五、寫在最后

我一直認為，基礎框架不能寫得太重，公司的公共組件不應放在基礎框架工程內實現，而是另外定制。在基礎框架的開發過程中，我不斷汲取前輩的優秀代碼經驗，并融入自己的代碼特色，提煉高復用性代碼，并對中間件進行淺封裝。

此外，本著技術開放的心態，這套基礎框架決定走開源路線，大家可以下載Deploy到自己的私倉使用，基于自己公司的業務進一步定制自己的基礎組件。

Gitee源碼地址：https://gitee.com/jensvn/d3boot（例行賒Star）

D3boot基礎框架具體的使用方式見源碼的README.md文件，這里不再贅述。