爲何在作微服務設計的時候須要DDD？

記得以前在規劃和設計微服務架構的時候，張隊長給了我一個至今依然記憶深入的提示：『你的設計藍圖裏爲何沒有看到DDD的影子呢？』

隨着對充血模型的領域認知的加深，我越加感受到DDD的重要性。可是DDD內容繁多，是否是要深刻去了解呢，我以爲沒必要入坑太深，我的淺見，它最核心的一點就是針對貧血模型的不足而設計，把原先傳統的貧血模型裏的業務邏輯層拎出來，融入到Domain層，這樣面對複雜業務的規模化變動，咱們只須要專一於Domain便可。

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

　　由於在互聯網時代，軟件所面臨的問題域比以往要複雜得多，這種複雜性來源於不斷擴展的問題域自身，也來源於創新變化，以及這種規模性增加所帶來的挑戰。

　　然而一我的一個團隊，他對複雜的事物的認知是有極限的，面對這種複雜問題惟一的方法就是分而治之。分主要考慮的是如何去分；治意味着分出來的每個部分要可以獨立的運行，可以互相的協做，完成總體的目標，可以一來應對外部變化所帶來的衝擊。

微服務的缺陷

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

• 服務並沒有解決複雜系統如何應對需求變化這個問題，甚至還加重了這個問題。
• 當一個需求變化了，須要花大量的精力去識別這個變化影響到了哪些微服務，這些服務的多個團隊之間，須要經過無休止的扯皮去決定哪一個服務多一些，哪些服務少改一些。
• 而後測試團隊還須要作昂貴的這種聯調測試
• 即使如此呢，開發團隊依然不放心，還要經過一系列的開關控制，當心翼翼的去作切流，去作灰度發佈。

      從業務層面來看，微服務架構沒有避免這種散彈式的修改。甚至反而加劇了他，這是爲何呢？一個重要的緣由是微服務架構在分的這個緯度考慮的並不全面。

DDD功用

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

• 功能緯度
• 質量緯度，好比性能，可用性
• 工程緯度

      微服務對第2個給出了很好的指導，對第3個也給出了一些建議。可是，對第1個功能緯度只給出來很是有限的指導，就是爲何隨着微服務的流行，領域驅動設計(DDD)又被從新重視起來的緣由。

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

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

      

拆分案例

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

關於領域

      咱們稱企業的業務範圍和在這個範圍裏進行的活動爲領域，和軟件系統無關。領域會分紅多個子域，好比咱們一個電商系統，會有：

• 商品子域
• 訂單子域
• 庫存子域等等。

      在不一樣的子域裏，不一樣的概念有不一樣的含義。因此咱們在進行領域建模的時候，必需要有一個明確的領域邊界，也就是DDD裏稱作的限界上下文，它是系統內部的一個架構邊界，決定了這個系統架構。

劃分系統內部架構邊界

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

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

　　舉個例子，咱們把系統分紅ABC三個個上下文，三個上下文的代碼能夠在一個部署單元裏運行，經過進程內調用來完成操做，這就是典型的單體架構；

　　 

　　也能夠各自在一個獨立的部署單元裏運行，經過遠程調用來完成操做，這就是如今流行的微服務架構。

邊界清晰的好處

　　咱們更多的是兩種架構模式的一個混合，好比A和B一塊兒是一個部署單元，C是另一個獨立的部署單元，這種狀況每每是由於C很是重要，他併發的訪問量很是大，或者它的需求變動比較頻繁。將C拆分出來的有如下幾個好處:

• 資源傾斜
• 使用彈力設計模式：好比重試，熔斷，降級
• 使用特殊技術：好比Go語言
• 具有獨立代碼庫：有獨立團隊和運維人員，和A和B的運行期作到隔離不互相影響

　　這四點正是服務架構所關注的，它是基於非功能緯度的視角來看待拆分這件事情的，他關注的不是系統架構的邏輯邊界，更多的關注的是應用程序行爲的分隔。

　　那爲何不把A和B都拆成一個獨立的部署單元？

　　這會帶來更多的好處，也會帶來額外的成本，架構應該是能夠演進的，在業務發展的早期，應該關注系統架構的邏輯邊界，保持邏輯邊界的清晰和關係的正確，隨着業務量的增長，逐步在作拆分，這是組合應用DDD和微服務架構帶來的最大的好處。

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

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

• 聚合根用來保證內部實體規則的正確性和數據的一致性
• 外部對象只能經過ID來引用聚合根，不能引用聚合根內部的實體
• 聚合根之間不能共享一個數據庫事務，它們之間的數據一致性須要經過最終的一致性來保障

　　有了聚合根，基於這些約束，將來能夠根據須要把聚合根升級爲上下文，甚至拆分紅微服務都是比較容易的。

　　另外想要知道如何合理的拆分微服務，能夠參考個人另一篇文章《微服務劃分的姿式》，今天就給你介紹到這兒，但願對你有所啓發。