DDD戰略篇：架構設計的響應力
當敏捷宣言的17位簽署者在2001年喊出“響應變化勝于遵循計劃”這樣的口號時，鮮有組織會真正把這句話當回事兒，甚至很多經驗豐富的管理者會認為好的計劃是成功的一半，遵循計劃就是另外一半。然而在時下的第四次工業革命浪潮中，可能很多管理者已經不會簡單滿足于“響應”，而是選擇主動發起變化了。不確定性管理成了這個時代的主旋律，企業的響應力成了成敗的關鍵。
隨著這種趨勢的深入，架構設計這個技術管理領域也被推到了風暴邊緣。“穩定”這個過去我們用來形容好系統的詞語似乎已經失去原有的含義，很多人開始用“健壯”這個詞語來形容好的系統。比如Netflix公司采用的Chaos Monkey機制隨機主動關停線上服務而不會造成整個服務生態宕機的作法更多的是在測試系統的健壯性，保證不會因為某個局部的問題而造成全身癱瘓。
然而架構的健壯性卻比較難于定義和測試，以至于很多時候咱們在架構設計上還是在追求穩定性。在一個典型的企業IT組織里，當你詢問一位資深工程師架構設計時，往往會得到一張搭積木一樣的“架構圖”。
圖的底層是各種數據存儲(從經典的Oracle到大數據標配的Hadoop)，圖的中間是類似Kafaka這樣的消息管道和傳統的ESB(消息總線)，上層則是各種業務應用(包括各種Web應用和移動的APP)。
仿佛這是一個流行的“穩定”架構設計。
(示意：典型的IT系統架構圖)
當詢問這樣的架構是否合理時，不少人會告訴你問題可大了：這不是云時代的服務化架構。原因是這個架構的大部分組件，如數據存儲，都已經可以完全“托管”給云平臺了。于是乎，很多企業架構師又開始尋找像過去ESB一樣能夠對接各種云平臺的PaaS了，然后抱怨現在的PaaS沒有當年的ESB“穩定”。
兩個核心問題卻很少被提及：
- 當年基于ESB集成的SOA服務化架構解耦出的組件不但沒有提升效率，反而增加了系統后續修改的復雜度。
- 看似“以不變應萬變”的架構并不能支撐多樣化的業務需求，最后各個業務部門仍然有一套自己的IT系統，即便是畫出來的架構圖驚人的相似(多少次有人驚呼“這就是我們之前那個工作流系統~”)。
就這兩個核心痛點，讓我們一起來談談架構設計面臨的挑戰和應對方式。
什么是架構設計
由于軟件設計是一個復雜度很高的活動，“通過組件化完成關注點分離從而降低局部復雜度”很早就成為了咱們這個行業的共識。前面提到的數據存儲、消息管道等“模塊”在某種意義上都是組件化的產物。這樣的好處是在不同系統里遇到同樣的功能需求時可以復用。在云服務崛起的今天，這樣的組件以“服務”的形式更容易為我們所采用。
當然技術出身的架構師們在架構設計的時候或多或少都有一種“搭積木”的感覺。大家都非常關注Kafaka有哪些功能，K8S是不是比Mesos功能更全，以及Akka是不是穩定。就像走進一個家裝公司，在選擇了“套餐”之后有工程人員給你介紹地磚和木地板用哪個品牌更好。
回到咱們的第二個核心痛點，如果只是這樣的搭積木，為什么咱們總是在面對新變化、新需求的時候發現需要新的組裝方式或新的組件呢?這樣的架構設計對比直接按照需求實現(不考慮架構)有什么優勢呢?
這里我們應該回到架構設計的本質，即為什么我們要在代碼實現前做設計。顯然如果去掉設計這個過程，大家會說問題這么復雜，如何下手啊?所以設計首先是要解決問題的復雜度。于是有人做了一個架構，交給了一個團隊去實現，很快發現實現的架構和設計完全是兩張皮。當然原因很明確——缺少了交流和溝通，所以設計其次是要建立團隊協作溝通的共識。
假設我們產生了一個團隊都達成共識的架構設計，大家都兢兢業業把設計變成了現實。一個長期困擾軟件行業的問題出現了，需求總是在變化，無論預先設計如何“精確”，總是發現下一個坑就在不遠處。相信很多技術人員都有這樣的經歷，結果往往是情況越來越糟糕，也就是我們常說的架構腐化了，最后大家不得不接受重寫。這些經歷讓我們逐步明確了軟件架構設計的實質是讓系統能夠更快地響應外界業務的變化，并且使得系統能夠持續演進。在遇到變化時不需要從頭開始，保證實現成本得到有效控制。
面向業務變化而架構
基于上面的架構設計定義，關鍵因素就是業務變化。顯然這個時代的業務變化是很快的，甚至很多業務主動在變，不變則亡是很多行業目前的共識。變化速度給架構設計帶來了很大挑戰，一個移動APP可能需要在一周內上線，然而為了支撐這個移動APP的后臺服務，平臺發布窗口是每兩個月一次。這樣的不匹配在IT領域里是隨處可見的現實，我們習慣性地認為后臺天然就很重因此很慢，只可能在犧牲質量的情況下滿足這樣的速度。
然而事實上這樣的健壯架構確實是存在的，看看身邊現在無處不在的互聯網，又有哪一個企業的架構比之復雜呢。互聯網系統的組件是一個個網站，每個網站完成著自己的業務功能更新，從新聞發布到在線聊天。而各個站點又是緊密互聯的，聊天網站可能把新聞網站拿到的信息實時推送給在線的用戶。每個網站都是獨立的小單元，面向互聯網用戶提供著一定的業務服務。好的網站也根據用戶的反饋在不停升級和變化，但這樣的變化并不影響用戶使用其它的網站。
從互聯網架構我們可以學到什么呢?從架構設計角度我認為以下三點是關鍵。
- 讓我們的組件劃分盡量靠近變化的原點，對于互聯網來說就是用戶和業務，這樣的劃分能夠讓我們將變化“隔離”在一定的范圍(組件)內，從而幫助我們有效減少改變點。
- 組件之間能夠互相調用，但彼此之間不應該有強依賴，即各自完成的業務是相對獨立的，不會因為一方掉線而牽連另外一方，比如新聞網站掛掉了，聊天網站應該繼續正常提供服務，可能提示用戶暫時無法提供新聞信息而已。
- 組件在業務上是鼓勵復用的，正是這樣的復用才成就了今天的互聯網，我們不會每個網站都去實現一個強大的搜索引擎。而被“復用”最多的網站顯然會受到追捧，成為明星業務。當然架構上這樣的網站必然是健壯的。
上面的三點毫無疑問都指向了業務，從業務出發、面向業務變化是我們現代架構設計成功的關鍵。
架構設計的核心實質是保證面對業務變化時我們能夠有足夠快的響應能力。
這種響應力體現在新需求(變化)的實現速度上，也體現在我們組件的復用上，在實現過程中現有架構和代碼變化點的數量也是技術人員能夠切身體會到的。面對日新月異的數字化時代，組織的整體關注點都應該集中到變化的原點，即業務上，而架構應該服務于這種組織模式，讓這樣的模式落地變得自然。
對比之前的傳統SOA架構，這個思路的變化是本質性的。類似工業總線(ESB)這樣的組件化其實是面向技術的，希望通過技術平臺的靈活性來解決業務變化的多樣性。雖然短時間能夠收到一定的成效，長期看必然把自身做成瓶頸，因為所有業務的變化最后都堆積到了這個技術組件來解決。這也回答了為什么實施了傳統SOA架構的企業最后都發現響應速度其實并沒有提升起來。
面向業務變化而架構就要求首先理解業務的核心問題，即有針對性地進行關注點分離來找到相對內聚的業務活動形成子問題域。子問題域內部是相對穩定的，即未來的變化頻率不會很高，而子問題邊界是很容易變化的，比如在一個物流系統中：計算貨物從A地到B地的路徑是相對固定的，計算包裹的體積及歸類也是相對固定的，但根據包裹的體積優化路徑卻經常會根據業務條件而變化。
(子問題域的劃分)
面對業務的變化也要求我們的架構必須是演進的，因為業務的變化點也會隨著時間推移發生著變化。這意味著在一款較長生命周期的軟件產品中，不會出現類似ESB這樣的重型組件，相反的我們追求的是一些面向業務服務的輕量級組件，它們的持續演進也會造成老組件的合并，新組件的重新拆分。當然這也成了現代微服務架構成功的基礎條件之一。
打造架構響應力的方法
如果認同了上述現代架構的真正意義，大家一定會問怎么才能打造這樣的高響應力架構呢?
領域驅動設計方法DDD(Domain Driven Design)為我們提供了很好的切入點。這個2003年就總結出來的方法終于在10多年后重新走入了架構師的視野，而這一次大家已經意識到了這種方法在這個快速變化時代的重要性。DDD通過以下兩個模式去有效解決了文章開始提到的兩大痛點：
- 讓團隊中各個角色(從業務到開發測試)都能夠采用統一的架構語言，從而避免組件劃分過程中的邊界錯位。
- 讓業務架構和系統架構形成綁定關系，從而建立針對業務變化的高響應力架構。
這兩點是DDD的核心，也是為什么時下全球架構圈在進一步向DDD這個方向靠攏的原因。DDD明確了業務和系統架構上的綁定關系，并提供了一套元語言來幫助各個角色有效交流架構設計。
(DDD的基本方法)
在戰略層面，DDD非常強調針對業務問題的分析和分解，通過識別核心問題域來降低分析的復雜度。在戰術層面，DDD強調通過識別問題域里的不同業務上下文來進行面向業務需求的組件化。最后在實現層面利用成熟的技術模式屏蔽掉技術細節的復雜度。
【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】
