本文是從 What is Domain Driven Design? 這篇文章翻譯而來。

　　”…在很多領域，專家的作用體現在他們的專業知識上而不是智力上。“

　　-- Don Reinertsen

　　領域驅動設計(Domain Driven Design)是一種軟件開發方法，目的是讓軟件系統在實現時準確的基于對真實業務過程的建模并根據真實業務過程的調整而調整。

　　傳統的開發工作趨向于一種以技術為先導的過程，需求從業務方傳遞到開發團隊，開發人員依據需求上的描述創造出最有可能的假想。

　　在瀑布開發過程中，這導致了大量的需要頻繁校對、分析、復核和審批的需求文檔。之后這些文檔被交給開發團隊去變成能夠運行的軟件。

　　敏捷開發方法同樣可以采納瀑布模式過程中產生的需求文檔，但敏捷方法在實際的處理過程中會把它們分成很小的任務和“故事”，之后的開發工作將依據這些任務的排序。

　　領域驅動設計很大程度上使你從這兩種截然不同的結果中抽身出來，讓你能看到需求是如何在第一現場被收集到——如果你愿意看的話，它在動手先做的方式和在最后一分鐘才做的方式之間做了彌補。

　　領域驅動設計方式知道需求是永遠不會“完成”的，需求就像一個活的文檔。更重要的是，這些仍待討論的活文檔實際上就是軟件自身——所有的文檔都是程序代碼的一種影像，一種演示品。

　　隨著軟件系統的開發和發展，你對各種問題的理解也會更深——領域驅動設計就是要通過深入的理解問題來找到問題的解決方案。

　　然而，領域驅動設計真正的不同之處卻是，它把軟件系統當作業務過程的一個影射，是使能動，而不是驅動。領域驅動設計是要你深入到業務過程中，了解業務術語和實踐方法。技術方面的事被放在了第二位，只是最終的一種手段而已。

　　Ubiquitous語言(UL)是領域驅動設計的中心——這是一種共有的不斷成長的語言。它是一種來源于業務術語、經過開發團隊的補充而產生的協商后的語言。如果一個業務人員不懂得UL里的一個術語，有可能是UL需要改進發展。如果一個技術人員不懂得UL里的一個術語，有可能是他們需要跟領域專家進行交流。

　　領域專家是領域驅動設計里第二重要的組成部分——這些人能夠對這個領域有深入的了解，包括這個業務本身。這些人構成了開發過程中必要的組成部分。他們也許像一些敏捷開發方法里傳統的產品擁有者那樣不需要“全天候”的在職，但他們必須在開發過程中能被持續的接觸到，而且隨時準備好參與到開發過程中。領域專家不能被當作門外人，而應被當作領域驅動設計過程中的核心——他們非常像是開發團隊中的一部分，就像普通的開發者和測試者一樣。

　　領域驅動設計沒有開始和結束——它是一個不斷的再評估，再重構，再建模，再設計的持續過程——每一次的對話都會使你對問題有更進一步的理解。領域驅動設計沒有“完成”點——它永遠都在進行；Ubiquitous語言會不斷發展和成長，領域模型隨著對業務理解的改變而改變，代碼不斷的再組織和重構來更好的表現你的理解。

　　各種模擬產物產生又拋棄，而唯一真正有意義的只有代碼。它是解決方案的唯一表達，是一種不再抽象的表達。文檔是用來解釋和描述系統的，而只有代碼能不失分毫的做到這些。這就是說，在領域驅動設計里，代碼必須保持高質量，要清晰，要有表達力，沒有技術上省略和專門用語，盡可能的要讓代碼能夠在被解釋時對領域專家有些意義。

　　領域驅動設計里沒有精巧的代碼，也沒有奇特的處理過程，或“你不需要知道”的模塊。領域專家不需要成為開發人員來理解軟件系統里用來做這些工作的關鍵部分是什么。他們同樣也不需要考慮數據庫或批處理任務或其他技術相關的方面。

　　領域驅動設計是敏捷方法的終極表達——它是用來處理不斷變化和發展的需求的——正如任何一個從未涉足軟件項目的人都知道——一個項目的需求從開始到結束保持一成不變是極其罕見的，絕大多數情況是它會隨著業務的增長和變化而變化。

　　通過不斷的交流，領域驅動設計會指導你用軟件最精確的表達你的業務過程。