軟件架構(gòu)設(shè)計(jì)本身就是一個(gè)復(fù)雜的事情，但其實(shí)業(yè)界已有一個(gè)共識(shí)，那就是“通過組件化完成關(guān)注點(diǎn)的分離從而降低局部復(fù)雜度”。其實(shí)現(xiàn)在我們用的無(wú)論是容器、中間件、消息、數(shù)據(jù)庫(kù)等，在某種意義上都是組件化的產(chǎn)物。這樣的好處是在不同的系統(tǒng)里可以復(fù)用。在云原生興起的今天，以通用的、組件化的服務(wù)形式更容易為我們所用，所以說(shuō)現(xiàn)在如果還不享用云原生技術(shù)紅利，那你就會(huì)被時(shí)代拋棄。

云原生滿足非功能性質(zhì)量需求

云原生在技術(shù)上能夠最大程度的解決眾多非功能性質(zhì)量和技術(shù)需求（如上圖），那作為一個(gè)企業(yè)級(jí)應(yīng)用架構(gòu)，自然會(huì)把專注點(diǎn)轉(zhuǎn)移到業(yè)務(wù)應(yīng)用功能性設(shè)計(jì)本身上來(lái)?，F(xiàn)在來(lái)說(shuō)對(duì)于一個(gè)復(fù)雜業(yè)務(wù)架構(gòu)進(jìn)行設(shè)計(jì)，我們要想做到又快又好，無(wú)非是兩種情況：一是架構(gòu)師本身對(duì)業(yè)務(wù)理解很深、能力超強(qiáng)、爐火純青；二是原有的業(yè)務(wù)系統(tǒng)本身模型清晰，足夠的“高內(nèi)聚低耦合”，可以快速在其基礎(chǔ)之上分析業(yè)務(wù)變化形成新的業(yè)務(wù)架構(gòu)設(shè)計(jì)。我們應(yīng)該追求的是第二種情況，這也就意味著從一開始的企業(yè)級(jí)模型建設(shè)，就要對(duì)模型設(shè)計(jì)、業(yè)務(wù)流程仔細(xì)對(duì)待，只有做到基礎(chǔ)扎實(shí)，才能有后面的“快速迭代”。

我們?cè)倩氐郊軜?gòu)設(shè)計(jì)的本質(zhì)，即為什么我們要在代碼實(shí)現(xiàn)前做設(shè)計(jì)。設(shè)計(jì)首先是要解決問題的復(fù)雜度。于是有人做了一個(gè)架構(gòu)，交給了一個(gè)團(tuán)隊(duì)去實(shí)現(xiàn)，很快發(fā)現(xiàn)實(shí)現(xiàn)的架構(gòu)和設(shè)計(jì)完全是兩回事。當(dāng)然原因很明確——缺少了交流和溝通；其次是要建立團(tuán)隊(duì)協(xié)作溝通的共識(shí)。即使我們做好了一個(gè)團(tuán)隊(duì)都達(dá)成共識(shí)的架構(gòu)設(shè)計(jì)，大家都兢兢業(yè)業(yè)把設(shè)計(jì)變成了現(xiàn)實(shí)，一個(gè)長(zhǎng)期困擾軟件行業(yè)的問題出現(xiàn)了，需求總是在變化，無(wú)論預(yù)先設(shè)計(jì)如何“精確”，總是發(fā)現(xiàn)下一個(gè)坑就在不遠(yuǎn)處，結(jié)果往往是情況越來(lái)越糟糕，也就是我們常說(shuō)的架構(gòu)“腐化”了，最后大家不得不接受重寫。這些經(jīng)歷讓我們逐步明確了軟件架構(gòu)設(shè)計(jì)的實(shí)質(zhì)是通過核心問題的分離降低復(fù)雜度，并讓系統(tǒng)能夠更快地響應(yīng)外界業(yè)務(wù)的變化，并且使得系統(tǒng)能夠持續(xù)演進(jìn)。在遇到變化時(shí)不需要從頭開始，保證實(shí)現(xiàn)成本得到有效控制。

所以，我覺得從架構(gòu)設(shè)計(jì)角度，以下三點(diǎn)是最為關(guān)鍵的：

• 讓我們的模型、組件和業(yè)務(wù)劃分盡量靠近變化的本質(zhì)，比如對(duì)于一般電商系統(tǒng)來(lái)說(shuō)，就是用戶、商品、交易、支付等，這樣的劃分能夠讓我們將變化“隔離”在一定的范圍(業(yè)務(wù)模塊)內(nèi)，從而幫助我們有效減少改變點(diǎn)。

• 設(shè)計(jì)上，業(yè)務(wù)模型內(nèi)部是高內(nèi)聚，模型之間是低耦合，即各自完成的業(yè)務(wù)是相對(duì)獨(dú)立的，不會(huì)因?yàn)橐环降艟€而牽連另外一方，比如商品推薦功能掛掉了，但是交易和支付業(yè)務(wù)應(yīng)該繼續(xù)正常提供服務(wù)，可能提示用戶暫時(shí)無(wú)法提供推薦服務(wù)，或者干脆降級(jí)為兜底策略。

• 模型、組件在業(yè)務(wù)上盡可能是復(fù)用的，正是這樣的復(fù)用才成就了今天的互聯(lián)網(wǎng)級(jí)架構(gòu)，我們不會(huì)每做一個(gè)電商系統(tǒng)都從零做起。而被“復(fù)用”最多的業(yè)務(wù)模塊顯然會(huì)重點(diǎn)設(shè)計(jì)和運(yùn)營(yíng)，成為核心業(yè)務(wù)模塊。當(dāng)然架構(gòu)上這樣的電商系統(tǒng)必然也會(huì)比較健壯。

上面的三點(diǎn)毫無(wú)疑問都指向了業(yè)務(wù)，從業(yè)務(wù)出發(fā)、面向業(yè)務(wù)變化是我們現(xiàn)代架構(gòu)設(shè)計(jì)成功的關(guān)鍵，所以說(shuō)復(fù)雜業(yè)務(wù)架構(gòu)設(shè)計(jì)的核心實(shí)質(zhì)是保證面對(duì)業(yè)務(wù)變化時(shí)我們能夠有足夠快的響應(yīng)能力。

前面說(shuō)了業(yè)務(wù)軟件開發(fā)的常見?。簭囊粋€(gè)小的項(xiàng)目不斷開發(fā)演化變成一個(gè)大型業(yè)務(wù)系統(tǒng)，但隨著新需求的不斷增加，最終演變成了開發(fā)團(tuán)隊(duì)的噩夢(mèng)。而這些噩夢(mèng)大部分是源于軟件的概念完整性（“概念完整性”一詞來(lái)源于軟件工程的經(jīng)典著作《人月神話》）遭到了破壞。這些業(yè)務(wù)代碼可能是一代又一代的開發(fā)人員各行其道的堆疊起來(lái)的（我們又稱之為“屎山”），而這個(gè)過程中沒人有意識(shí)的去維護(hù)軟件的概念完整性。而 DDD 領(lǐng)域設(shè)計(jì)，特別是 DDD 提供的戰(zhàn)略建模層面的概念，是維護(hù)軟件概念完整性的良藥。

“技術(shù)服務(wù)于業(yè)務(wù)、業(yè)務(wù)驅(qū)動(dòng)技術(shù)”是目前大部分人的共識(shí)，尤其是對(duì)商業(yè)公司而言。而 DDD 領(lǐng)域設(shè)計(jì)主張?jiān)谲浖O(shè)計(jì)中把業(yè)務(wù)領(lǐng)域本身作為關(guān)注的焦點(diǎn)（換句話說(shuō)就是軟件開發(fā)人員要懂業(yè)務(wù)）非常符合這種思想；并且，DDD 提供了切實(shí)可行的面對(duì)復(fù)雜業(yè)務(wù)軟件設(shè)計(jì)的解決方法，這也是我非常提倡作為一個(gè)架構(gòu)師去深入學(xué)習(xí)和討論 DDD 領(lǐng)域設(shè)計(jì)的相關(guān)知識(shí)。

在戰(zhàn)略層面，DDD 非常強(qiáng)調(diào)對(duì)業(yè)務(wù)問題的分析和分解，通過識(shí)別核心問題來(lái)降低問題的復(fù)雜度。DDD 在戰(zhàn)略層面維護(hù)模型的概念完整性的方法，最重要的兩個(gè)概念就是界限上下文（Bounded Context）和防腐層（Anti-Corruption Layer）。

• 定義好界限上下文

關(guān)于界限上下文的定義，隨便一本講 DDD 的書上都會(huì)詳細(xì)講解，這里我只想分享一下自己的一些理解。這時(shí)，有人會(huì)問：界限上下文多大才能合適呢，劃分上下文有沒有可以遵循的規(guī)則呢？

劃分上下文的規(guī)則，無(wú)非就是放之四海而皆準(zhǔn)的“高內(nèi)聚、低耦合”，這么說(shuō)可能還是太虛。其實(shí)真正讓大家感到糾結(jié)的是，不知如何切分的那些東西之間所存在的關(guān)聯(lián)，有的甚至干脆都納入到一個(gè)上下文里。其實(shí)，我認(rèn)為與其關(guān)注上下文的“大小”，不如關(guān)注模型的“質(zhì)量”，關(guān)注概念的完整性是不是容易被破壞。我覺得，判斷大小是不是合適，要結(jié)合應(yīng)用開發(fā)團(tuán)隊(duì)的能力，看開發(fā)團(tuán)隊(duì)能在多大的一個(gè)范圍內(nèi)掌控軟件的概念完整性。只要是開發(fā)團(tuán)隊(duì)沒有問題，這個(gè)范圍就算再大也都是可以的。

如果開發(fā)團(tuán)隊(duì)的水平在業(yè)界屬于上游，那么維護(hù)上下文的范圍往往是很大的；一些公司開發(fā)團(tuán)隊(duì)的水平參差不齊，所以在項(xiàng)目的實(shí)施過程中，可能需要?jiǎng)澐窒鄬?duì)小的上下文，盡可能減少“屎山”的不斷堆積。 

• 做好防腐層

界限上下文需要時(shí)刻保護(hù)好自己所維護(hù)的邊界，以及邊界內(nèi)概念的完整性，這時(shí)需要將某個(gè)上下文的概念轉(zhuǎn)化為另一個(gè)上下文概念的地方就叫做“防腐層”。防腐層的實(shí)現(xiàn)有很多種，典型的比如作為適配器 Adaptor 來(lái)實(shí)現(xiàn)，另外廣義上講，Gateway 也是一個(gè)典型性的防腐層組件，當(dāng)然，防腐層的代碼和其他內(nèi)部業(yè)務(wù)模型之間要存在明顯的物理邊界（當(dāng)然不一定說(shuō)要把防腐層作為一個(gè)個(gè)獨(dú)立部署的進(jìn)程），至少我們可以考慮把防腐層作為一個(gè)獨(dú)立的類庫(kù)來(lái)進(jìn)行構(gòu)建和維護(hù)，阿里內(nèi)部的比如星環(huán)、其實(shí)就是這個(gè)思路。

一個(gè)典型的防腐層的設(shè)計(jì)

DDD 在戰(zhàn)術(shù)上最核心的概念就是實(shí)體和聚合，為了更好的理解什么是聚合、聚合根、聚合內(nèi)部實(shí)體，下面舉例說(shuō)明一下。想象一下一個(gè)電商系統(tǒng)的訂單相關(guān)的模型，我們可能會(huì)得到訂單 Order、訂單頭 OrderHeader、訂單行項(xiàng) OrderItem 三個(gè)相互關(guān)聯(lián)的概念：

• 一個(gè)叫做 Order 的聚合。

• 這個(gè)訂單聚合的聚合根是一個(gè)叫做 OrderHeader 的實(shí)體，實(shí)體 OrderHeader 的 ID 叫做 OrderId（訂單號(hào)）。

• 通過 OrderHeader 實(shí)體，我們可以訪問 OrderItem 實(shí)體的一個(gè)聚合。OrderItem 這個(gè)實(shí)體的局部 ID 叫做 ProductId（產(chǎn)品 ID）。因?yàn)闃I(yè)務(wù)善變不允許在同一個(gè)訂單的不同訂單項(xiàng)內(nèi)出現(xiàn)同一個(gè)產(chǎn)品，所以我們可以選擇產(chǎn)品 ID 作為訂單項(xiàng)的局部 ID。

“聚合是數(shù)據(jù)修改的單元”，基于這個(gè)原則，我們可以做到“聚合內(nèi)強(qiáng)一致、聚合外最終一致”，比如，我們可以不能接受一個(gè)訂單內(nèi)的所有訂單項(xiàng)的金額之和不等于訂單頭的總金額，我們就必須把訂單頭和訂單行項(xiàng)這兩個(gè)實(shí)體劃分到同一個(gè)聚合內(nèi)。

• 設(shè)計(jì)聚合的原則

我們不妨先看一下《實(shí)現(xiàn)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》一書中對(duì)聚合設(shè)計(jì)原則的描述，原文是有點(diǎn)不太好理解的，我來(lái)稍微解釋一下：

1. 在一致性邊界內(nèi)建模真正的不變條件。聚合用來(lái)封裝真正的不變性，而不是簡(jiǎn)單地將對(duì)象組合在一起。聚合內(nèi)有一套不變的業(yè)務(wù)規(guī)則，各實(shí)體和值對(duì)象按照統(tǒng)一的業(yè)務(wù)規(guī)則運(yùn)行，實(shí)現(xiàn)對(duì)象數(shù)據(jù)的一致性，邊界之外的任何東西都與該聚合無(wú)關(guān)，這就是聚合能實(shí)現(xiàn)業(yè)務(wù)高內(nèi)聚的原因。

2. 盡量設(shè)計(jì)小的聚合。如果聚合設(shè)計(jì)得過大，聚合會(huì)因?yàn)榘^多的實(shí)體，導(dǎo)致實(shí)體之間的管理過于復(fù)雜，高頻操作時(shí)會(huì)出現(xiàn)并發(fā)沖突或者數(shù)據(jù)庫(kù)鎖，最終導(dǎo)致系統(tǒng)可用性變差。而小聚合設(shè)計(jì)則可以降低由于業(yè)務(wù)過大導(dǎo)致聚合重構(gòu)的可能性，讓領(lǐng)域模型更能適應(yīng)業(yè)務(wù)的變化。

3. 通過唯一標(biāo)識(shí)引用其它聚合。聚合之間是通過關(guān)聯(lián)外部聚合根 ID 的方式引用，而不是直接對(duì)象引用的方式。外部聚合的對(duì)象放在聚合邊界內(nèi)管理，容易導(dǎo)致聚合的邊界不清晰，也會(huì)增加聚合之間的耦合度。

4. 在邊界之外使用最終一致性。聚合內(nèi)數(shù)據(jù)強(qiáng)一致性，而聚合之間數(shù)據(jù)最終一致性。在一次事務(wù)中，最多只能更改一個(gè)聚合的狀態(tài)。如果一次業(yè)務(wù)操作涉及多個(gè)聚合狀態(tài)的更改，應(yīng)采用領(lǐng)域事件的方式異步修改相關(guān)的聚合，實(shí)現(xiàn)聚合之間的解耦（相關(guān)內(nèi)容我會(huì)在領(lǐng)域事件部分詳解）。

5. 通過應(yīng)用層實(shí)現(xiàn)跨聚合的服務(wù)調(diào)用。為實(shí)現(xiàn)微服務(wù)內(nèi)聚合之間的解耦，以及未來(lái)以聚合為單位的微服務(wù)組合和拆分，應(yīng)避免跨聚合的領(lǐng)域服務(wù)調(diào)用和跨聚合的數(shù)據(jù)庫(kù)表關(guān)聯(lián)。

上面的這些原則是 DDD 的一些通用的設(shè)計(jì)原則，還是那句話：“適合自己的才是最好的?！痹谙到y(tǒng)設(shè)計(jì)過程時(shí)，你一定要考慮項(xiàng)目的具體情況，如果面臨使用的便利性、高性能要求、技術(shù)能力缺失和全局事務(wù)管理等影響因素，這些原則也并不是不能突破的，總之一切以解決實(shí)際問題為出發(fā)點(diǎn)。

• 設(shè)計(jì)聚合的步驟

DDD 領(lǐng)域建模通常采用類似事件風(fēng)暴，一般通過用例分析、場(chǎng)景分析和用戶旅程分析等方法，通過頭腦風(fēng)暴列出所有可能的業(yè)務(wù)行為和事件，然后找出產(chǎn)生這些行為的領(lǐng)域?qū)ο螅⑹崂眍I(lǐng)域?qū)ο笾g的關(guān)系，找出聚合根，找出與聚合根業(yè)務(wù)緊密關(guān)聯(lián)的實(shí)體和值對(duì)象，再將聚合根、實(shí)體和值對(duì)象組合，構(gòu)建聚合。

電商系統(tǒng)大家都比較熟悉了，而且關(guān)于電商業(yè)務(wù)來(lái)說(shuō)有許多比較成熟的模型可以直接借鑒；那下面我們以另外一個(gè)場(chǎng)景-保險(xiǎn)投保業(yè)務(wù)為例，看一下聚合的構(gòu)建過程主要都包括哪些步驟，當(dāng)然這個(gè)例子我是從其他的學(xué)習(xí)資料里看到的，比較典型，可以當(dāng)作示例來(lái)進(jìn)行說(shuō)明：

保險(xiǎn)投保業(yè)務(wù)簡(jiǎn)單示例（From 學(xué)習(xí)資料）

• 第一步：采用用例分析或事件風(fēng)暴等方法，根據(jù)業(yè)務(wù)行為，梳理出在過程中發(fā)生這些行為的所有的實(shí)體和值對(duì)象，比如投保單、標(biāo)的、客戶、被保人等等。

• 第二步：從眾多實(shí)體中選出適合作為對(duì)象管理者的根實(shí)體，也就是聚合根。判斷一個(gè)實(shí)體是否是聚合根，上一章也說(shuō)過，你可以結(jié)合以下場(chǎng)景分析：是否有獨(dú)立的生命周期？是否有全局唯一 ID？是否可以創(chuàng)建或修改其它對(duì)象？是否有專門的模塊來(lái)管這個(gè)實(shí)體。圖中的聚合根分別是投保單和客戶實(shí)體。

• 第三步：根據(jù)上一章說(shuō)的設(shè)計(jì)聚合的原則，找出與聚合根關(guān)聯(lián)的所有緊密依賴的實(shí)體和值對(duì)象。構(gòu)建出一個(gè)包含一個(gè)聚合根、多個(gè)實(shí)體和值對(duì)象的對(duì)象集合，這個(gè)集合就是聚合。在圖中我們構(gòu)建了客戶和投保這兩個(gè)聚合。

• 第四步：在聚合內(nèi)根據(jù)聚合根、實(shí)體和值對(duì)象的依賴關(guān)系，畫出對(duì)象的引用和依賴模型。這里需要說(shuō)明一下：投保人和被保人的數(shù)據(jù)，是通過關(guān)聯(lián)客戶 ID 從客戶聚合中獲取的，在投保聚合里它們是投保單的值對(duì)象，這些值對(duì)象的數(shù)據(jù)是客戶的冗余數(shù)據(jù)，即使未來(lái)客戶聚合的數(shù)據(jù)發(fā)生了變更，也不會(huì)影響投保單的值對(duì)象數(shù)據(jù)。從圖中我們還可以看出實(shí)體之間的引用關(guān)系，比如在投保聚合里投保單聚合根引用了報(bào)價(jià)單實(shí)體，報(bào)價(jià)單實(shí)體則引用了報(bào)價(jià)規(guī)則子實(shí)體。

• 第五步：多個(gè)聚合根據(jù)業(yè)務(wù)語(yǔ)義和上下文一起劃分到同一個(gè)限界上下文內(nèi)。

那以上就是一個(gè)聚合誕生的完整過程了。

由于企業(yè)內(nèi)情況千差萬(wàn)別，發(fā)展歷程也不一樣，有遺留單體系統(tǒng)的微服務(wù)改造，也有全新未知領(lǐng)域的業(yè)務(wù)建模和系統(tǒng)設(shè)計(jì)，還有遺留系統(tǒng)局部?jī)?yōu)化的情況。不同場(chǎng)景下，領(lǐng)域建模的策略也會(huì)有差異。下面我們就分幾類場(chǎng)景來(lái)看看如何進(jìn)行領(lǐng)域建模。

新建系統(tǒng)對(duì)于復(fù)雜的業(yè)務(wù)領(lǐng)域，領(lǐng)域可能需要多級(jí)拆分后才能開始領(lǐng)域建模。領(lǐng)域拆分為子域，甚至子域還需要進(jìn)一步拆分。比如：保險(xiǎn)它需要拆分為承保、理賠、收付費(fèi)和再保等子域，承保子域再拆分為投保、保單管理等子子域。復(fù)雜領(lǐng)域如果不做進(jìn)一步細(xì)分，由于問題域太大，領(lǐng)域建模的工程量會(huì)非常浩大。你不太容易通過事件風(fēng)暴，完成一個(gè)很大的領(lǐng)域建模，即使勉強(qiáng)完成，效果也不一定好。

對(duì)于復(fù)雜領(lǐng)域，我們可以分三步來(lái)完成領(lǐng)域建模和微服務(wù)設(shè)計(jì)。

• 拆分子域建立領(lǐng)域模型，根據(jù)業(yè)務(wù)領(lǐng)域的特點(diǎn)，參考流程節(jié)點(diǎn)邊界或功能聚合模塊等邊界因素。結(jié)合領(lǐng)域?qū)＜液晚?xiàng)目團(tuán)隊(duì)的討論，將領(lǐng)域逐級(jí)分解為大小合適的子域，針對(duì)子域采用事件風(fēng)暴，劃分聚合和限界上下文，初步確定子域內(nèi)的領(lǐng)域模型。

• 領(lǐng)域模型微調(diào)梳理領(lǐng)域內(nèi)所有子域的領(lǐng)域模型，對(duì)各子域領(lǐng)域模型進(jìn)行微調(diào)。微調(diào)的過程重點(diǎn)考慮不同領(lǐng)域模型中聚合的重組。同步考慮領(lǐng)域模型和聚合的邊界，服務(wù)以及事件之間的依賴關(guān)系，確定最終的領(lǐng)域模型。

• 微服務(wù)的設(shè)計(jì)和拆分根據(jù)領(lǐng)域模型和微服務(wù)拆分原則，完成微服務(wù)的拆分和設(shè)計(jì)。

如果我們面對(duì)的是一個(gè)單體遺留系統(tǒng)，只需要將部分功能獨(dú)立為微服務(wù)，而其余仍為單體，整體保持不變，比如將面臨性能瓶頸的模塊拆分為微服務(wù)。我們只需要將這一特定功能，理解為一個(gè)簡(jiǎn)單子領(lǐng)域，參考簡(jiǎn)單領(lǐng)域建模的方式就可以了。在微服務(wù)設(shè)計(jì)中，我們還要考慮新老系統(tǒng)之間服務(wù)和業(yè)務(wù)的兼容，必要時(shí)可引入防腐層。

隨著云原生技術(shù)的興起，現(xiàn)在企業(yè)級(jí)架構(gòu)就更加的云化，而云化的架構(gòu)風(fēng)格有了新的關(guān)注點(diǎn)：彈性邊界。彈性邊界是一個(gè)云原生企業(yè)級(jí)應(yīng)用架構(gòu)的核心概念，它指把彈性作為最優(yōu)先的考慮要素而劃定的系統(tǒng)邊界，決定了我們是否能夠充分發(fā)揮云原生平臺(tái)的全部能力。于是我們就需要新的方法來(lái)彌補(bǔ)以前業(yè)務(wù)模型的不足，以滿足新的云原生化的需要。現(xiàn)在可以說(shuō)，微服務(wù)基本上就是以云原生架構(gòu)作為基礎(chǔ)，而在固定彈性的平臺(tái)上使用微服務(wù)架構(gòu)，有極高的實(shí)施成本。可以說(shuō)，云原生實(shí)際上就應(yīng)該是微服務(wù)的前置條件。

在云原生時(shí)代，我們需要將彈性作為首要考慮的因素，納入建模的考量。那么彈性邊界，就是我們劃分系統(tǒng)的重要依據(jù)。而且，我們還需要考慮彈性邊界間的依賴關(guān)系，盡量避免彈性耦合。對(duì)于業(yè)務(wù)建模來(lái)說(shuō)，為了配合云原生時(shí)代的架構(gòu)，我覺得要做到如下幾點(diǎn)：

• 確立一種模型結(jié)構(gòu)能夠反映彈性邊界，而這時(shí)候需要考慮不同彈性邊界的原則來(lái)劃分界限上下文；如果兩個(gè)上下文明顯具有不同的彈性訴求，那就應(yīng)該拆分。而如果具有一致的彈性訴求，可以考慮先不拆。那這個(gè)時(shí)候拆分微服務(wù)到底能多“微”呢？簡(jiǎn)單說(shuō)就是“微”到能夠更好的利用彈性來(lái)控制成本的大小。

• 從異步模型的視角，去優(yōu)化業(yè)務(wù)邏輯；典型就是 MQ 消息隊(duì)列系統(tǒng)，由于有 broker，所以生產(chǎn)者和消費(fèi)者不必在同一時(shí)間都保持可用性以及相同的吞吐量，而且生產(chǎn)者也不需要馬上等到回復(fù)。

• 位置的松耦合：典型就是服務(wù)注冊(cè)中心，消費(fèi)端完全不需要直接知道提供端的具體位置，而都通過注冊(cè)中心來(lái)查找服務(wù)來(lái)訪問。

• 在彈性邊界切分業(yè)務(wù)上下文時(shí)，同一個(gè)彈性邊界內(nèi)部維護(hù)業(yè)務(wù)強(qiáng)一致性。

• 在異步調(diào)用產(chǎn)生中間態(tài)異常時(shí)，需要維護(hù)業(yè)務(wù)最終一致性。

“康威定律”告訴我們，組織結(jié)構(gòu)會(huì)決定團(tuán)隊(duì)溝通的結(jié)構(gòu)，也會(huì)決定產(chǎn)品的結(jié)構(gòu)。對(duì)組織結(jié)構(gòu)的梳理，在需求調(diào)研的時(shí)候會(huì)經(jīng)常做。如果是信息收集而言，業(yè)務(wù)架構(gòu)設(shè)計(jì)在這里并沒有什么特殊之處。區(qū)別在于，業(yè)務(wù)架構(gòu)的目標(biāo)是企業(yè)級(jí)的能力規(guī)劃，希望能夠突破壁壘、形成合力。正是這個(gè)原因，組織結(jié)構(gòu)對(duì)業(yè)務(wù)架構(gòu)設(shè)計(jì)的反作用力也是很大的，企業(yè)級(jí)數(shù)字化轉(zhuǎn)型方案要與組織結(jié)構(gòu)相匹配，否則落地的時(shí)候會(huì)困難重重?？梢哉f(shuō)，部門利益是做企業(yè)級(jí)架構(gòu)的最大障礙之一，跨越這個(gè)障礙也是對(duì)架構(gòu)師的能力的要求之一。當(dāng)然，有些情況下，沒有更好的解決方案時(shí)，不動(dòng)也是一種選擇。

以我的經(jīng)驗(yàn)，這種問題沒有特別好的辦法，無(wú)非是兩種：一是有超強(qiáng)能力者主導(dǎo)，在最高層的支持下，強(qiáng)力推進(jìn)這種決策，但是企業(yè)越大，尤其是以業(yè)務(wù)為主導(dǎo)地位的企業(yè)中，這種結(jié)構(gòu)就愈難形成；二是加強(qiáng)企業(yè)內(nèi)部的業(yè)務(wù)架構(gòu)人員的能力和數(shù)量（最好各個(gè)部門都有類似的角色），讓這些企業(yè)機(jī)構(gòu)人員以合作伙伴的方式全程參與到項(xiàng)目中，在項(xiàng)目的實(shí)施過程中搭建起協(xié)作網(wǎng)絡(luò)，提升決策效率，才能使組織結(jié)構(gòu)不再是企業(yè)數(shù)字化轉(zhuǎn)型的瓶頸。

多年前，這些傳統(tǒng)的大型 ERP 業(yè)務(wù)軟件，其實(shí)都是在一個(gè)很大的范圍內(nèi)維護(hù)業(yè)務(wù)概念的完整性。一個(gè) ERP 安裝完畢后，數(shù)據(jù)庫(kù)有七八百?gòu)埍恚ㄒ簿褪瞧甙税賯€(gè)實(shí)體）處于同一個(gè)界限上下文之內(nèi)。但是這些 ERP 在這樣一個(gè)巨大的界限上下文內(nèi)仍然很好的維護(hù)了業(yè)務(wù)概念的完整性，實(shí)在令人敬佩。

然而實(shí)現(xiàn)它非常困難，但是破壞它卻非常容易。一套 ERP 定制項(xiàng)目實(shí)施下來(lái)，數(shù)據(jù)庫(kù)里可能又多了幾百?gòu)埍?，更不用說(shuō)不規(guī)范的命名看起來(lái)千奇百怪。這些廠商的 ERP 實(shí)施顧問和開發(fā)人員，夜以繼日的維護(hù)這個(gè)龐大的“屎山”。我們不能讓這些龐大的“單體應(yīng)用”無(wú)限制的增長(zhǎng)，于是我們又一次祭起了“分而治之”的大旗。想 SOA 這樣的軟件組件化技術(shù)給我們提供了拆分的工具。我們把一個(gè)大的界限上下文按照利于拆分成幾個(gè)相對(duì)來(lái)說(shuō)小一些的界限上下文；在物理上，我們把一個(gè)大的單體應(yīng)用拆分成若干服務(wù)。

一般來(lái)說(shuō)，我們會(huì)讓服務(wù)的物理邊界和界限上下文的領(lǐng)域邊界基本堆砌，一個(gè)界限上下文對(duì)一個(gè)或多個(gè)可以獨(dú)立部署的服務(wù)應(yīng)用，服務(wù)應(yīng)用包含了界限上下文的核心業(yè)務(wù)邏輯的實(shí)現(xiàn)。SOA 的服務(wù)組件的物理邊界給服務(wù)間的調(diào)用增加了一些困難，這就使得開飯人員簡(jiǎn)化對(duì)象之間的關(guān)系，編寫更加“高內(nèi)聚、低耦合”的代碼。當(dāng)服務(wù)組件不多的時(shí)候，構(gòu)建防腐層的工作量也不會(huì)很大，我們只要處理好組件之間的代碼即成就好了。

但是，我們的架構(gòu)師和開發(fā)人員太喜歡“分而治之”了，微服務(wù)的廣泛使用甚至說(shuō)是濫用，讓我們看很多微服務(wù)真的是很“微”，幾乎是一個(gè) DDD 的聚合就可以對(duì)應(yīng)一個(gè)可以獨(dú)立部署的微服務(wù)。這樣的微服務(wù)單單靠本身做不了太多的業(yè)務(wù)，這就需要更多更多的微服務(wù)“聚合”起來(lái)一起才能對(duì)外提供業(yè)務(wù)服務(wù)。

當(dāng)然，微服務(wù)技術(shù)基礎(chǔ)設(shè)施的發(fā)展也為服務(wù)之間的調(diào)用提供了更多的便利，跨越微服務(wù)的邊界成為了常態(tài)；這個(gè)時(shí)候，業(yè)務(wù)開發(fā)人員區(qū)分“同一個(gè)上下文內(nèi)的服務(wù)調(diào)用”和“上下文之間的防腐層”就要時(shí)刻保持頭腦清醒，這時(shí)候的界限上下文和微服務(wù)的物理邊界往往很難對(duì)齊，這就必然增加了維護(hù)每個(gè)界限上下文概念完整性的難度。

既然維護(hù)一個(gè)個(gè)“微小”的獨(dú)立的界限上下文概念完整性越來(lái)愈難，那么我們干脆將它們?cè)倬酆掀饋?lái)吧？將它們?nèi)诤系揭粋€(gè)大小適度的界限上下文，那這就是所謂的企業(yè)級(jí)業(yè)務(wù)架構(gòu)，也就是我們現(xiàn)在說(shuō)的業(yè)務(wù)中臺(tái)，最終目的可以說(shuō)想要獲得“企業(yè)級(jí)”的大和諧。

所以在一定程度上講，軟件工程就是妥協(xié)的藝術(shù)，是“中庸之道”。我們要不要中臺(tái)，要大的中臺(tái)，不管企業(yè)的大小，都應(yīng)該結(jié)合自身的業(yè)務(wù)目標(biāo)以及擁有的資源，在“維護(hù)更大范圍的概念完整性”和“維護(hù)更多的防腐層代碼”之間做出平衡，那這也是一個(gè)企業(yè)級(jí)架構(gòu)師所要做的最核心的事情之一。

我們團(tuán)隊(duì)這些年確實(shí)做了一些“業(yè)務(wù)中臺(tái)方法論”的積累和實(shí)踐，并且在一些項(xiàng)目中做了實(shí)踐，當(dāng)然其中最靈魂的部分之一還是前面說(shuō)的領(lǐng)域設(shè)計(jì)。以前很多人說(shuō) DDD 領(lǐng)域設(shè)計(jì)乃至業(yè)務(wù)中臺(tái)方法論最難的就是沒有一個(gè)合適的工具或者平臺(tái)來(lái)實(shí)踐，今天其實(shí)阿里開源的 COLA 以及內(nèi)部使用的星環(huán)、BizWorks 都是很好的工具和平臺(tái)。

企業(yè)級(jí)應(yīng)用架構(gòu)是在不斷的演進(jìn)和迭代，但是我始終感覺企業(yè)應(yīng)用架構(gòu)的形成過程是在一種看起來(lái)科學(xué)的方法論下，但是又不完全科學(xué)的過程中實(shí)現(xiàn)的。仔細(xì)想一下，做軟件架構(gòu)的其實(shí)很羨慕做建筑架構(gòu)的，因?yàn)榻ㄖ軜?gòu)有嚴(yán)謹(jǐn)?shù)牧W(xué)基礎(chǔ)作為基座，有很多可以精確計(jì)算的東西，而軟件架構(gòu)卻沒有多少可以精確計(jì)算出來(lái)的成分，所以，前面說(shuō)的“不斷的妥協(xié)”不失是一種可行的設(shè)計(jì)思路和設(shè)計(jì)藝術(shù)；其實(shí)這也應(yīng)驗(yàn)了那句“沒有銀彈”。

由于時(shí)間倉(cāng)促，有些內(nèi)容簡(jiǎn)單帶過，有些本應(yīng)該結(jié)合實(shí)例來(lái)說(shuō)明的地方在本文中也簡(jiǎn)略而過，后面有時(shí)間的話我會(huì)結(jié)合更多的實(shí)際案例來(lái)對(duì)本文說(shuō)的觀點(diǎn)進(jìn)行補(bǔ)充。也希望本文能夠激發(fā)大家一起對(duì)目前云原生時(shí)代的企業(yè)級(jí)應(yīng)用架構(gòu)設(shè)計(jì)的思考和討論，相互學(xué)習(xí)，共同進(jìn)步。