DDD & Microservices
Microservices(微服務架構)和DDD(領域驅動設計)是時下最炙手可熱的兩個技術詞語。在最近兩年的咨詢工作中總是會被不同的團隊和角色詢問，由此也促使我思考為什么這兩個技術詞匯被這么深入人心的綁定，它們之間的關系是什么呢?
服務于更高的業務響應力
首先從兩個詞匯的發明來看它們是沒有因果關系的。
DDD是Eric Evans于2003年出版的書名，同時也是這個架構設計方法名的起源。DDD的想法是讓我們的軟件實現和一個演進的架構模型保持一致，而這個演進的模型來自于我們的業務需求。這種演進式設計方法在當時看來還是比較挑戰的，更為流行的解決架構設計復雜度的方法是分層：比如數據架構、服務架構、中間件架構等。MVC在互聯網應用開發領域也基本成為了標配。
時間很快過了10年，Martin Fowler和ThoughtWorks英國架構師James Lewis坐下來一起分析了好幾個能夠持續演進的大型復雜系統，總結出了9大核心特質，然后用Microservices來定義了擁有這些特質的架構。
之后由于Google、Netflix、Amazon等一系列明星企業都對號入座，Microservices開始風靡整個軟件業。這時候很多人會問微服務架構是怎么設計出來的，業界人士會說DDD是一個好方法，其中也包括微服務定義者Martin Fowler，畢竟DDD原書的序是他給著的，于是乎DDD開始在被定義10年后火了。
從我個人角度來看，如果真的需要找到因果關系的話，最根本的驅動力來自于科技時代對軟件系統(數字化)響應力要求的不斷提升，而系統的復雜度卻隨著業務的多元化而與日俱增。如何駕馭這樣的高復雜度成了每個企業必須面對的挑戰，以至于業界開始把這種模型總結為響應力企業(Responsive Enterprise)，而模型中總結的大部分原則都是為了更好的適應環境不確定性帶來的高復雜度。
從業務視角分離復雜度
每個人能夠認知的復雜度都是有限的，在面對高復雜度的時候我們會做關注點分離，這是一個最基本的哲學原則。顯然在針對復雜業務場景進行建模時，我們也會應用此原則。這個時候去分離關注點一般可以從兩個維度出發：
- 技術維度分離，類似MVC這樣的分層思想是我們廣泛接受的。
- 業務維度分離，根據不同的業態劃分系統，比如按售前、銷售、售后劃分。
以上兩個維度沒有孰優孰劣之分，在處理復雜問題的時候一定都會用上，但為了能夠高效響應業務的變化，微服務的架構更強調業務維度的關注點分離來應對高復雜度。這是顯著區別于傳統SOA架構的特質之一，比如誕生于傳統SOA時代的ESB(工業服務總線)就是一個典型的技術關注點分離出來的中間件。
隨著業務的變化，我們也看到ESB成為了一個架構上的反模式，即大量的業務規則和流程被封裝在了ESB里，讓ESB成為了不可駕馭的復雜度之源，以至于破壞了SOA架構之前承諾的各種優勢。當然Microservices架構并非是新一代SOA架構這么簡單，已經有不少文章在討論這個話題，本文就不在展開了。
所以從本質上作為一種架構設計方法的DDD和作為一種架構風格的Microservices都是為著追求高響應力目標而從業務視角去分離復雜度的手段。
如果這個時代你還覺得自己的架構不需要這種響應力，我建議你問問身邊維護3年以上系統的朋友或同事們，他們會告訴你這是怎樣的一種痛苦。實際上很多企業對這種響應力的追求已經很“瘋狂”了，這也是微服務的兩位定義者可能都始料未及的。
他們在定義文章中帶著很強警告語氣讓大家慎用，但在這個科技時代，微服務架構實施的可能風險對比高響應力在未來可能帶來的市場機會幾乎可以忽略不計。一個Netflix的成功就足以讓大部分企業毫不猶豫的選擇微服務作為自身的架構風格。
業務和技術漸進統一的架構設計
如果Microservices和DDD在目標上達成了上文的統一，那么在具體做法上和以前有什么不同呢?
為了解釋清楚這個問題讓我們極簡化架構設計為以下三個層面工作：
- 業務架構：根據業務需求設計業務模塊及交互關系。
- 系統架構：根據業務需求設計系統和子系統的模塊。
- 技術架構：根據業務需求決定采用的技術及框架。
顯然這三者在具體一個架構設計活動中應該是有先后順序的，但并非一定是孰先孰后，比如一個簡單的web應用，很多人會說MVC是標配了(首先確定了系統架構)，或者有人說用RoR快(首先確定了技術架構)。在給定的業務場景里，也許這樣的順序是合理的。
(架構設計工作分層及傳統意義上的負責人)
這個時候咱們增加復雜業務需求和快速市場變化這兩個環境變量，這個順序就變得很有意思了。于是我們聽到不少走出初創期的互聯網服務平臺開始“重寫”他們的系統(從PHP到Java)，很多文章開始反思MVC帶來的僵化(臃腫的展現層)。
經歷了這樣變遷的架構師們都會感同身受的出來為DDD站臺，其原因就是“跳過”(或“后補”)業務架構顯然表明設計出來的架構關注點并不在業務的響應力上，因為業務的可能變化點并沒有被分析出來指導系統和技術架構的設計。
DDD的核心訴求就是能夠讓業務架構和系統架構形成綁定關系，從而當我們去響應業務變化調整業務架構時，系統架構的改變是隨之自發的。
這個變化的結果有兩個：
- 業務架構的梳理和系統架構的梳理是同步漸進的，其結果是劃分出的業務上下文和系統模塊結構是綁定的。
- 技術架構是解耦的，可以根據劃分出來的業務上下文的系統架構選擇最合適的實現技術。
***點顯然也是我們產生微服務劃分所必須遵循的，因為微服務追求的是業務層面的復用，所以設計出來的系統必須是跟業務一致的。第二點更是微服務架構的特質：“去中心化”的治理技術和數據管理。 作為架構設計的方法，DDD的各種實踐，包括最近流行的Event Storming(事件風暴)實際上都是促進業務和系統架構梳理的漸進式認知。
在一次DDD工作坊中，一位同事給出了“你們連業務故事都講不清楚，還有必要繼續做架構設計嗎?”這樣的經典評論。而DDD的整個方法也沒有涉及具體的技術架構實現，這個選型的權利很多時候被“下放”給了真正的開發團隊。
值得一提的是采用DDD這種架構設計方法并不一定就產生Mircoservices這種架構風格，往往會推薦用大顆粒度的服務來包含業務分析過程中發現的不確定點，以避免拆分后變化過度頻繁帶來的雙向修改成本。
跨職能協作的架構設計
業務和系統的漸進認知改變了很多之前的架構工作模式，在采用DDD的過程中，很容易感受到業務專家的重要性。而如果還有人寄希望讓業務能夠一次性給架構師講清楚需求，那我建議抱有這樣希望的同學去親身參加一次自己不熟悉業務領域的架構設計討論。你會很容易得出結論“原來業務也不懂他要什么”。當然業務人員聽說要參加某種(軟件)架構設計方法時心里也一定是抵觸的。
DDD成功運用的基礎就是創造讓業務和系統這兩種不同認知模型逐步統一的環境。
(業務架構和系統架構設計)
所以“不幸”的是如果你不能建立一個跨業務和技術的新型架構設計小組，你的DDD實踐就沒有成功的基礎，繼而采用微服務架構可能就會是一場災難。幸運的是這種跨職能組織結構已經是前文中“采用”微服務架構企業(如Amazon)的標配，你不必再論證這件事情的可實施性。剩下的關鍵就是如何能夠讓不同背景的人們協作起來。這也是大家可以看到DDD領域的下一個熱點，類似Event Storming這樣的模式化協作工作坊會更多的出現在大家的視線里。
永無終止的DDD和演進的Microservices
DDD是容易上癮的，當大家發現原來通過這個建模過程業務專家更了解服務劃分(系統模塊)，架構設計更懂業務需求，這種協作會成為常態。在這個tech@core的時代，這樣的融合將成為企業的核心競爭力。
當然剛開始采用DDD方法的時候，請不要認為每個系統搞一次所謂的DDD工作坊就能夠找到***的服務劃分了。業務的變化是持續的，而每次業務架構變化必然牽動系統架構的變化。良好的領域架構綁定了業務和系統，讓雙方人員能夠用統一語言交流，這件事情建立不易，而持續運作更難。
成功的DDD方法運用是貫穿系統的整個生命周期的，這個過程中業務和技術的協作是持續發生的。
Microservices的***一個特質：“演進式”設計 - 也明確了設計是一種持續的活動。DDD提供了一種符合這個微服務特質的工作方法，讓演進能夠落地。值得一提的是就筆者最近的經驗，這個演進過程中最難認知到變化的就是DDD里最顯而易見的“統一語言”。當大家形成了一個業務概念-“客戶”后，少有團隊能夠持續審視這個“客戶”是否隨著市場的變化而發生了含義的變遷。
對比傳統的SOA，微服務的拆分也是動態的，禚嫻靜在自己的文章中描述一個系統采用微服務架構歷程中服務拆分的演變。這里不會有一個ESB來以不變應萬變，這種幻想在過去的10年里已經被數次打臉。DDD的好處是讓業務和技術人員都能夠在合作中理解這種變化，而不至于陷入業務人員抱怨技術架構不知所謂，技術人員覺得業務人員朝三暮四的尷尬。
你需要成為那個高個子!
Martin Fowler在Microservies的定義文章中畫了下面的圖，評論“你必須有那個高度”來隱喻微服務實施的能力要求。就架構建模方面來說我認為DDD應該是一個團隊必須去掌握的，包括這個團隊的業務人員和產品設計人員。
(微服務前置條件示意)
很有意思的是目前Service Design也是全球用戶體驗設計領域的一個熱門話題，從用戶視角出發去設計整個服務鏈條。比如時下熱門的共享單車，一個成功的服務設計應該是從用戶開始有用車需求觸發到***完成騎行繳費離開，而不僅僅是去設計一輛能夠互聯網解鎖的自行車。
我們可以找到很多Service Deisgn和DDD在原則上的相似之處，比如用戶中心和協同設計。借用上面的高個子說法:
在業務需求認知和跨職能協作方面你一定需要成為高個子!
【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】
