翻遍整個網際網路，我發現，關於領域驅動設計，大家都**理解錯了**。
今天，我們嘗試透過一篇文章的篇幅，給大家展示一個完全不同的視角，把“領域驅動設計”這六個字解釋清楚。
## 領域驅動設計學習資料現狀
領域驅動設計的概念提出已經有20年的時間了，整個網際網路充斥著大量書籍、文章和影片教程，這裡我列舉幾本比較著名的優秀書籍：
- 領域驅動設計之父 Eric Evans《領域驅動設計-軟體核心複雜性應對之道》
- Vaughn Vernon的《實現領域驅動設計》
- 張逸老師的《解構領域驅動設計》
首先不可否認，這些書籍都是優秀的作品，也被業界奉為寶典級別的作品，網上大部分資料的核心內容也都是類似的，但我相信，大部分人讀這些資料的感受是：
- 晦澀難懂
- 不明覺厲
## 為什麼會雲裡霧裡不明覺厲？
首先，我先列舉出了大部分文章提到的概念名詞：
- 問題空間（problem space）
- 解決方案空間（Solution Space）
- 領域（Domain）
- 限界上下文（Bounded Context）
- 通用語言（Ubiquitous Language）
- 實體（Entity）
- 值物件（Value Object）
- 聚合（Aggregate）
- 倉儲（Repository）
- 工廠（Factory）
- 領域服務（Domain Service）
- 領域事件（Domain Event）
目前主流的領域驅動設計資料（書籍、文章、課程），都在嘗試將這些概念給讀者講明白，都在嘗試解釋這樣的方法是好的方法，但很顯然都沒有站在一個不懂領域驅動設計的開發者角度來講解，要理解這些資料所講述的觀點，是需要先理解“領域驅動設計”，然後才能看得懂，甚至出現領域建模需要“憑經驗”這樣的說法。
所以說目前大部分的資料，懂領域驅動設計的人才能看懂，而懂的人，又不需要透過這些資料獲取養分，這就變成了一部分人的自娛自樂。
由於大部分人在瞭解領域驅動設計的過程中，更多的感受是“晦澀難懂”、“不明覺厲”，導致整個軟體行業對它產生了兩級分化的評價，一部分人認為領域驅動設計完全沒用，不可落地，一部分人卻認為這是軟體工程困境的解藥，而且處於這兩極的開發者，不僅觀點無法調和，甚至在辯論過程中，也是驢唇不對馬嘴，完全無法在一個頻道上溝通和交換觀點。
## 領域驅動設計到底是什麼？
【影片】[全網第二個把 DDD 說明白的影片](https://www.bilibili.com/video/BV1AZ421M7zw)
先說觀點：**領域驅動設計** **是一種價值觀**。
領域驅動設計不是方法論，不是軟體設計時的思想指導，不是程式碼組織的靈丹妙藥，它本質上是一種價值觀，是你做一個決策時的價值取向。
接下來，咱們把“領域驅動設計”這六個字拆解出來分析。
首先什麼是“領域”？英文原詞就是“Domain”，這個詞並不抽象，就是其直接的含義，就是邊界、範圍的意思。比如一個籃球場的範圍，一個國家的領土範圍，一個公司前臺的工作職責範圍，又或者是一個軟體系統提供的功能的範圍。
然後是“驅動”，怎麼理解呢？我們看看下面幾句話：
- 賺錢驅動工作
- 慾望驅動求偶
- 領域驅動設計
這三句話的句式是類似的，解讀起來就是：工作的目的是賺錢，所以賺錢這個目的驅使我們工作，我們世俗的慾望驅使我們求偶，那麼識別（問題、解決方案）的範圍/邊界這個目標驅使我們進行分析和設計行為。所以“驅動”的意思是為了xx的目標而做yy。
最後是“設計”就是指我們分析需求、設計模型、組織程式碼的行為。
到這裡，“領域驅動設計”這個詞表的的意思，就是我們做軟體設計的核心驅動力，就是識別各種各樣的範圍和邊界。如果你認同這個觀點，就意味著你認為“識別領域”是軟體設計的核心目標，是軟體設計最重要的事情。
什麼是最重要的事？就是你的價值取向，就是價值觀。而價值觀又恰恰是人們做各種決策的底層因素。
這裡舉個例子，有的人出門喜歡叫車，圖方便，方便就是ta看重的價值，有的人出門喜歡腳踏車，可以鍛鍊，鍛鍊就是ta看重的價值，看重不同的價值，在做“選擇交通工具”這個決策時，起了決定性作用，最終做出的決定也是不同的。
因此，我們認為價值觀決定了做決策時看重什麼，而“領域驅動設計”的價值觀，就是識別領域是最重要的事，我在分析業務、建模過程中，一定要識別出範圍和邊界，不識別出來我就不舒服。
當然也有很多與“領域驅動設計”不一致的價值觀，比如為了趕工期，“這塊沒搞清楚，先湊合一下，以後再說”，也是一種常見的軟體設計價值觀的體現，這是“工期大於一切”的價值觀。
當然，很多人會說把需求完全分析清楚也是不現實的，誠然這個是沒錯的，因此“領域驅動設計”追求的領域的“明確性”，而不是“正確性”，只要我們在做決策的時候，明確哪部分範圍是確定性的，哪部分範圍是模糊的，模糊的部分當下被我們明確地劃分到了哪個部分範圍內。畢竟老闆、產品經理、研發都是在有限地資訊下做決策，不可能全知全能，一定有一部分地決策是做一定地預判，只要我們明確地知道不明確的部分處於怎樣地範圍即可，未來隨著資訊的越來越充分，不斷修正我們對領域劃分的決策即可。
## 為什麼這個價值觀符合軟體設計的價值利益
【影片】[為什麼 DDD 符合軟體設計的價值利益](https://www.bilibili.com/video/BV19b421H7wc/)
首先，先來思考一個經典問題：“把大象放進冰箱，一共需要幾步？”
第一步，開啟冰箱門；第二步，把大象放進去；第三步，關上冰箱門。
我們在解決任何問題的時候，都會遵循一個模式：“大問題拆成小問題”。
而這個模式等價於：“複雜問題變為簡單問題”。
那麼最關鍵的問題來了，如何衡量“複雜”和“簡單”？我們來看幾個例子，下面兩個系統，你覺得哪個更復雜？你一定會選“系統2”，因為顯然它的元素數量更多。
下面兩個系統呢？是不是感覺“系統3”更復雜？
基於上面的例子，我們至少可以得出兩個判斷：
1. 系統複雜度與元素的數量和元素的關係有關；
1. 元素的關係對系統複雜度的影響遠遠大於元素的數量所產生的影響；
迴歸到領域驅動設計，為啥要劃分領域？因為“劃分領域就是在用數量簡化關係”，用明確的邊界將問題拆解，逐個擊破。其意圖是控制系統複雜度，儘可能降低系統的複雜度，而複雜度的降低，是與我們軟體工程的投入產出利益一致的。
到此，我們就形成了一個核心邏輯鏈條：“劃分領域->降低複雜度->降低成本”，因此劃分領域符合我們價值取向，我們願意認同“領域驅動設計”的價值觀。
## 重新審視對待“領域驅動設計”的分歧
假如你認同“領域驅動設計是一種價值觀”這樣的觀點，我們重新來回到前面說的“完全沒用，不可落地”和“軟體工程困境的解藥”這兩派觀點的分歧上，就會發現大家的分歧底層就是價值觀的分歧，一方面大家的討論維度都停留在“領域驅動設計怎麼落地”這個層面，缺少了“領域驅動設計到底是什麼”這個問題的共識；另一方面大家沒有察覺到核心分歧其實是價值觀的分歧，導致了對於“領域驅動設計”的理解和判斷過程缺乏底層認知的共識。
對於本質沒有共識，其之上的所有討論如同“空中樓閣”，缺乏嚴密邏輯鏈條的推導，那麼表達者不得不用一些抽象的概念來模糊化自己表達的東西，從而使得“領域驅動設計”這個詞變得越發抽象，越發“不明覺厲”。
## 後續
本文從why的角度解析了“領域驅動設計”，並未涉及到How的部分，但以我的經驗來看，理解了why，在執行How的操作時會更加地篤定和自信，更容易成功。
且聽我後續慢慢道來。