我能DDD嗎？

你是可以實施DDD的，如果你：

? 有開發卓越軟件的激情和毅力

? 渴望學習和進步

? 有能力理解軟件模式，并懂得如何應用這些模式

? 有發掘不同設計方法的能力和耐性

? 勇于改變現狀

? 看重細節，希望親自試驗

? 希望編寫更好的代碼

DDD不是沒有學習曲線，而且學習曲線有可能很陡。不用著急，本書將盡可能地為你降低學習曲線，我的目的就是挖掘你成功的潛能，幫助你和你的團隊實現DDD。

DDD首先并不是關于技術的，而是關于討論、聆聽、理解、發現和業務價值的，而這些都是為了將知識集中起來。如果你了解公司的業務，那么你至少可以為DDD的通用語言（Ubiquitous Language）做出貢獻。當然，你可能需要學習更多的業務知識。由于你對業務概念的理解，你已經開始走在DDD的康莊大道上了。

多年的軟件開發經驗能夠幫助我更好地實現DDD嗎？可能會。然而，你的開發經驗并沒有教給你向領域專家聆聽和學習的能力。在實施DDD的過程中，你最好將那些不怎么使用技術語言的人加進自己的團隊，此時你得仔細地聆聽他們，還應該尊重他們的觀點，并且相信他們比你了解得更多。

將領域專家引入到團隊是大有好處的。

在實施DDD的過程中，你最好將那些不怎么使用技術語言的人加進自己的團隊。就像你會向他們學習一樣，他們也會向你學習。

可能你最希望看到的便是：領域專家同樣得聽你的。大家都是同一個團隊的成員。領域專家不見得就知道所有的業務，他們也得學習。就像你會向他們學習一樣，他們也會向你學習。你向領域專家提出的問題有可能暴露出他們不知道的地方。你將直接幫組團隊更好地理解業務，甚至確定業務。

這樣一來，團隊中的所有成員都在學習和成長——是DDD使之成為了可能。

但是，我們還沒有領域專家

領域專家并不是一個職位，他可以是精通業務的任何人。他們可能了解更多的關于業務領域的背景知識，他們可能是軟件產品的設計者，甚至有可能是銷售員。

如果你發現有人比你更加了解業務知識，找到他們，聆聽他們，并向他們學習。

現在，我們已經開了一個好頭。我并不是說技術不重要，而是說在本書中你得掌握領域建模中更高層次的概念。如果你的能力能夠位于理解《Head First設計模式》[Freeman et al]和《設計模式》[Gamma et al]之間，或者你還學了一些更高級的模式，那么你已經具備很好的DDD基礎了。在本書中，我將盡量顧及到各個層次的學習者。

什么是領域模型？

領域模型是關于某個特定業務領域的軟件模型。通常，領域模型通過對象模型來實現，這些對象同時包含了數據和行為，并且表達了準確的業務含義。

不同角色的人都可以從DDD中獲益，看看自己屬于以下角色的哪一種：

? 新手，初級開發者：“我還年輕，有很多點子，對寫代碼充滿了熱情。但是我所在的那個項目簡直讓人崩潰，我才不想一畢業就被那些重復性的工作糾來纏去。這個項目的架構為什么如此復雜？這到底是怎么呢？我修改了一點代碼，卻破壞了更多的代碼。有人知道這本來應該是什么樣子嗎？現在，我還得添加一些復雜的新特性。我在遺留代碼之上添加了一個適配器來屏蔽那些難看的遺留代碼，但是沒有用。我相信除了整天寫代碼和調試外，還有更好的辦法。于是有人向我介紹DDD，聽說DDD是領域模型中的‘四人幫（Gang of Four）’，不錯不錯。”

? 中級開發者：“在過去的幾個月中，我加入了一個新的項目，這次輪到我來做出改變了。那時，當我和高級開發人員在一起工作時，我發現我缺少對事物的洞察力。有時團隊非常渙散，但是我又不知道其中的原因，我決定改變團隊成員們的做事方式。我需要一種能夠助我成功的軟件開發技術。一個高級架構師向我推薦DDD，我打算了解了解。

聽起來你已經是個高級開發者了，繼續往下讀。你超前思考的態度自然會得到回報的。

? 高級開發者，架構師：“我曾在多個項目中都使用過DDD，不過目前所在項目還未使用。我喜歡DDD戰術模式的威力，但是我還打算應用更多的DDD模式，比如戰略設計等。在閱讀[Evans]時，我發現通用語言的功能非常強大。我已經與團隊成員和管理層討論過采用DDD的事情了，但其中有些中高級開發者對DDD在項目中的前景并不看好，而管理層也不是那么熱衷于DDD。我是最近才加入公司的，雖然我是團隊帶頭人，但是整個團隊似乎并不愿意被一些新奇玩意兒打斷了開發進度。不管如何，我是不會放棄的。雖然其他開發者對DDD沒有信心，但是我是能做到的。我決定將領域專家引入到團隊中來，使他們跟技術人員一起工作。”

這就是一個領導應該做的。本書包含了很多關于戰略設計的例子。

? 領域專家：“我已經在IT部門幫他們解決業務問題好長一段時間了，我希望開發者們能夠更好地理解他們所做的事情。他們總是認為我們業務人員是愚蠢的。但是他們不知道的是，如果不是我們，他們早就丟了工作。開發者總會以一些奇怪的方式來討論我們的軟件，如果我說這是A，他們卻說這是B，好像我們需要有本詞典才能交流一樣。如果我們試圖糾正他們的錯誤叫法，他們就不愿意合作了。我們在這上面浪費了太多的時間。軟件為什么不能像真正的業務專家所想象的那樣工作呢？”你說對了。軟件開發的最大問題之一便是業務人員和技術人員需要某種翻譯才能交流。本章將對此做出討論。你將看到，DDD將業務人員和技術人員放在同一個層面上。驚訝吧，你已經使一些開發者向你靠近了，多幫幫他們。

? 項目經理：“我們要交付軟件，但結果并不總是讓人舒心，有時開發時間拖得太長了。開發者在談論到領域時總是各執一詞，莫衷一是。我不確定我們是否需要另一種銀彈般的技術或者方法。之前我們不是沒有嘗試過，但是每次都失敗了，結果還是得回到原來的位置。我總是說，我們應該放棄幻想，準備戰斗，但是團隊成員并不這么認為。他們工作非常努力，我總覺得欠他們些什么，于是聽聽他們的意見吧。他們都是聰明之人，并且都希望做出些改變。對于我來說，如果我上面的管理層同意，我是完全允許開發者們花

時間學習的。團隊成員們希望有個集中化的業務知識體系，我想我可以以此說服我的老板。這樣一來，我自己的工作也將變得簡單，我還可以促進團隊和業務專家之間的合作與互信。”

多好的項目經理啊！

不管你是誰，有一點是重要的：要在DDD之路上取得成功，你肯定得學習，并且大量地學習。學習不是什么問題，你是聰明的，并且一直都在學習。然而，我們都面臨這樣一種困境：

就個人來講，我時刻都在準備著學習，但是我并不喜歡被人教。

——Winston Churchill

在本書中，我會盡量將知識傳遞變成一件愉悅之事，并且保證你在DDD上有所收獲。

你可能又有問題了：“為什么我們需要DDD呢？”