一個微服務+DDD(領域驅動設計)的代碼結構示例

前有幸拜讀過諸多大神關於DDD的實現落地等文章，學習較多，受益匪淺，在此推薦 : 

https://www.cnblogs.com/hafiz/p/9388334.html
https://blog.csdn.net/k6T9Q8XKs6iIkZPPIFq/article/details/78909897
https://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html
https://blog.csdn.net/bluishglc/article/details/6681253

下面參考了DDD官方的結構，總結了前輩們的相關經驗，再根據自身對微服務和DDD學習和理解，做了一個用SpringCloud搭建的最基本的結構例子。個人才疏學淺，如有雷同或是不當之處，望各位大佬見諒和幫忙指正。

首先引經據典 , 參考官方架構草圖，DDD總體結構分為四層  :  Infrastructure(基礎實施層)，Domain(領域層)，Application(應用層)，Interfaces(表示層，也叫用戶界面層或是接口層)，各個層面的作用下面介紹。

　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　

對於DDD的設計而言，最重要的是如何去划分領域，划分好邊界。在代碼設計上，之前有看到過大佬用模塊(Modules)來進行上下文界定和划分。如圖下 : 

 

而對於微服務而言，就非常適合從業務上去划分以上的各個Modules，划分好各個業務板塊。

微服務 + DDD，個人覺得應該是首先是從微服務的角度(如何划分微服務)考慮去划分大的業務模塊，每一個微服務都應該是一個可以單獨部署，各司其職的模塊；

而在微服務實際開發中，結合DDD的思想去划分所有屬於自己的領域。

如圖示例，對於我這個Project而言，是模塊已經划分好的微服務應用，代碼設計上就分為  Infrastructure，Domain，Application，Interfaces : 

　　　　　　　　　　　　

 

Infrastructure 層 :  基礎實施層，向其他層提供通用的技術能力(比如工具類,第三方庫類支持,常用基本配置,數據訪問底層實現)

 

 　　　　　 

 

Domain層 : 主要負責表達業務概念,業務狀態信息和業務規則；是整個系統的核心層,幾乎全部的業務邏輯會在該層實現。

 

 　　　　　　

 

Application層 :  相對於領域層,應用層是很薄的一層,應用層定義了軟件要完成的任務,要盡量簡單。

　　注 : 這里圖里面所說的對內對外，對程序而言，事實上是從展現層調用應用層，應用層調用領域層，領域層或調用基礎實施層。

 

　　　　

 

 Interfaces層 : 負責向用戶顯示信息和解釋用戶命令，請求應用層以獲取用戶所需要展現的數據(比如獲取首頁的商品數據)

 

　　　

 

以上，就是個人 對 微服務+DDD的代碼結構示例，完整代碼詳見 https://github.com/EalenXie/springcloud-microservice-ddd

無論我們代碼結構如何規划，也並非一成不變，應該從實際出發，去思考划分結構的意義。此例子是對於微服務+DDD反應到實際開發，代碼的結構設計上的一種初步的思考與探索,一個樣板工程，不應該成為我們對實際DDD思考與設計的限制，本例僅供參考。

感謝各位提出意見和支持。

 

　　(我個人對微服務的理解)Tips : 

　　微服務架構設計，一個微服務應該就是一個可單獨部署，可運行的應用，也就是微服務最小的運行單元。

　　微服務本身內部高度內聚，微服務與微服務之間低耦合。

　　首先對於應用划分上，就應該想清楚每個微服務的職責，每個微服務服務內部建立起自己的依賴，完成自己的職責和業務。

　　微服務與微服務之間交互通過HTTP或RPC接口調用，降低微服務之間代碼實現和業務的耦合。

　　微服務的實現不應該受限某程序語言(或Java，或Go，或Python)，不應該受限於某框架(或SpringCloud，或Dubbo，或各種RPC框架等等)。

　　我的代碼結構是對於一個微服務本身(即應用)划分的，領域是對於微服務內部本身而言的，即這個微服務涉及哪些領域。

　　首先從大的方向去划分每一個微服務，然后再從每一個微服務確定所包含的領域，領域的邊界，等等。

　　比如划分了一個 認證授權服務，那么 領域可能有 用戶，權限；實體可能有角色，資源等等。領域行為有授權登錄，用戶退出，授權等等。

　　不要被框架和結構本身所限制！