今天我們還需要關注DDD嗎？

12 月 8 日，ThoughtWorks 舉辦了第一屆 DDD（Domain-Driven Design，領域驅動設計）中國峰會，會上 DDD 領域的實踐者分享了他們對于 DDD 的理解與應用。DDD 是什么？我們認為它是比系統架構更高層次的概念，它是一種設計思想，很多時下流行的架構模式都是在這種思想影響下產生的，像最近備受關注的 CQRS、微服務其實都存在 DDD 思想的影子；同時，DDD 還在軟件行業的其它方方面面影響不斷。但是 DDD 本身相關內容并沒有多少人去傳播、去分享，這不禁讓我們想問： 我們需要去關注 DDD 嗎？

DDD 究竟意味著什么？在歷史的進程中 DDD 的發展是怎么樣的？它未來的發展前景如何？帶著一系列問題，我們在會場采訪了 DDD 資深專家、Event Storming 之父 Alberto Brandolini 與 ThoughtWorks 資深咨詢師王威。

DDD 是什么？

要討論需不需要關注 DDD，首要的是先了解 DDD 是什么。Alberto 認為，DDD 是一種在面向高度復雜的軟件系統時，關于如何去建模的 方法論 ，“它的關鍵點是根據系統的復雜程度，建立合適的模型”。在 Alberto 當天的演講“Why DDD Maters Today？”中，他提到“在一個系統中，沒有一個人能完全掌握系統的全貌”，在多人參與的系統中，DDD 正是可以通過在不同角色之間進行協作，使參與者達成統一認知，對齊系統設計與程序實際所服務的業務領域。

圖片源： http://insights.thoughtworks.cn/ddd-architecture-design/

具體來講，DDD 方法論在系統建模過程中，可以為團隊中的各個角色 提供一套統一語言 ，避免組件劃分過程中的邊界錯位，完成領域圖預演、需求分析、架構模型、代碼模型、測試等工作。“統一語言”概念在 DDD 中極為重要，在一個系統的構建過程中，往往業務人員關注的是業務架構，而技術人員則關注系統架構的表述方式；在將業務架構映射到系統架構的時候，需要經過一層“翻譯”工作；而業務只要發生變化，就會影響到系統，系統就要重新對業務進行翻譯，這會使工作變得復雜、低效。在 DDD 中，使用一個統一語言，可以直接將業務架構與系統架構綁定，不需要進一步去翻譯，從而 增強系統對業務的響應速度 。

“領域驅動設計”中的“領域”一詞指的是要實現的軟件系統所要解決的實際問題所處的整個領域范圍，它不僅包括系統架構的相關問題，還涉及到系統所支持的業務等內容，但它是與具體的開發技術無關的。也就是說 DDD 關注的是要構建的系統中，關于所要解決的問題的業務、流程和數據等內容是如何工作的，在這些東西理清之后，DDD 去構建出一個模型，接著再去選擇具體的實現技術。 DDD 強調的是解耦具體實現技術，所以它可以迅速梳理核心業務邏輯。

DDD 并不是直接給你建議某一個系統架構，它的執行結果是呈現一個方案，可以從這個構建出的模型中決定你去用什么技術來實現什么樣的架構，進而來完成一個系統的設計。技術在這個過程中是被選擇的，備選的各種技術只是像一個列表一樣擺在眼前，它要根據你的領域需求來選擇，比如“ 選擇采用微服務架構 ”。

也正是因為它關注的是領域，而不是具體技術，所以 DDD 其實不僅可以應用在軟件系統的開發中，也可以在其它領域，諸如測試體系的建設、公司的管理、需求變更的跟進和項目的管理。

總結起來，DDD 的一個生命周期是這樣的：在設計和實現一個系統的時候，這個系統所要處理問題的領域專家和開發人員以一套統一語言進行協作，共同完成該領域模型的構建，在這個過程中，業務架構和系統架構等問題都得到了解決，之后將領域模型中關于系統架構的主體映射為實現代碼，完成系統的實現落地。 而用什么方式去做領域模型的構建，方法是多樣的 ，Alberto 自己就為此發明了 Event Storming（事件風暴），并成為了一種經典的 DDD 落地模式。

Alberto 補充到：“為了方便理解，可以類比 精益創業 （Lean Startup），在我看來它是與 DDD 同個層次的概念，它也是一種能夠通過快速對業務進行分析，快速去建模，支撐業務的模式。”

從微服務到 DDD

DDD 自 2004 年出現以來，其核心概念基本沒發生什么變化，但是這些年來，DDD 整體的傳播與實踐都在向好的方向發展著，Alberto 認為有幾個時間點使他印象深刻：

• 2003 年，Eric Evans 發布了影響深遠的《Domain-Driven Design: Tackling Complexity in the Heart of Software》（領域驅動設計：軟件核心復雜性應對之道）一書，DDD 問世，開始受到關注；
• 2007 年，Alberto 開始接觸 DDD，他聽了 Eric 的演講，這讓他很震撼，因為他在這之中了解到 DDD 對于處理界限上下文（BoundedContext）的思路很有價值。于是他開始深入了解 DDD；
• 到了 2011 年，這是 Alberto 認為對 DDD 的發展至關重要的一年，這一年是 DDD 思想大爆發的時期。在這一年中，社區中聚集了一些 DDD 的思想領袖（Thought Leader），Eric Evans 自不必說，還有像《Implementing Domain-Driven Design》（實現領域驅動）的作者 Vaughn Vernon、微服務巨匠 Martin Fowler 等人，他們聚到了一起，紛紛拋出自己的想法。大家突然之間發現，原來 DDD 可以做的事情有很多，它可以用來做 CQRS，可以用來做測試體系的建設，也可以用來做項目的管理……DDD 的應用場景變得多了起來。同時，Alberto 自己在 Event Storming 方面的想法獲得成功，很多專家在演講中引用了他的這種 DDD 建模方式。他認為這一年非常有價值，業界大牛們就 DDD 展開了深入的交流。

而從國內來看，王威認為 2014 年微服務的興起是 DDD 的一個重要里程碑。不可否認， 很多人是因為微服務才了解 DDD 的 。在聽說了微服務架構之后，人們覺得采用微服務架構會讓系統開發與運維管理變得簡單高效，同時實現的系統會更加合理，更加高可用、高性能，但是當他們實際去做微服務架構的時候，有不少人會發現自己做得并不好，沒法取得人們“吹捧”的那些效果，“ 就算用了微服務架構也不能解決他們的問題，反而帶來很多開發與運維上的負擔 ”。于是他們去咨詢、去找方法，最后發現其實是自己劃分微服務的方法出錯了，這個時候才知道人們在談論微服務的時候，其實都沒有講到一個點： 應該用 DDD 的思想去指導微服務的實踐。

是的，關于微服務架構怎么做，網上已經有很多相關理論和實踐分享了，但是很少有人會說這個東西需要在 DDD 思想的指導下去做，在微服務的實踐過程中，如果一開始就用 DDD 進行了全局模型設計，那么業務拆分、代碼解耦等環節在實際架構建設時都是水到渠成的。而因為 DDD 使用統一語言來進行建模，這種高效建模、團隊內部溝通無障礙和快速響應業務變化的特點會讓微服務架構的實現更加簡易。許多人盲目地去做微服務，如果在那之前他們先了解了 DDD，那么在 DDD 的指導下，微服務或許又會有另一番美景；另一方面，許多人雖然不知道 DDD，但是他們在系統構建的過程中， 思想其實或多或少都會與 DDD 相符 ，那么，如果能夠提前去了解 DDD，“ 從 DDD 到微服務，而不是從微服務到 DDD ”，全面而系統地從頭到尾以 DDD 的思想來操作，就能進一步降低微服務架構過程中行差踏錯的可能性。

當然，人們談論微服務而不涉及 DDD，可能還有另一種情況，就是他們實際上就是在 DDD 的指導下完成了微服務架構，但是“由于在建模的過程中，核心領域就是公司的核心資產，公司一般是不會把這個東西拿出來分享的”，王威解釋到。很容易理解，像大型電信、金融企業，他們的業務核心模型肯定是屬于公司機密，不會對外分享的。這其實也就是如今雖然 DDD 已經可以被應用在各種業務場景下，但是我們很難看到 DDD 實踐案例的一個重要原因。

不管從國外還是國內來看，目前 DDD 主要還是停留在社區層面，但是就像 Alberto 說的“去參加演講，今年看到的是這些人，明年看到的基本還是這些人”，雖然社區仍然不大，參與者的忠誠度卻是很高的。如今，國外有比較知名的 DDD Europe、DDD Exchange 等會議，國內像這次也舉辦了“DDD 中國峰會”，隨著對 DDD 的研究、實踐與傳播，“ 這個圈子正在變得越來越大，我們相信更多的 DDD 實踐將會被分享 ”。

看到這些變化，Alberto 與王威都認為 DDD 迎來了發展的最佳時機。越來越多人關注 DDD，而且出現了更多的企業去使用 DDD 的優勢做業務，這使得目前 DDD 的境況不會變得更糟，但是 Alberto 提出了他的擔憂：“ 我害怕 DDD 會不會最后變得像敏捷（Agile）那樣 。”王威進一步解釋：“敏捷一開始其實是很好的，它的原則非常理想，大家對它的實踐也非常廣，但是目前來看敏捷，會發現每個人的實踐都不同，大家對它的認知可能有分歧，甚至有些實踐背離了敏捷的初衷。”兩位都不希望 DDD 將來會發生類似的情況。

我們需要關注 DDD 嗎？

DDD 的思想在它問世的這十幾年間已經深深地影響了軟件行業的架構理論和各種實踐發展，像 CQRS 架構、依賴反轉、洋蔥圈架構、EDA 事件驅動架構和微服務架構等都能找到 DDD 的影子。DDD 甚至影響了軟件行業中的各個方面，比如在本次 DDD 會議上還可以看到，有的講師從測試體系的建設、公司的管理、需求變更的跟進和項目的管理等方面分享了 DDD 的應用。

通常來說，DDD 適用于任何規模、任何性質的公司，這是一種通用的、具有指導意義的方法論，因此它可以 在各個業務場景里發揮作用 。

王威認為，DDD 作為一種方法論，我們更應該關注的是它 能夠幫助團隊針對業務達成一個統一的認知 。在這個業務變化節奏相當快的時代，系統架構是必須不斷演進的，而 DDD 在這個過程中因為構建了團隊的統一語言，使得在對業務的快速響應方面表現得出類拔萃，這是它的精髓，不管什么領域，只要有這種業務快速響應的需求，那么 DDD 都是適用的。以往想要啟動一個系統架構設計的時候，需要 3、4 個月的時間去咨詢，等待調研報告，但是如果以 DDD 的方式，那么 2、3 周就可以出一份 Roadmap。王威說：“客戶更看重的是 DDD 對整個業務領域統一的認知，以及對業務響應變化的能力，DDD 快速啟動的能力。”Alberto 補充說到：“ 所有領域的企業都可以采用 DDD，DDD 應用最大的障礙就是去承認原先的架構并不是那么完善的 。”

另一方面，在一些特定的領域，比如需要有人參與指導、進行技術交流，以及需要大量人力協作而容易導致秩序混亂的設計工作，DDD 因為其關注業務問題域的特性，可以使得執行效果更好。

“而具體到創業公司，他們因為需要使用成本更低的方式去打入市場，所以使用 DDD 會讓這個過程更加順利。”Alberto 認為這是創業公司的切入點。

所以回過頭來看： 我們需要關注 DDD 嗎？ 不言而喻。Alberto 與王威在這個問題上都回答的特別堅定： Sure，需要！

談及如何去關注 DDD，Alberto 說他的經驗是 積極參與到本地社區中去 ，他認為這是一個很有效的方式，社區可以提供很多信息。同時他覺得看書并不是很好的方式，與其一個人看書學習，不如找一個人一起學習，確保你掌握了學到的東西。

而為 DDD 實踐者構建一個社區，讓關注 DDD 的人有一個交流平臺，也正是此次 DDD 中國峰會的價值所在，舉辦方想以此在國內第一次正式地告訴軟件設計從業者：DDD 是在我們這個業務高度不確定的時代，解決業務問題，適應業務變化時需要采用的架構思想。

 

 

來自：http://www.infoq.com/cn/articles/should-we-focus-on-ddd