記得之前在規(guī)劃和設(shè)計微服務(wù)架構(gòu)的時候，張隊長給了我一個至今依然記憶深刻的提示：你的設(shè)計藍圖里為什么沒有看到DDD的影子呢？

隨著對充血模型的領(lǐng)域認知的加深，我越加感覺到DDD的重要性。于是網(wǎng)上一頓海找，并做了學習筆記。

DDD內(nèi)容繁多，個人淺見，它不同于傳統(tǒng)貧血的最核心的一點就是把原先傳統(tǒng)的貧血模型里的業(yè)務(wù)邏輯層拎出來，融入到Domain層，這樣面對復雜業(yè)務(wù)的規(guī)?；兏?，我們只需要專注于Domain即可。

回到主題，我們要了解的是微服務(wù)和DDD到底有什么關(guān)系呢？

因為在互聯(lián)網(wǎng)時代，軟件所面臨的問題域比以往要復雜得多，這種復雜性來源于不斷擴展的問題域自身，也來源于創(chuàng)新變化，以及這種規(guī)模性增長所帶來的挑戰(zhàn)。

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

微服務(wù)的缺陷

微服務(wù)架構(gòu)在分和治兩個方面都給出了很好的理論指導和最佳實踐，那微服務(wù)是不是解決復雜問題的銀彈呢？其實不然，很多團隊在應用了微服務(wù)架構(gòu)來構(gòu)建他們的系統(tǒng)以后，發(fā)現(xiàn)并沒有完全解決這種復雜性問題，甚至還帶來了一些其他的問題。比如:

• 服務(wù)并沒有解決復雜系統(tǒng)如何應對需求變化這個問題，甚至還加劇了這個問題。
• 當一個需求變化了，需要花大量的精力去識別這個變化影響到了哪些微服務(wù)，這些服務(wù)的多個團隊之間，需要通過無休止的扯皮去決定哪個服務(wù)多一些，哪些服務(wù)少改一些。
• 然后測試團隊還需要做昂貴的這種聯(lián)調(diào)測試
• 即便如此呢，開發(fā)團隊依然不放心，還要通過一系列的開關(guān)控制，小心翼翼的去做切流，去做灰度發(fā)布。

從業(yè)務(wù)層面來看，微服務(wù)架構(gòu)沒有避免這種散彈式的修改。甚至反而加重了他，這是為什么呢？一個重要的原因是微服務(wù)架構(gòu)在分的這個緯度考慮的并不全面。

DDD功用

當我們?nèi)プ龇值倪@種工作的時候，需要考慮哪些維度呢？我覺得我們至少要考慮三個維度：

• 功能緯度
• 質(zhì)量緯度，比如性能，可用性
• 工程緯度

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

DDD彌補了微服務(wù)在功能劃分方面沒有給出很好指導的缺陷。所以他們在面對復雜問題和構(gòu)建系統(tǒng)時候是一種互補的關(guān)系，在系統(tǒng)拆分的時候可以很好的協(xié)作。

只是他們看待系統(tǒng)拆分這個角度是不同的。微服務(wù)當中的服務(wù)所關(guān)注的范圍正是DDD所推崇的六邊形架構(gòu)中的領(lǐng)域?qū)印?/p>

拆分案例

接下來結(jié)合DDD和微服務(wù)來拆分一個復雜系統(tǒng)。

關(guān)于領(lǐng)域

我們稱企業(yè)的業(yè)務(wù)范圍和在這個范圍里進行的活動為領(lǐng)域，和軟件系統(tǒng)無關(guān)。領(lǐng)域會分成多個子域，比如我們一個電商系統(tǒng)，會有：

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

在不同的子域里，不同的概念有不同的含義。所以我們在進行領(lǐng)域建模的時候，必須要有一個明確的領(lǐng)域邊界，也就是DDD里稱做的限界上下文，它是系統(tǒng)內(nèi)部的一個架構(gòu)邊界，決定了這個系統(tǒng)架構(gòu)。

劃分系統(tǒng)內(nèi)部架構(gòu)邊界

架構(gòu)簡潔之道這本書里邊就說過：系統(tǒng)架構(gòu)是由系統(tǒng)的內(nèi)部架構(gòu)邊界以及邊界之間的依賴關(guān)系所決定的，與系統(tǒng)中各個組件之間的通信和調(diào)用的方式是無關(guān)的。我們常說的微服務(wù)的服務(wù)調(diào)用本身只是一種比函數(shù)調(diào)用方式成本稍高的，分割應用程序行為的一種形式，系統(tǒng)架構(gòu)無關(guān)。

所以，復雜系統(tǒng)劃分的第一重要的是要劃分內(nèi)部的架構(gòu)邊界，即劃分清楚這個上下文，以及明確他們之間的關(guān)系，這對應于我們之前說的功能的維度。這正是DDD用武之處。其次我們才考慮基于非功能的維度如何劃分，這是微服務(wù)能夠發(fā)揮其優(yōu)勢的地方。

舉個例子，我們把系統(tǒng)分成ABC三個個上下文，三個上下文的代碼可以在一個部署單元里運行，通過進程內(nèi)調(diào)用來完成操作，這就是典型的單體架構(gòu)；

也可以各自在一個獨立的部署單元里運行，通過遠程調(diào)用來完成操作，這就是現(xiàn)在流行的微服務(wù)架構(gòu)。

邊界清晰的好處

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

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

這四點正是服務(wù)架構(gòu)所關(guān)注的，它是基于非功能緯度的視角來看待拆分這件事情的，他關(guān)注的不是系統(tǒng)架構(gòu)的邏輯邊界，更多的關(guān)注的是應用程序行為的分隔。

那為什么不把A和B都拆成一個獨立的部署單元？

這會帶來更多的好處，也會帶來額外的成本，架構(gòu)應該是可以演進的，在業(yè)務(wù)發(fā)展的早期，應該關(guān)注系統(tǒng)架構(gòu)的邏輯邊界，保持邏輯邊界的清晰和關(guān)系的正確，隨著業(yè)務(wù)量的增加，逐步在做拆分，這是組合應用DDD和微服務(wù)架構(gòu)帶來的最大的好處。

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

DDD界限上下文內(nèi)部通過實體和值對象來對領(lǐng)域概念進行建模，一組實體和值子對象歸屬于一個聚合根。那按DDD要求

• 聚合根用來保證內(nèi)部實體規(guī)則的正確性和數(shù)據(jù)的一致性
• 外部對象只能通過ID來引用聚合根，不能引用聚合根內(nèi)部的實體
• 聚合根之間不能共享一個數(shù)據(jù)庫事務(wù)，它們之間的數(shù)據(jù)一致性需要通過最終的一致性來保障
• 有了聚合根，基于這些約束，未來可以根據(jù)需要把聚合根升級為上下文，甚至拆分成微服務(wù)都是比較容易的。