領域驅動設計（DDD）高手養成記

開發出一款基於業務的高質量軟體產品，一直是架構師與軟體開發工程師為之努力的目標，之所以說是努力的目標，是因為這其中存在眾多的難題。

開發出一款基於業務的高質量軟體產品，一直是架構師與軟體開發工程師為之努力的目標，之所以說是努力的目標，是因為這其中存在眾多的難題。

比如：如何將業務需求準確的轉化為軟體設計?如何能讓團隊人員在開發時能專註於業務，而不是技術本身?如何解決跨部門間語言溝通問題，如開發與業務之間的溝通障礙?如何解決軟體系統不會隨著時間推移而慢慢腐爛的問題等等……

為了解決這一系列的問題，15年前，Eric Evans提出了一個行之有效的方法論，即領域驅動設計(Domain Driven Design，簡稱DDD)，Eric Evans也因此享譽全球的IT圈。

略微讓人遺憾的是，對於DDD，國內了解的人卻並不多，我們也甚少聽聞，業界有宣稱應用了DDD原則的項目和軟體。

沒有掌握DDD的人，抱怨這一技術過於晦澀、在現實中根本無處著手。而掌握了它的人卻覺得沒那麼難，不過是一種很自然的設計方法選擇。

DDD對架構師和軟體開發工程師意味著什麼?對企業又意味著什麼?我們應該如何正確的理解DDD並落地使用它?DDD高手是如何養成的?

近日，由ThoughtWorks發起的第二屆領域驅動設計中國峰會(2018 DDD China Conference)在北京召開，筆者有幸採訪到2位DDD的實踐型專家，他們分別是民航信息技術總監，領域驅動設計中國峰會話題出品?張逸，ThoughtWorks高級諮詢師，周宇剛。一起來看他們的經驗之談。

如何學習並使用DDD?

對於98年大學畢業的張逸來說，2006年的他，已經是一名有著豐富編程經驗的老程序員了，就在那年，他通過Eric Evans的《領域驅動設計》一書，第一次接觸到DDD。

「那個時候，學習DDD主要靠看書，外加自己琢磨，因為，沒有人教，也沒有氛圍。」張逸說。

與此同時，他也開始在工作中逐漸嘗試使用DDD，因為Eric一書晦澀難懂，並不好理解，因此，在實踐的過程中，很多時候他都是一知半解的在做，就這樣持續不斷的實踐了10多年。

「類似航延結算、協同決策等偏業務的系統，我們就會嘗試採用DDD去改進系統架構，改進代碼質量，但過程並不是那麼順利，走的磕磕絆絆的。有時間周期問題，還有團隊成員能力問題。」 張逸說。

如今回過頭來再看，一個項目，純粹按DDD的方式去做的比較少，很多項目因為歷史遺留問題，再加上團隊在DDD理解上的一些分歧，導致很難有項目完全按照DDD去做，但會引入一些DDD思想。當找不到答案時，其實還是從設計的本質去看，甭管是否符合Eric Evans書中所介紹的東西。

周宇剛接觸DDD的時間是 2009，比張逸略晚，很難想像他是一個做過導遊的程序員，周宇剛學習DDD的原因是在日常編程工作中遇到很多挑戰，比如，一個預訂流程，面向對象應該如何去做?對象是什麼?怎麼協作?

直到有一次，無意中看到了Eric的書，僅看到戰術設計的前半部分，就讓他如獲至寶。為了進一步學習DDD，他還特意去國外網站Stack Overflow上註冊了個賬號，就是為了去看看別人是如何學的。其實，跑到國外網站去看也是無奈之舉，因為搜遍了國內網站，發現根本沒人在聊DDD。

事實上，書的後半部分戰略設計甚至還沒來得及看，他就已經等不及了，要在自己項目中去實踐。

作為Team Leader，他工作中有較大的自主權，所以，比較容易的就在自己項目中開始嘗試，但過程是曲折的。「因為最初並不知道DDD到底是什麼?一邊要嘗試去理解它，一邊又要在自己項目中去實踐」，周宇剛說。

當書上的知識或別人的案例跟實際項目不是特別契合時，在實踐的過程中應該怎麼去積累自己的經驗呢?周宇剛認為，要跳出這個領域去設計，因為，我們追求的不是用不用DDD，而是用了DDD能達到什麼效果。

如何正確理解DDD?

為什麼很多人會覺得DDD很難學?因為，它就是一個思想，一個方法。周宇剛說。

開始，你以為DDD是一個面向對象的建模方法，能告訴你企業應用架構該怎麼做，慢慢的，你又會發現，它告訴你的是怎麼識別問題，如企業應用中的問題，業務領域的問題，哪些應該拆開處理……

事實上，DDD最初是一個綜合軟體系統分析和設計的面向對象建模方法，如今已經發展為一種針對大型複雜系統的領域建模與分析方法。

張逸認為，要了解DDD，首先得弄清楚它的歷史背景與來龍去脈。

雖然，從Eric Evans出版那本劃時代的著作《領域驅動設計》至今，已有差不多十五年時間,DDD也發生了一些變化，但Eric Evans為什麼要提出DDD?這是學習DDD需要去了解的。

2004年，Eric Evans提出DDD，剛好是面向對象設計大為流行之時，UML也是甚囂塵上，但是，這個時間節點上，軟體設計還有一個致命的問題，軟體系統開發還是從資料庫角度去進行。當然，這裡面涉及多種原因的，也是需要了解的。

原因一、當時的軟體系統開發，並沒有現在的多樣性，系統操作的源頭還是操作資料庫，只是簡單與複雜的區別。

原因二、軟體行業本身很像是一個軟體作坊，依靠的是老代新的傳承方式。而老人最早接觸到的就是面向資料庫的設計，所以，雖然已經有面向對象，但開發者的開發工作仍然是基於資料庫驅動。

因此，Eric Evans的書中就特彆強調，如果採用面向資料庫設計的思維去建模，很難去享受DDD帶來的好處。張逸認為，要正確理解DDD的最關鍵的一點，是理解Domain Driven，並由此角度去驅動它，而這需要保證兩點：

一、在設計時，壓根就不要去考慮技術實現，只考慮業務，只考慮domain。

二、DDD不純粹是一個軟體開發方法，強調Domain，強調領域就要有溝通，一定要有協作，很多人之所以做DDD比較困難，甚至於做的不好，就是沒有業務人員參與，基於業務的溝通機制是DDD最核心的。

DDD對企業、對架構師和軟體開發工程師意味著什麼?

在周宇剛和張逸看來，DDD對企業有2個方面的價值，一是能幫助企業識別自身核心領域，決定企業資源的運用。二是能幫助企業優化團隊組織結構與文化。

周宇剛說，從價值導向看，DDD對於企業而言，是一種策略，能幫助企業識別自身核心領域，決定了企業資源怎樣去運用，來支撐核心競爭力。比如核心領域，需要花大精力去做，非核心領域，可以採用更簡單、更快速的方式去做，甚至直接採購成熟的軟體套件。

而張逸則就DDD對團隊組織結構和文化的價值進行了闡述，他表示，很多時候並不是技術上的問題，而是團隊組織結構和文化方面的問題。當然這不純粹是DDD能推動的，還可以通過敏捷或者精益的方式。

對架構師而言，DDD對架構師落地戰略設計是會有幫助的，周宇剛說。因為，DDD解決跨部門間語言溝通問題，在業務、產品、開發之間建立領域通用語言以提高溝通效率。而對於開發者，DDD的作用更實際，能幫助開發者正確地開發所負責項目的代碼。

張逸認為，對架構師而言，DDD能幫助架構師確認系統、領域邊界，邊界確認好，即使裡邊有問題，只要邊界是穩定的，那麼，系統就不會受到太大影響。

邊界控制好，整體架構就會很清晰，把控也會更直觀，這樣的架構就不容易腐爛，現在的軟體系統最大的問題，是隨著時間推移它就會慢慢腐爛。而且把邊界控制好，代碼落到實現層面上也就相對容易。

對於開發者，張逸認為DDD主要有兩個層麵價值：

一、能夠幫助開發者補充知識，不想當架構師的開發者不是一個好的開發者，開發者不能只滿足於架構師分配的一畝三分地，也必須了解DDD知識。開發者如果只知道架構師要幹嘛，卻不知道架構師為什麼要這麼干，是很難提高的，這也不利於開發者去實現出來。

二、一體化的知識結構，從DDD落地上說，因為DDD更偏向於業務，更希望從業務的角度去看，所以，DDD能更好地和開發者所掌握的一些最基本設計原則匹配起來。

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