當(dāng)敏捷宣言的17位簽署者在2001年喊出“響應(yīng)變化勝于遵循計劃”這樣的口號時房午，鮮有組織會真正把這句話當(dāng)回事兒，甚至很多經(jīng)驗豐富的管理者會認(rèn)為好的計劃是成功的一半查辩，遵循計劃就是另外一半俩滥。然而在時下的第四次工業(yè)革命浪潮中巍实，可能很多管理者已經(jīng)不會簡單滿足于“響應(yīng)”，而是選擇主動發(fā)起變化了东涡。不確定性管理成了這個時代的主旋律冯吓，企業(yè)的響應(yīng)力成了成敗的關(guān)鍵。
隨著這種趨勢的深入疮跑，架構(gòu)設(shè)計這個技術(shù)管理領(lǐng)域也被推到了風(fēng)暴邊緣组贺。“穩(wěn)定”這個過去我們用來形容好系統(tǒng)的詞語似乎已經(jīng)失去原有的含義祖娘，很多人開始用“健壯”這個詞語來形容好的系統(tǒng)失尖。比如Netflix公司采用的Chaos Monkey機(jī)制隨機(jī)主動關(guān)停線上服務(wù)而不會造成整個服務(wù)生態(tài)宕機(jī)的作法更多的是在測試系統(tǒng)的健壯性，保證不會因為某個局部的問題而造成全身癱瘓。
然而架構(gòu)的健壯性卻比較難于定義和測試掀潮，以至于很多時候咱們在架構(gòu)設(shè)計上還是在追求穩(wěn)定性菇夸。在一個典型的企業(yè)IT組織里，當(dāng)你詢問一位資深工程師架構(gòu)設(shè)計時仪吧，往往會得到一張搭積木一樣的“架構(gòu)圖”庄新。
圖的底層是各種數(shù)據(jù)存儲（從經(jīng)典的Oracle到大數(shù)據(jù)標(biāo)配的Hadoop），圖的中間是類似Kafaka這樣的消息管道和傳統(tǒng)的ESB（消息總線）薯鼠，上層則是各種業(yè)務(wù)應(yīng)用（包括各種Web應(yīng)用和移動的APP）择诈。
仿佛這是一個流行的“穩(wěn)定”架構(gòu)設(shè)計。
（示意：典型的IT系統(tǒng)架構(gòu)圖）
當(dāng)詢問這樣的架構(gòu)是否合理時人断，不少人會告訴你問題可大了：這不是云時代的服務(wù)化架構(gòu)吭从。原因是這個架構(gòu)的大部分組件，如數(shù)據(jù)存儲恶迈，都已經(jīng)可以完全“托管”給云平臺了涩金。于是乎，很多企業(yè)架構(gòu)師又開始尋找像過去ESB一樣能夠?qū)痈鞣N云平臺的PaaS了暇仲，然后抱怨現(xiàn)在的PaaS沒有當(dāng)年的ESB“穩(wěn)定”步做。
兩個核心問題卻很少被提及：
- 當(dāng)年基于ESB集成的SOA服務(wù)化架構(gòu)解耦出的組件不但沒有提升效率，反而增加了系統(tǒng)后續(xù)修改的復(fù)雜度奈附。
- 看似“以不變應(yīng)萬變”的架構(gòu)并不能支撐多樣化的業(yè)務(wù)需求全度，最后各個業(yè)務(wù)部門仍然有一套自己的IT系統(tǒng)，即便是畫出來的架構(gòu)圖驚人的相似（多少次有人驚呼“這就是我們之前那個工作流系統(tǒng)~”）斥滤。
就這兩個核心痛點将鸵，讓我們一起來談?wù)劶軜?gòu)設(shè)計面臨的挑戰(zhàn)和應(yīng)對方式。
什么是架構(gòu)設(shè)計
由于軟件設(shè)計是一個復(fù)雜度很高的活動佑颇，“通過組件化完成關(guān)注點分離從而降低局部復(fù)雜度”很早就成為了咱們這個行業(yè)的共識顶掉。前面提到的數(shù)據(jù)存儲、消息管道等“模塊”在某種意義上都是組件化的產(chǎn)物挑胸。這樣的好處是在不同系統(tǒng)里遇到同樣的功能需求時可以復(fù)用痒筒。在云服務(wù)崛起的今天，這樣的組件以“服務(wù)”的形式更容易為我們所采用茬贵。
當(dāng)然技術(shù)出身的架構(gòu)師們在架構(gòu)設(shè)計的時候或多或少都有一種“搭積木”的感覺簿透。大家都非常關(guān)注Kafaka有哪些功能，K8S是不是比Mesos功能更全解藻，以及Akka是不是穩(wěn)定老充。就像走進(jìn)一個家裝公司，在選擇了“套餐”之后有工程人員給你介紹地磚和木地板用哪個品牌更好螟左。
回到咱們的第二個核心痛點蚂维，如果只是這樣的搭積木戳粒，為什么咱們總是在面對新變化、新需求的時候發(fā)現(xiàn)需要新的組裝方式或新的組件呢虫啥？這樣的架構(gòu)設(shè)計對比直接按照需求實現(xiàn)（不考慮架構(gòu)）有什么優(yōu)勢呢蔚约？
這里我們應(yīng)該回到架構(gòu)設(shè)計的本質(zhì)，即為什么我們要在代碼實現(xiàn)前做設(shè)計涂籽。顯然如果去掉設(shè)計這個過程苹祟，大家會說問題這么復(fù)雜，如何下手捌来啤树枫？所以設(shè)計首先是要解決問題的復(fù)雜度。于是有人做了一個架構(gòu)景东，交給了一個團(tuán)隊去實現(xiàn)砂轻，很快發(fā)現(xiàn)實現(xiàn)的架構(gòu)和設(shè)計完全是兩張皮。當(dāng)然原因很明確——缺少了交流和溝通斤吐，所以設(shè)計其次是要建立團(tuán)隊協(xié)作溝通的共識搔涝。
假設(shè)我們產(chǎn)生了一個團(tuán)隊都達(dá)成共識的架構(gòu)設(shè)計，大家都兢兢業(yè)業(yè)把設(shè)計變成了現(xiàn)實和措。一個長期困擾軟件行業(yè)的問題出現(xiàn)了庄呈，需求總是在變化，無論預(yù)先設(shè)計如何“精確”派阱，總是發(fā)現(xiàn)下一個坑就在不遠(yuǎn)處诬留。相信很多技術(shù)人員都有這樣的經(jīng)歷，結(jié)果往往是情況越來越糟糕贫母，也就是我們常說的架構(gòu)腐化了文兑，最后大家不得不接受重寫。這些經(jīng)歷讓我們逐步明確了軟件架構(gòu)設(shè)計的實質(zhì)是讓系統(tǒng)能夠更快地響應(yīng)外界業(yè)務(wù)的變化腺劣，并且使得系統(tǒng)能夠持續(xù)演進(jìn)彩届。在遇到變化時不需要從頭開始，保證實現(xiàn)成本得到有效控制誓酒。
面向業(yè)務(wù)變化而架構(gòu)
基于上面的架構(gòu)設(shè)計定義，關(guān)鍵因素就是業(yè)務(wù)變化贮聂。顯然這個時代的業(yè)務(wù)變化是很快的靠柑，甚至很多業(yè)務(wù)主動在變，不變則亡是很多行業(yè)目前的共識吓懈。變化速度給架構(gòu)設(shè)計帶來了很大挑戰(zhàn)歼冰，一個移動APP可能需要在一周內(nèi)上線，然而為了支撐這個移動APP的后臺服務(wù)耻警，平臺發(fā)布窗口是每兩個月一次隔嫡。這樣的不匹配在IT領(lǐng)域里是隨處可見的現(xiàn)實甸怕，我們習(xí)慣性地認(rèn)為后臺天然就很重因此很慢，只可能在犧牲質(zhì)量的情況下滿足這樣的速度腮恩。
然而事實上這樣的健壯架構(gòu)確實是存在的梢杭，看看身邊現(xiàn)在無處不在的互聯(lián)網(wǎng)，又有哪一個企業(yè)的架構(gòu)比之復(fù)雜呢秸滴∥淦酰互聯(lián)網(wǎng)系統(tǒng)的組件是一個個網(wǎng)站，每個網(wǎng)站完成著自己的業(yè)務(wù)功能更新荡含，從新聞發(fā)布到在線聊天咒唆。而各個站點又是緊密互聯(lián)的，聊天網(wǎng)站可能把新聞網(wǎng)站拿到的信息實時推送給在線的用戶释液。每個網(wǎng)站都是獨立的小單元全释，面向互聯(lián)網(wǎng)用戶提供著一定的業(yè)務(wù)服務(wù)。好的網(wǎng)站也根據(jù)用戶的反饋在不停升級和變化误债，但這樣的變化并不影響用戶使用其它的網(wǎng)站浸船。
從互聯(lián)網(wǎng)架構(gòu)我們可以學(xué)到什么呢？從架構(gòu)設(shè)計角度我認(rèn)為以下三點是關(guān)鍵找前。
- 讓我們的組件劃分盡量靠近變化的原點糟袁，對于互聯(lián)網(wǎng)來說就是用戶和業(yè)務(wù)，這樣的劃分能夠讓我們將變化“隔離”在一定的范圍（組件）內(nèi)躺盛，從而幫助我們有效減少改變點项戴。
- 組件之間能夠互相調(diào)用，但彼此之間不應(yīng)該有強(qiáng)依賴槽惫，即各自完成的業(yè)務(wù)是相對獨立的周叮，不會因為一方掉線而牽連另外一方，比如新聞網(wǎng)站掛掉了界斜，聊天網(wǎng)站應(yīng)該繼續(xù)正常提供服務(wù)仿耽，可能提示用戶暫時無法提供新聞信息而已。
- 組件在業(yè)務(wù)上是鼓勵復(fù)用的各薇，正是這樣的復(fù)用才成就了今天的互聯(lián)網(wǎng)项贺，我們不會每個網(wǎng)站都去實現(xiàn)一個強(qiáng)大的搜索引擎。而被“復(fù)用”最多的網(wǎng)站顯然會受到追捧峭判，成為明星業(yè)務(wù)开缎。當(dāng)然架構(gòu)上這樣的網(wǎng)站必然是健壯的。
上面的三點毫無疑問都指向了業(yè)務(wù)林螃，從業(yè)務(wù)出發(fā)奕删、面向業(yè)務(wù)變化是我們現(xiàn)代架構(gòu)設(shè)計成功的關(guān)鍵。
架構(gòu)設(shè)計的核心實質(zhì)是保證面對業(yè)務(wù)變化時我們能夠有足夠快的響應(yīng)能力疗认。
這種響應(yīng)力體現(xiàn)在新需求（變化）的實現(xiàn)速度上完残，也體現(xiàn)在我們組件的復(fù)用上伏钠，在實現(xiàn)過程中現(xiàn)有架構(gòu)和代碼變化點的數(shù)量也是技術(shù)人員能夠切身體會到的。面對日新月異的數(shù)字化時代谨设，組織的整體關(guān)注點都應(yīng)該集中到變化的原點熟掂，即業(yè)務(wù)上，而架構(gòu)應(yīng)該服務(wù)于這種組織模式铝宵，讓這樣的模式落地變得自然打掘。
對比之前的傳統(tǒng)SOA架構(gòu)，這個思路的變化是本質(zhì)性的鹏秋。類似工業(yè)總線（ESB）這樣的組件化其實是面向技術(shù)的尊蚁，希望通過技術(shù)平臺的靈活性來解決業(yè)務(wù)變化的多樣性。雖然短時間能夠收到一定的成效侣夷，長期看必然把自身做成瓶頸横朋，因為所有業(yè)務(wù)的變化最后都堆積到了這個技術(shù)組件來解決。這也回答了為什么實施了傳統(tǒng)SOA架構(gòu)的企業(yè)最后都發(fā)現(xiàn)響應(yīng)速度其實并沒有提升起來百拓。
面向業(yè)務(wù)變化而架構(gòu)就要求首先理解業(yè)務(wù)的核心問題琴锭，即有針對性地進(jìn)行關(guān)注點分離來找到相對內(nèi)聚的業(yè)務(wù)活動形成子問題域。子問題域內(nèi)部是相對穩(wěn)定的衙传，即未來的變化頻率不會很高决帖，而子問題邊界是很容易變化的，比如在一個物流系統(tǒng)中：計算貨物從A地到B地的路徑是相對固定的蓖捶，計算包裹的體積及歸類也是相對固定的地回，但根據(jù)包裹的體積優(yōu)化路徑卻經(jīng)常會根據(jù)業(yè)務(wù)條件而變化。
（子問題域的劃分）
面對業(yè)務(wù)的變化也要求我們的架構(gòu)必須是演進(jìn)的俊鱼，因為業(yè)務(wù)的變化點也會隨著時間推移發(fā)生著變化刻像。這意味著在一款較長生命周期的軟件產(chǎn)品中，不會出現(xiàn)類似ESB這樣的重型組件并闲，相反的我們追求的是一些面向業(yè)務(wù)服務(wù)的輕量級組件细睡，它們的持續(xù)演進(jìn)也會造成老組件的合并，新組件的重新拆分帝火。當(dāng)然這也成了現(xiàn)代微服務(wù)架構(gòu)成功的基礎(chǔ)條件之一溜徙。
打造架構(gòu)響應(yīng)力的方法
如果認(rèn)同了上述現(xiàn)代架構(gòu)的真正意義，大家一定會問怎么才能打造這樣的高響應(yīng)力架構(gòu)呢犀填？
領(lǐng)域驅(qū)動設(shè)計方法DDD（Domain Driven Design）為我們提供了很好的切入點蠢壹。這個2003年就總結(jié)出來的方法終于在10多年后重新走入了架構(gòu)師的視野，而這一次大家已經(jīng)意識到了這種方法在這個快速變化時代的重要性宏浩。DDD通過以下兩個模式去有效解決了文章開始提到的兩大痛點：
- 讓團(tuán)隊中各個角色（從業(yè)務(wù)到開發(fā)測試）都能夠采用統(tǒng)一的架構(gòu)語言，從而避免組件劃分過程中的邊界錯位靠瞎。
- 讓業(yè)務(wù)架構(gòu)和系統(tǒng)架構(gòu)形成綁定關(guān)系比庄，從而建立針對業(yè)務(wù)變化的高響應(yīng)力架構(gòu)求妹。
這兩點是DDD的核心，也是為什么時下全球架構(gòu)圈在進(jìn)一步向DDD這個方向靠攏的原因佳窑。DDD明確了業(yè)務(wù)和系統(tǒng)架構(gòu)上的綁定關(guān)系制恍，并提供了一套元語言來幫助各個角色有效交流架構(gòu)設(shè)計。
（DDD的基本方法）
在戰(zhàn)略層面神凑，DDD非常強(qiáng)調(diào)針對業(yè)務(wù)問題的分析和分解净神，通過識別核心問題域來降低分析的復(fù)雜度。在戰(zhàn)術(shù)層面溉委，DDD強(qiáng)調(diào)通過識別問題域里的不同業(yè)務(wù)上下文來進(jìn)行面向業(yè)務(wù)需求的組件化鹃唯。最后在實現(xiàn)層面利用成熟的技術(shù)模式屏蔽掉技術(shù)細(xì)節(jié)的復(fù)雜度。
在這里我們也希望通過第一屆DDD China建立起一個架構(gòu)設(shè)計人員的交流平臺瓣喊。期待更多的中國技術(shù)人員能夠通過這個平臺和世界一流架構(gòu)大師們建立起溝通的渠道坡慌，不僅在戰(zhàn)略層面，也在戰(zhàn)術(shù)層面和所有人一起分享討論關(guān)于DDD的一切藻三。
文：ThoughtWorks肖然
