背景
名詞解釋
如果你的團隊目前正是構建微服務架構風格的軟體系統，問自己兩個問題？
軟體架構演進
軟體架構大致經歷了從單機架構，集中式架構，分散式微服架構，程式的層次圖如下所示。
單機架構
特點如下：
1， 程式導向的設計方法；
2， 結構為CS；
3，程式的層次分兩層，即UI層和資料庫層；
4， 設計的核心在資料庫和欄位。
集中式架構
特點如下：
1， 物件導向的設計方法；
2，程式層次為經典的3層架構，即業務接入層， 業務邏輯層，資料庫層；
3，部分企業也採用SOA架構風格；
4，集中式的架構缺點：擴充套件性，伸縮性差，系統容易變得臃腫；
分散式微服務架構
特點：
1， 基於微服務的理念：分而治之，模組高內聚（獨立團隊，獨立部署，獨立儲存，技術異構），模組之間通過RPC或者HTTP通訊，鬆耦合；
2，模組之間鬆耦合，解決了擴充套件性和伸縮性的問題；
架構對比
單體架構和集中式架構，系統分析， 系統設計，系統開發這3個階段是割裂的，即分屬3個不同的人或者小組或者崗位的人負責，這樣的後果是：
1，系統分析，設計，開發三個階段的資訊不一致，導致上線之後功能跟需求偏差非常大；
2，系統的開發無法快速響應需求和業務的變化，錯失發展的良機。
微服務的困局
微服務解決的問題
微服務解決了單體架構和集中式架構的問題：擴充套件性，彈性伸縮，敏捷開發快速響應業務變化；
但是微服務並非毫無缺陷。
微服務的挑戰
微服務的粒度應該多大？微服務應該怎麼拆分和設計？微服務的邊界在哪裡？
微服務架構的提出者martin flower 也沒有告訴我們該如何拆分微服務。
微服務拆分的困局：
失敗的例子：微服務就是把單體拆的足夠小能夠獨立部署的技術框架，然後由於拆分的太細，後期服務運維和上線。
問題的本質：** 業務或者微服務的邊界到底是什麼？**
破局之路：2004年DDD釋出，Domain-Driven Design –Tackling Complexity in the Heart of Software，跟蹤軟體的核心複雜度。
核心思想：通過領域驅動設計方法來定義領域模型，來確定業務和應用的邊界，最後保證業務模型和程式碼模型的一致性。
**
通過業界的大量實踐證明： 通過DDD的方法來設計領域模型，劃分領域邊界再根據領域邊界從業務的視角來劃分微服務的邊界，通過這些邊界設計出來的微服務都非常合理，可以實現服務的內部高內聚，外部低耦合。
**
**
所以很多的企業已經把DDD當做微服務設計的主流方法了。
DDD
定義
是一種處理高度複雜的領域設計思想：圍繞業務概念進行領域建模來控制業務的複雜性，並試圖分離技術實現的複雜性，解決軟體系統難以理解難以演進的複雜性問題；
不是架構，而是一種架構設計的方法論： 通過邊界劃分把複雜業務領域簡單化，幫助我們設計清晰的領域和應用邊界，容易實現架構的演進。
主要內容
分為戰略設計和戰術設計。
DDD帶了了什麼？
戰略設計
從業務視角出發，建立業務領域模型，劃分領域的邊界，建立通用語言的限界上下文。限界上下文就是微服務邊界的參考。
領域模型用來指導微服務的設計和拆分。
基礎元素：
領域模型，領域邊界，通用語言限界上下文；
方法：
劃定領域模型和微服務邊界的步驟：
戰術設計
技術視角出發，側重於領域模型的技術實現，完成軟體的開發和落地。
包含基礎元素：
聚合根、
實體、
值物件、
領域服務、
應用服務和
資源庫
等程式碼邏輯的設計和實現。
把領域模型中的領域物件跟程式碼模型中的物件對應，將業務架構和系統架構進行繫結。當我們調整業務架構和領域模型的時候，系統架構也會發生對映關係的調整；
微服務和DDD之間的關係
小結
主要回答了為什麼微服務的設計和邊界需要使用DDD這種方法論來操作。希望諸位的微服務設計高內聚低耦合，良好的適應業務的變化，具備非常好的擴充套件性，伸縮性。
原創不易，關注誠可貴，轉發價更高！轉載請註明出處，讓我們互通有無，共同進步，歡迎溝通交流。
我會持續分享Java軟體程式設計知識和程式設計師發展職業之路，歡迎關注，我整理了這些年程式設計學習的各種資源，關注公眾號‘李福春持續輸出’，傳送'學習資料'分享給你！
