領域驅動設計真的好嗎？

領域驅動是一個相對抽象的概念，如果仍然從抽象的角度來解釋的話可能會更讓人迷惑。

從事多年的領域驅動開發，我想從一些細節處出發，來講講領域驅動為什么好，好在哪里，是如何被總結提煉出來的。

1、傳統三層與領域驅動的區別。

傳統三層架構及其衍生出的多層架構是現有大部分程序員甚至好多工作十年以上的程序唯一使用和認可的模式。這種編程認識和習慣同時也是DDD實踐的最大的阻礙。因為每個人在學習過程中都系統學習過三層架構， 對數據層、業務層、表現層的三者分離，有一種直覺。

我并沒有說這個不好。只是偏執的理解和使用三層，很容易形成一葉障目的情況。在三層里，我們的模型層是用來與數據庫一一對應，而這個對象的行為分布到了業務層，有的甚至通過存儲過程放在了數據庫和數據層。

這是一個非常不好的現象，就是這里的對象是貧血模型（只有屬性沒有行為）。另一種類，在業務層和數據層的方法同樣也是貧血模型（只有行為沒有屬性），造成了一種認知上的局限性，本身就不符合我們對面向對象的基本認知，也必然導致有問題的調序。

另外，因為所有的都變成了數據庫操作，很容易讓人產生一種慣性思維，就是業務系統就是數據庫的增刪改查，這種被很多程序認為自己看透了所謂程序的本質的人。他們在設計一個系統時，就是從數據庫開始設計，并且把所有的業務映射到數據庫的操作上去。讓程序變得僵化，也讓自己的思想變得僵化。試問如果要你開發一個視頻解碼程序你怎么開發，那要是開發一個播放器，一個BT下載端，一個數據庫，一個web服務器，一個IM通訊你如何做，他們似乎并不是面向對數據的，那你怎么處理呢？

所以從這點上DDD提倡充血模型，把視角轉換到對具體業務的理解上，開發的程序跟現實中人的理解，跟具體的業務一一對應。比如一個老師類就是自己的姓名、年齡、所帶科目，同時有上課，教學，批改作業這樣的方法。

這是一個活生生的概念，一個充血模型。一旦邁出了這一步，你突然發現，原來你學過的UML繪圖，你學過的設計模式，全部用得上了。可謂思路一變，大路通天。

2、DDD是不斷提煉，不斷深化，不斷標準化的過程中提出來的。

以三層為例，三層為什么會被提出來，而且被廣大程序員廣泛接受，就是因為開始寫程序的時候，大家需要有一種共同認可，約定俗成的規范，這樣大家就能保證項目里參與的人寫出來的代碼更容易別其它人理解和修改。這個就是標準化的力量，當大家認可同一種模式后，就能非常和諧的協同起來。

比如在實際工作中，我不提倡大家去畫非常精準嚴格的UML圖，我們只使用里面最通俗易懂的一些圖，一些標識，一些符號來表達我們的概念。UML是幫助我們疏理思維的工具，用我們大家都能直觀認識，能快速達成統一的東西來進行處理。這個就成了我們事實上的標準，是我們在用UML，不是UML在用我們。

DDD也一樣，里面包含了很多前人總結的各種經驗。采用時從大家共同理解，容易接受的部分開始，隨著實踐的展開，會有越來越多的概念進入視野，然后一步一步的使用起來。所以我們說DDD是別人總結出來的標準，是讓大家共同認可才有價值的。從這個點上來說，對于執行DDD很到位的團隊，DDD絕對是真的好的。但是對于你完全不具備DDD的思維方式，而強行寫DDD的人是真的不好。

3、DDD并不是銀彈，你曾經解決不了的技術問題，可能同樣還是解決不了。

他只是提出了一種更接近人的思維方式的一種模式，并且抽象出了一系列的對象和工具，讓你更容易的去分解你的業務模型和概念。幫助你快速的建立領域模型和分層架構。在需求發生變化的時候，他更容易響應，因為跟業務一致，所以他也更容易開始，而不是先設計數據庫，一旦數據庫發生變更，會發生重大的修改，有些甚至是傷筋動骨的調整。當你有一點點業務概念的時候，你就可以開始寫代碼進行驗證了。可能說在大型項目里，他是有很大的用武之地的。

我認為DDD是道，三層只是術。

至于適不適合你，還取決于你是否想深入的了解和應用DDD。