【轉】一個微服務+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思考與設計的限制,本例僅供參考。

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章