為什麼在做微服務設計的時候需要DDD？

隨著對充血模型的領域認知的加深，我越加感覺到ddd的重要性。於是網上一頓海找，並做了學習筆記。

ddd內容繁多，個人淺見，它不同於傳統貧血的最核心的一點就是把原先傳統的貧血模型裡的業務邏輯層拎出來，融入到domain層，這樣面對複雜業務的規模化變更，我們只需要專注於domain即可。

回到主題，我們要了解的是微服務和ddd到底有什麼關係呢？

因為在網際網路時代，軟體所面臨的問題域比以往要複雜得多，這種複雜性**於不斷擴充套件的問題域自身，也**於創新變化，以及這種規模性增長所帶來的挑戰。

然而乙個人乙個團隊，他對複雜的事物的認知是有極限的，面對這種複雜問題唯一的方法就是分而治之。分主要考慮的是如何去分；治意味著分出來的每乙個部分要能夠獨立的執行，能夠互相的協作，完成整體的目標，能夠一來應對外部變化所帶來的衝擊。

微服務架構在分和治兩個方面都給出了很好的理論指導和最佳實踐，那微服務是不是解決複雜問題的銀彈呢？其實不然，很多團隊在應用了微服務架構來構建他們的系統以後，發現並沒有完全解決這種複雜性問題，甚至還帶來了一些其他的問題。比如:

從業務層面來看，微服務架構沒有避免這種散彈式的修改。甚至反而加重了他，這是為什麼呢？乙個重要的原因是微服務架構在分的這個緯度考慮的並不全面。

當我們去做分的這種工作的時候，具體拆分詳見我的另外一篇文章《微服務的拆分姿勢》，需要考慮哪些維度呢？我覺得我們至少要考慮三個維度：

微服務對第2個給出了很好的指導，對第3個也給出了一些建議。但是，對第1個功能緯度只給出來非常有限的指導，就是為什麼隨著微服務的流行，領域驅動設計(ddd)又被重新重視起來的原因。

ddd彌補了微服務在功能劃分方面沒有給出很好指導的缺陷。所以他們在面對複雜問題和構建系統時候是一種互補的關係，在系統拆分的時候可以很好的協作。

只是他們看待系統拆分這個角度是不同的。微服務當中的服務所關注的範圍正是ddd所推崇的六邊形架構中的領域層。

接下來結合ddd和微服務來拆分乙個複雜系統。

我們稱企業的業務範圍和在這個範圍裡進行的活動為領域，和軟體系統無關。領域會分成多個子域，比如我們乙個電商系統，會有：

在不同的子域裡，不同的概念有不同的含義。所以我們在進行領域建模的時候，必須要有乙個明確的領域邊界，也就是ddd裡稱做的限界上下文，它是系統內部的乙個架構邊界，決定了這個系統架構。

架構簡潔之道這本書裡邊就說過：『系統架構是由系統的內部架構邊界以及邊界之間的依賴關係所決定的，與系統中各個元件之間的通訊和呼叫的方式是無關的』。我們常說的微服務的服務呼叫本身只是一種比函式呼叫方式成本稍高的，分割應用程式行為的一種形式，系統架構無關。

所以，複雜系統劃分的第一重要的是要劃分內部的架構邊界，即劃分清楚這個上下文，以及明確他們之間的關係，這對應於我們之前說的功能的維度。這正是ddd用武之處。其次我們才考慮基於非功能的維度如何劃分，這是微服務能夠發揮其優勢的地方。

舉個例子，我們把系統分成abc三個個上下文，三個上下文的**可以在乙個部署單元裡執行，通過程序內呼叫來完成操作，這就是典型的單體架構；

也可以各自在乙個獨立的部署單元裡執行，通過遠端呼叫來完成操作，這就是現在流行的微服務架構。

我們更多的是兩種架構模式的乙個混合，比如a和b一起是乙個部署單元，c是另外乙個獨立的部署單元，這種情況往往是因為c非常重要，他併發的訪問量非常大，或者它的需求變更比較頻繁。將c拆分出來的有以下幾個好處:

那為什麼不把a和b都拆成乙個獨立的部署單元？

在單體架構中，保持架構邏輯邊界不被突破是有一定難度。如果邏輯邊界不清晰，在需要伺服器拆分的時候，就未必能拆得出來了。另外沒有人一下子就可以把邏輯邊界定義正確，即使這個上下文定義的不太正確，在ddd聚合根這個概念可以保障我們能夠演進出更適合的上下文。

ddd界限上下文內部通過實體和值物件來對領域概念進行建模，一組實體和值子物件歸屬於乙個聚合根。那按ddd要求

有了聚合根，基於這些約束，未來可以根據需要把聚合根公升級為上下文，甚至拆分成微服務都是比較容易的。

另外想要知道如何合理的拆分微服務，可以參考我的另外一篇文章《微服務劃分的姿勢》，今天就給你介紹到這兒，希望對你有所啟發。