領域驅動是一個相對抽象的概念,如果仍然從抽象的角度來解釋,可能會更不容易明白.

從多年的領域驅動實際出發, 從一些細節處出發,來講講領域驅動為什麼好,好在哪裡,是如何被總結提煉出來的.

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

三 層架構及期衍生出的多層架構是現有大部分程式設計師甚至好多工作十年以前的程式唯一使用和認可的模式。基至也是DDD實踐的最大的阻礙。因為每個在學習過程中都系統學習過三層架構， 對資料層、業務層、表現層的三者分離，有一種直覺。我並沒有說這個不好。只是偏執的理解和使用三層，很容易形成一葉障目的情況。在三層裡，我們的模型層是用來與資料庫一一對應，而這個物件的行為分佈到了業務層，有的甚至透過儲存過程放在了資料庫和資料層。

這是一個非常不好的現象，就是這裡的物件是貧血模型（只有屬性沒有行為）。另一種類，在業務層和資料層的方法同樣也是貧血模型（有隻行為沒有屬性）。這本身就是一種不好的實踐。

另外，因為所有的都變成了資料庫操作，很容易讓人產生一種慣性思維，就是業務系統就是資料庫的增刪改查，這種被很多程式認為自己看透了所謂程式的本質的人。他們在設計一個系統時，就是從資料庫開始設計，並且把所有的業務對映到資料庫的操作上去。讓程式變得僵化，也讓自己的思想變得僵化。試問如果要你開發一個影片解碼程式你怎麼開發，那要是開發一個播放器，一個BT下載端,一個數據庫,一個web伺服器,一個IM通訊你如何做? 資料庫你要怎麼設計?你要如何增刪改查.

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

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

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

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

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

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

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

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

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

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

領域驅動設計的好處

由於對業務進行了專業的領域劃分，使得業務邏輯更加清晰，正確的業務歸類有利於後續業務擴充套件。

領域物件面向物件程式設計，使得程式碼工程更加高內聚。將業務邏輯分散到各個領域物件中，使得物件外部程式碼更加精減。

解決複雜業務邏輯編寫問題。透過領域劃分，分散業務邏輯編寫，在一個領域內專注領域內業務處理。

領域驅動模式使用面向物件的模式來程式設計，使得程式碼更加語義化。

領域驅動設計模式提出已經有好多年了，為什麼沒有流行起來?

近些年已經有越來越多的公司追求領域驅動設計了。

領域驅動有一個前提，那就是專業建模。其實專案一般都做了模組劃分，這裡的劃分是一樣的意思，只是夠不夠專業而已。

現微服務化的出現，也是對業務領域劃分的一種體現。

領域驅動一個關鍵的點是model是包含行為的。這個在MVC模式中，就是service + model層兩層。

屬性和行為分離，使得可以並行開發，不會存在不同人提交相同的程式碼檔案而造成衝突。

綜上所述，領域驅動除了面向物件程式設計外，特色設計模式在MVC模式中也能看到影子。但在model面向物件程式設計不利於團隊協作開發，也不見得是個好選擇。

複雜問題簡單化，簡化單位功能，透過組合的方式來表達複雜功能。