背景
名詞解釋
如果你的團隊目前正是構建微服務架構風格的軟體系統，問自己兩個問題？
軟體架構演進
軟體架構大致經歷了從單機架構，集中式架構，分布式微服架構，程式的層次圖如下所示，
單機架構
特點如下：
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軟體編程知識和程式員發展職業之路，歡迎關注，我整理了這些年編程學習的各種資源，關注公眾號‘李福春持續輸出’，發送'學習資料'分享給你！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/177765.html
標籤：Java