領域驅動設計，為何死灰復燃？

作者簡介

張逸，曾先後就職於中興通訊、惠普 GDCC、中軟國際、ThoughtWorks 等大型中外企業，任職角色為高級軟體工程師、架構師、技術總監、首席諮詢師。

一、領域驅動設計為何又

死灰復燃

煥發青春？

領域驅動設計（Domain Driven Design，DDD）確實已不再青春，從 Eric Evans 出版了劃時代的著作《領域驅動設計》至今，已有將近十五年的時間，在軟體設計領域中，似乎可以稱得上是步入老年時代了。

可惜的是，對於這樣一個在國外 IT 圈享有盛譽並行之有效的設計方法學，國內大多數的技術人員卻並不了解，也未曾運用到項目實踐中，真可以說是知音稀少。

DDD 似乎成了一門悄悄發展的隱學，它從來不曾大行其道，卻依舊頑強地發揮著出人意料的價值。

直到行業內吹起微服務的熱風，人們似乎才重新發現了領域驅動設計的價值，並不是微服務拯救了領域驅動設計，是因為領域驅動設計一直在堅硬的生長，然而看起來，確乎因為微服務，領域驅動設計才又煥發了青春。

我從 2006 年開始接觸領域驅動設計，一開始我就發現了它的魅力並沉迷其間。從閱讀 Eric Evans 的《領域驅動設計》入門，然後嘗試在軟體項目中運用它，也取得了一定成效。

然而，我的學習與運用一直處於摸索之中，始終感覺不得其門而入，直到有機會拜讀 Vaughn Vernon 出版的《實現領域驅動設計》一書，並負責該書的審校工作，我才觸摸到了領域驅動從戰略設計到戰術設計的整體脈絡，並了解其本質：

領域驅動設計是一個開放的設計方法體系

。

即使如此，許多困惑與謎題仍然等待我去發現線索和答案。

設計總是如此，雖然前人已經總結了許多原則與方法，卻不能像數學計算那樣，按照公式與公理進行推導就一定能得到準確無誤的結果。設計沒有唯一的真相。

二、為什麼要學習領域驅動設計？

如果你已經能設計出美麗優良的軟體架構，如果你只希望腳踏實地做一名高效編碼的程序員，如果你是一位注重用戶體驗的前端設計人員，如果你負責的軟體系統並不複雜，那麼，你確實不需要學習領域驅動設計！

領域驅動設計當然並非「銀彈」，自然也不是解決所有疑難雜症的「靈丹妙藥」，請事先降低對領域驅動設計的不合現實的期望。

我以中肯地態度總結了領域驅動設計可能會給你帶來的收穫：

• 
  

  領域驅動設計是一套完整而系統的設計方法，它能帶給你從戰略設計到戰術設計的規範過程，使得你的設計思路能夠更加清晰，設計過程更加規範。



• 
  

  領域驅動設計尤其善於處理與領域相關的高複雜度業務的產品研發，通過它可以為你的產品建立一個核心而穩定的領域模型內核，有利於領域知識的傳遞與傳承。



• 
  

  領域驅動設計強調團隊與領域專家的合作，能夠幫助團隊建立一個溝通良好的團隊組織，構建一致的架構體系。



• 
  

  領域驅動設計強調對架構與模型的精心打磨，尤其善於處理系統架構的演進設計。



• 
  

  領域驅動設計的思想、原則與模式有助於提高團隊成員的面向對象設計能力與架構設計能力。



• 
  

  領域驅動設計與微服務架構天生匹配，無論是在新項目中設計微服務架構，還是將系統從單體架構演進到微服務設計，都可以遵循領域驅動設計的架構原則。

三、學習領域驅動設計的秘訣

沒有誰能夠做到領域驅動設計的一蹴而就，一門課程也不可能窮盡領域驅動設計的方方面面，從知識的學習到知識的掌握，進而達到能力的提升，需要一個漫長的過程。

所謂「理論聯繫實際」雖然是一句耳熟能詳的老話，但其中蘊含了顛撲不破的真理。

我在進行領域驅動設計培訓時，總會有學員希望我能給出數學公式般的設計準則或規範，似乎軟體設計就像拼積木一般，只要遵照圖示中給出的拼搭過程，不經思考就能拼出期待的模型。——這是不切實際的幻想。

要掌握領域驅動設計，就不要被它給出的概念所迷惑，而要去思索這些概念背後蘊含的原理，多問一些為什麼。同時，要學會運用設計原則去解決問題，而非所謂的「設計規範」。例如：

• 
  

  思考限界上下文邊界的劃分，實際上還是「高內聚、低耦合」原則的體現，只是我們需要考慮什麼內容才是高內聚的，如何抽象才能做到低耦合？



• 
  

  是否需要提取單獨的限界上下文？是為了考慮職責的重用，還是為了它能夠獨立進化以應對未來的變化？



• 
  

  在分層架構中，各層之間該如何協作？如果出現了依賴，該如何解耦？仍然需要從重用與變化的角度去思考設計決策。



• 
  

  為什麼同樣遵循領域驅動設計，不同的系統會設計出不同的架構？這是因為不同的場景對架構質量的要求並不一樣，我們要學會對架構的關注點做優先順序排列，從而得出不同的架構決策。

我強烈建議讀者諸君要

學會對設計的本質思考，不要只限於對設計概念的掌握，而要追求對設計原則與方法的融匯貫通

只有如此，才能針對不同的業務場景靈活地運用領域驅動設計，而非像一個牽線木偶般遵照著僵硬的過程進行死板地設計。

四、首個全面講解 DDD 的原創課程

國內關於領域驅動設計（Domain Driven Design，DDD）的原創書籍少之又少，甚至可以說沒有，我結合了十餘年實踐領域驅動設計的經驗與心得，並糅合了 DDD 社區最新發展的理論知識與最佳實踐，策划了《領域驅動設計實踐》系列課程。

本系列課程拆分為兩個課程，即《領域驅動戰略設計實踐》和《領域驅動戰術設計實踐》，分別對應領域驅動設計的戰略設計階段與戰術設計階段。

本課程是《領域驅動設計實踐》系列課程的第一個課程，其全面覆蓋了領域建模分析與架構設計的戰略設計過程。

從剖析軟體複雜度的根源開始，引入了領域場景分析與敏捷項目實踐，幫助需求分析人員與軟體設計人員分析軟體系統的問題域、提煉真實表達的領域知識、最終建立系統的統一語言。

本課程將主流架構設計思想、微服務架構設計原則與領域驅動設計中屬於戰略設計層面的限界上下文、上下文映射、分層架構結合起來，完成從需求到架構設計再到構建代碼模型的架構全過程。

此外，本課程內容的每一個知識點都會結合項目實踐案例來講解，力求內容的深入淺出，並在講解過程中介紹了諸多架構設計原則與模式，豐富了知識內涵，但又不僅只限於對領域驅動設計的覆蓋。同時，本課程也可以作為軟體架構設計的參考書。

為了讓讀者更容易掌握整個戰略設計的全過程，最後還給出了一個真實的完整案例：EAS 系統，結合該案例來講解如何在項目實踐中進行領域建模分析、識別限界上下文，並最終構建整個系統的架構。

訂購本課程可獲得專屬海報，分享專屬海報每成功邀請一位好友購買，即可獲得 25% 的返現獎勵，多邀多得，上不封頂，立即提現。

五、送給所有喜歡 DDD 讀者的肺腑之言

如果我們能夠走在邁向唯一真相的正確道路上，那麼每前進一步，就會離這個理想的唯一真相更近一步，這正是我推出這門課的初衷。

也並不是說我貼近了唯一真相，更不是說我已經走在了正確道路上，但我可以自信地說，對於領域驅動設計，我走在了大多數開發人員的前面，在我發現了更多新奇風景的同時，亦走過太多荒蕪的分岔小徑，經歷過太多坎坷與陷阱。

我嘗試著解答領域驅動設計的諸多謎題，期望能從我的思考與實踐中發現正確道路的蛛絲馬跡。

我寫的這門課程正是我跌跌撞撞走過一路的風景拍攝與路徑引導，就好似

你要去銀河系旅遊，最好能有一本《銀河系漫遊指南》在手一樣，不至於迷失在浩瀚的星空之中，我期待這門課程能給你帶來這樣的指導。加油！

如果你對學習本課程有任何疑問，歡迎通過 GitChat 的讀者圈功能與我交流互動，我會極可能及時回答每個人的問題。

張逸 · 架構編碼實踐者

專家推薦

張逸不但擁有過硬的領域驅動設計實踐經驗，而且是一位能夠深入淺出的闡釋者。這兩項特質保證大家能夠收穫滿滿！

——ThoughtWorks 

諮詢總監、精益敏捷專家，肖然

我做了多年大規模微服務架構，也見了許多微服務實施案例，其中做得好的無一例外對領域模型有了深入的分析，做得不好的往往只關注工具和框架而忽略了領域模型。張逸是國內 DDD 領域少有的專家，我向大家推薦他的《領域驅動設計實踐》系列課程。

——阿里巴巴高級技術專家，許曉斌

國內同仁寫的軟體需求設計方面的圖書，我都有收集，但能認真閱讀的不多。張逸寫的書是少數我認真閱讀過的，推薦給大家。

——UMLChina 首席專家，潘加宇

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！