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在原則上的類似之處，好比用戶中心和協同設計。借用上面的高個子說法:

在業務需求認知和跨職能協做方面你必定須要成爲高個子！

---

做爲國內領域驅動設計（DDD）思想和實踐的領軍者，ThoughtWorks的架構諮詢師們但願和社區的合做夥伴一塊兒，組織一次領域驅動設計的峯會，從而建立一個讓國內的領域驅動設計（DDD）實踐者們互相交流、分享本身團隊的成功經驗的機會。咱們也但願經過這個大會，使得領域驅動設計（DDD）的架構思想可以在國內被更多人所認知，從而造成更大的規模效應。

咱們決定將於2017年12月8日、9日，在北京舉行領域驅動設計中國峯會 2017（DDD China Conference 2017）。現向國內同行和領域驅動設計（DDD）的實踐者們普遍徵集話題：jinshuju.net/f/f8Puf5