一篇帶你了解DDD四層微服務架構
一、微服務搭建思路
大家看到的這張架構圖并不是空穴來潮，它是通過不斷演變出來的，我們要從DDD四層架構、微服務架構兩個維度去融合理解。
這里的DDD四層架構適用于單個服務的工程架構（如圖中的左下部分），就是單體應用的DDD四層架構的包劃分方式。
而微服務架構，則是從整體去看，整合多個單體應用，它們之間通過應用SDK工程進行RPC通訊。
二、微服務架構下的應用SDK
這個工程比較好理解，類似于我們傳統(tǒng)的理解的RPC包，或者叫API包，在Maven工程里，一般定義為一個子Module，里面主要定義的是Feign接口（如service.XxxFeignService），DTO對象（contract.dto.XxxRequest/XxxResponse）等等，此外還可以對FeignService返回的數(shù)據(jù)進行清洗與簡單通用的封裝（如util.XxxUtil），也就是說它還能封裝簡單的業(yè)務邏輯。
但需要特別注意：應用SDK要往一個大尺度獨立的聚合工程的方向去搭建，它里面的頂層包要按內部業(yè)務系統(tǒng)的維度去隔離，并且它和業(yè)務系統(tǒng)不是一對一的關系。
為什么要這樣設計？我講個例子你就明白了。
我們公司的業(yè)務系統(tǒng)在頂層劃分為SaaS應用和PaaS應用，那么PaaS應用對應的應用SDK可以命名為PaaSSdk，在PaaSSdk工程里，包括了消息中心、ChatAI、應用市場等PaaS應用的外部接口封裝與簡單業(yè)務邏輯封裝。
這樣做的好處顯而易見——SaaS應用需要用到PaaS應用的接口時，只需要引入PaaSSdk即可，原則上這個內部Sdk與我們平時引入的外部Jar包沒什么區(qū)別，可能只是網(wǎng)關和鑒權體系不一樣罷了。
而且，簡單的業(yè)務系統(tǒng)就用一個module就好了，沒必要再拆分多個module，要知道，每引入多一個東西就有更多的不確定性。
所以你也就能理解，為什么這里的應用Sdk與業(yè)務系統(tǒng)不是一對一的關系，如果是一對一，業(yè)務系統(tǒng)勢必要引入大量的Jar包，這在維護成本上是個災難。試想一下，如果要用到阿里云OSS的Jar包時，你會引入大量POM嗎？
三、DDD四層架構下的業(yè)務工程
DDD建模與落地的這幾年，收獲了不少好評，也著實為業(yè)務成功做出了貢獻，優(yōu)化了大半年，如今終于可以跟大家正式見面了。
先談架構思想：
- 經典DDD四層架構：作為主要骨架，其他優(yōu)秀架構思想作指導
- 整潔架構思想：應用到DDD領域層與基礎設施層，接口與實現(xiàn)拆到不同層，把技術代碼與業(yè)務代碼分離
- 菱形架構思想：內部以領域層的領域模型為核心，向南北兩個方向發(fā)散
- D3boot基礎框架：作為基礎設施，提供基礎CRUD接口、BOM依賴等基礎封裝，應用在各層，簡化鏈接，是快速搭建應用SDK、業(yè)務系統(tǒng)的粘合劑
DDD四層架構說明：
- 接入層：對外提供的系統(tǒng)入口/接口，如放Controller類，并按端劃分（這里的client包寫移動端接口，admin包寫管理端接口，open包寫開放接口）
- 應用層：跨聚合的服務編排service.XxxAppService、跨聚合領域事件監(jiān)聽event.XxxListener，實體工廠factory.XxxFactory
- 領域層：定義核心業(yè)務規(guī)則，與具體技術無關，不依賴其他各層；服務內按領域聚合劃分，外部聚合external.xxx按限界上下文（微服務）劃分；model定義充血模型、值對象，repository定義倉庫接口，service定義聚合內的領域服務，event定義聚合內的領域事件監(jiān)聽器；領域契約contract包含：API層特殊出入?yún)to.XxxRequest/dto.XxxResponse、數(shù)據(jù)查詢參數(shù)param.XxxParam、領域事件event.XxxEvent
- 基礎設施層：具體技術相關的代碼/框架、倉庫層實現(xiàn)repository.impl.XxxRepositoryImpl，包括數(shù)據(jù)聚合實現(xiàn)（fill方法）；external放外部服務實現(xiàn)，做接口防腐
四、集成D3boot基礎框架
領導讓你搭個業(yè)務系統(tǒng)，如果什么都從零開始的話，項目周期就太長了。我們在搭建系統(tǒng)的過程中，如果有這么一個框架，能夠快速解決CRUD、工程結構劃分等等問題就好了。
D3boot基礎框架的出現(xiàn)，正是為了解決這個問題。一般SpringBoot只能集成Spring體系內的技術棧，但作為心態(tài)更開放的我們，不應把目光聚焦在Spring體系內，每家企業(yè)都應該有自己的基礎框架。
D3boot，意為DDD工程快速啟動，其中融入了DDD領域驅動的架構思想，并且能處處體現(xiàn)充血模型帶來的CRUD上的便利，還支持SaaS應用的搭建（租戶隔離）。D3boot框架旨在快速搭建SaaS業(yè)務系統(tǒng)，減少繁瑣的CRUD定義，減少不必要的xml代碼書寫。
充血模型的思想體現(xiàn)在對Model的繼承，即可實現(xiàn)你想要的CRUD；而通過領域工廠（Factory的build、convert、fill等方式），又可以利用貧血模型思想的優(yōu)勢，對復雜的對象進行構建、轉換、填充，彌補了充血模型的不足。
目前我已使用這套輕量級微服務基礎框架，在公司里的健康管理平臺、消息中臺、工單中臺、社交中臺、ChatAI等業(yè)務系統(tǒng)應用了起來，使用感受一個字：舒服。
而作為基礎框架，考慮的更多是不同框架集成的問題、功能邊界問題，接下來我給大家一一介紹。
以下是D3boot的結構：
1.base：基礎組件
可擴展的基礎組件，下面包括多個子模塊，包括：
base-core：基礎核心組件：
定義了基礎核心上下文（如SpringContext、ThreadContext、BaseContext）、核心契約（如R對象、Page對象、抽象領域事件、業(yè)務異常、統(tǒng)一狀態(tài)碼等）、核心工具類（如Bean轉換工具、Json轉換工具、業(yè)務斷言工具等）。
base-data：基礎數(shù)據(jù)組件：
定義了基礎模型（支持CRUD的充血模型）、基礎倉庫及MybatisPlus的倉庫實現(xiàn)、數(shù)據(jù)類型處理器等，支持通過@TenantId注解PO類租戶字段來隔離租戶數(shù)據(jù)等。用到數(shù)據(jù)庫的工程需要依賴此包。
base-mq：基礎MQ組件：
目前集成了Kafka消息隊列，可快速通過注解方式實現(xiàn)MQ消費。
base-kit：基礎工具箱：
工具類，底下按不同的能力又細分為緩存類、事件類、語言類、線程類、WEB類工具。
base-monitor：基礎監(jiān)控組件：
集成HealthCheck接口、啟動打印代碼版本功能、日志告警功能（能把log.error的日志告警到企微機器人/釘釘機器人）。
base-web：基礎WEB組件：
定義了CRUD控制器基類CRUDController、按端劃分的模型控制器接口ModelController、全局異常增強、全局R對象包裝、全局Feign異常降級、各類WEB攔截器、基礎接口認證功能等。WEB工程需要依賴此包。
2.base-bom：基礎依賴組件
Maven的BOM（Bill of Materials）機制是Maven項目中的一個重要概念，它用于管理項目的依賴關系和版本控制。BOM機制可以幫助開發(fā)人員快速構建和維護項目，并且可以確保項目的穩(wěn)定性和可靠性。
Spring有自己的bom文件，如spring-boot-dependencies，里面定義了構建SpringBoot工程所需要的依賴。
參考Spring的方式，我們把第三方的依賴統(tǒng)一在base-bom組件里進行管理，這樣一來，業(yè)務工程只需要引入對應的dependency即可（包括定義D3boot框架里的組件版本），不需要再在業(yè)務系統(tǒng)過多地指定用哪個版本，達到版本統(tǒng)一的效果。
3.base-contract-parent：業(yè)務Contract父工程組件
作為應用SDK工程的父POM，快速搭建應用SDK。
4.base-parent：業(yè)務父工程組件
作為業(yè)務工程的父POM，快速搭建業(yè)務系統(tǒng)。
5.ddd-demo：DDDDemo工程
基于D3boot框架搭建的DDD四層架構風格的業(yè)務工程，寫得比較粗糙，具體參考架構圖的實現(xiàn)為準。
五、寫在最后
我一直認為，基礎框架不能寫得太重，公司的公共組件不應放在基礎框架工程內實現(xiàn)，而是另外定制。在基礎框架的開發(fā)過程中，我不斷汲取前輩的優(yōu)秀代碼經驗，并融入自己的代碼特色，提煉高復用性代碼，并對中間件進行淺封裝。
此外，本著技術開放的心態(tài)，這套基礎框架決定走開源路線，大家可以下載Deploy到自己的私倉使用，基于自己公司的業(yè)務進一步定制自己的基礎組件。
Gitee源碼地址：https://gitee.com/jensvn/d3boot（例行賒Star）
D3boot基礎框架具體的使用方式見源碼的README.md文件，這里不再贅述。
