# 背景 名詞解釋  如果你的團隊目前正是構建微服務架構風格的軟體系統，問自己兩個問題？  # 軟體架構演進 軟體架構大致經歷了從單機架構，集中式架構，分散式微服架構，程式的層次圖如下所示。  ## 單機架構 特點如下： 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軟體程式設計知識和程式設計師發展職業之路，歡迎關注，我整理了這些年程式設計學習的各種資源，關注公眾號‘李福春持續輸出’，傳送'學習資料'分享給你！