圖片

我們先來分析一下軟件架構模式演進的三個階段。

第一階段是單機架構：采用面向過程的設計方法，系統包括客戶端 UI 層和數據庫兩層，采用 C/S 架構模式，整個系統圍繞數據庫驅動設計和開發，并且總是從設計數據庫和字段開始。

第二階段是集中式架構：采用面向對象的設計方法，系統包括業務接入層、業務邏輯層和數據庫層，采用經典的三層架構，也有部分應用采用傳統的 SOA 架構。這種架構容易使系統變得臃腫，可擴展性和彈性伸縮性差。

第三階段是分布式微服務架構：隨著微服務架構理念的提出，集中式架構正向分布式微服務架構演進。微服務架構可以很好地實現應用之間的解耦，解決單體應用擴展性和彈性伸縮能力不足的問題。

我們知道，在單機和集中式架構時代，系統分析、設計和開發往往是獨立、分階段割裂進行的。

比如，在系統建設過程中，我們經常會看到這樣的情形：A 負責提出需求，B 負責需求分析，C 負責系統設計，D 負責代碼實現，這樣的流程很長，經手的人也很多，很容易導致信息丟失。最后，就很容易導致需求、設計與代碼實現的不一致，往往到了軟件上線后，我們才發現很多功能并不是自己想要的，或者做出來的功能跟自己提出的需求偏差太大。

而且在單機和集中式架構這兩種模式下，軟件無法快速響應需求和業務的迅速變化，最終錯失發展良機。此時，分布式微服務的出現就有點恰逢其時的意思了。

微服務設計和拆分的困境

那進入微服務架構時代以后，微服務確實也解決了原來采用集中式架構的單體應用的很多問題，比如擴展性、彈性伸縮能力、小規模團隊的敏捷開發等等。

但在看到這些好處的同時，微服務實踐過程中也產生了不少的爭論和疑惑：微服務的粒度應該多大呀？微服務到底應該如何拆分和設計呢？微服務的邊界應該在哪里？

可以說，很久以來都沒有一套系統的理論和方法可以指導微服務的拆分，包括微服務架構模式的提出者 Martin Fowler 在提出微服務架構的時候，也沒有告訴我們究竟應該如何拆分微服務。

于是，在這段較長的時間里，就有不少人對微服務的理解產生了一些曲解。有人認為：“微服務很簡單，不過就是把原來一個單體包拆分為多個部署包，或者將原來的單體應用架構替換為一套支持微服務架構的技術框架，就算是微服務了。” 還有人說：“微服務嘛，就是要微要小，拆得越小效果越好。”

但我想，這兩年，你在技術圈中一定聽說過一些項目因為前期微服務拆分過度，導致項目復雜度過高，無法上線和運維。

綜合來看，我認為微服務拆分困境產生的根本原因就是不知道業務或者微服務的邊界到底在什么地方。換句話說，確定了業務邊界和應用邊界，這個困境也就迎刃而解了。

那如何確定，是否有相關理論或知識體系支持呢？在回答這些問題之前，我們先來了解一下領域驅動設計與微服務的前世今生。

2004 年埃里克·埃文斯（Eric Evans）發表了《領域驅動設計》（Domain-Driven Design –Tackling Complexity in the Heart of Software）這本書，從此領域驅動設計（Domain Driven Design，簡稱 DDD）誕生。DDD 核心思想是通過領域驅動設計方法定義領域模型，從而確定業務和應用邊界，保證業務模型與代碼模型的一致性。

但 DDD 提出后在軟件開發領域一直都是“雷聲大，雨點小”！直到 Martin Fowler 提出微服務架構，DDD 才真正迎來了自己的時代。有些熟悉 DDD 設計方法的軟件工程師在進行微服務設計時，發現可以利用 DDD 設計方法來建立領域模型，劃分領域邊界，再根據這些領域邊界從業務視角來劃分微服務邊界。而按照 DDD 方法設計出的微服務的業務和應用邊界都非常合理，可以很好地實現微服務內部和外部的“高內聚、低耦合”。于是越來越多的人開始把 DDD 作為微服務設計的指導思想。

現在，很多大型互聯網企業已經將 DDD 設計方法作為微服務的主流設計方法了。DDD 也從過去“雷聲大，雨點小”，開始真正火爆起來。

為什么 DDD 適合微服務？

“眾里尋他千百度。驀然回首，那人卻在燈火闌珊處。”在經歷了多年的迷茫和爭論后，微服務終于尋到了他的心上人。

那 DDD 到底是何方神圣，擁有什么神器呢？

戰略設計主要從業務視角出發，建立業務領域模型，劃分領域邊界，建立通用語言的限界上下文，限界上下文可以作為微服務設計的參考邊界。

戰術設計則從技術視角出發，側重于領域模型的技術實現，完成軟件開發和落地，包括：聚合根、實體、值對象、領域服務、應用服務和資源庫等代碼邏輯的設計和實現。

我們不妨來看看 DDD 是如何進行戰略設計的。

DDD 戰略設計會建立領域模型，領域模型可以用于指導微服務的設計和拆分。事件風暴是建立領域模型的主要方法，它是一個從發散到收斂的過程。它通常采用用例分析、場景分析和用戶旅程分析，盡可能全面不遺漏地分解業務領域，并梳理領域對象之間的關系，這是一個發散的過程。事件風暴過程會產生很多的實體、命令、事件等領域對象，我們將這些領域對象從不同的維度進行聚類，形成如聚合、限界上下文等邊界，建立領域模型，這就是一個收斂的過程。

圖片

我們可以用三步來劃定領域模型和微服務的邊界。

第一步：在事件風暴中梳理業務過程中的用戶操作、事件以及外部依賴關系等，根據這些要素梳理出領域實體等領域對象。

第二步：根據領域實體之間的業務關聯性，將業務緊密相關的實體進行組合形成聚合，同時確定聚合中的聚合根、值對象和實體。在這個圖里，聚合之間的邊界是第一層邊界，它們在同一個微服務實例中運行，這個邊界是邏輯邊界，所以用虛線表示。

第三步：根據業務及語義邊界等因素，將一個或者多個聚合劃定在一個限界上下文內，形成領域模型。在這個圖里，限界上下文之間的邊界是第二層邊界，這一層邊界可能就是未來微服務的邊界，不同限界上下文內的領域邏輯被隔離在不同的微服務實例中運行，物理上相互隔離，所以是物理邊界，邊界之間用實線來表示。

有了這兩層邊界，微服務的設計就不是什么難事了。

在戰略設計中我們建立了領域模型，劃定了業務領域的邊界，建立了通用語言和限界上下文，確定了領域模型中各個領域對象的關系。到這兒，業務端領域模型的設計工作基本就完成了，這個過程同時也基本確定了應用端的微服務邊界。

在從業務模型向微服務落地的過程中，也就是從戰略設計向戰術設計的實施過程中，我們會將領域模型中的領域對象與代碼模型中的代碼對象建立映射關系，將業務架構和系統架構進行綁定。當我們去響應業務變化調整業務架構和領域模型時，系統架構也會同時發生調整，并同步建立新的映射關系。

DDD 與微服務的關系

有了上面的講解，現在我們不妨再次總結下 DDD 與微服務的關系。

DDD 是一種架構設計方法，微服務是一種架構風格，兩者從本質上都是為了追求高響應力，而從業務視角去分離應用系統建設復雜度的手段。兩者都強調從業務出發，其核心要義是強調根據業務發展，合理劃分領域邊界，持續調整現有架構，優化現有代碼，以保持架構和代碼的生命力，也就是我們常說的演進式架構。

DDD 主要關注：從業務領域視角劃分領域邊界，構建通用語言進行高效溝通，通過業務抽象，建立領域模型，維持業務和代碼的邏輯一致性。

微服務主要關注：運行時的進程間通信、容錯和故障隔離，實現去中心化數據管理和去中心化服務治理，關注微服務的獨立開發、測試、構建和部署。

總結

DDD 是一套完整而系統的設計方法，它能帶給你從戰略設計到戰術設計的標準設計過程，使得你的設計思路能夠更加清晰，設計過程更加規范。

DDD 善于處理與領域相關的擁有高復雜度業務的產品開發，通過它可以建立一個核心而穩定的領域模型，有利于領域知識的傳遞與傳承。

DDD 強調團隊與領域專家的合作，能夠幫助你的團隊建立一個溝通良好的氛圍，構建一致的架構體系。

DDD 的設計思想、原則與模式有助于提高你的架構設計能力。無論是在新項目中設計微服務，還是將系統從單體架構演進到微服務，都可以遵循 DDD 的架構原則。

DDD 不僅適用于微服務，也適用于傳統的單體應用。