翻遍整個互聯網，我發現，關於領域驅動設計，大家都 理解錯了 。
今天，我們嘗試透過一篇文章的篇幅，給大家展示一個完全不同的視角，把「領域驅動設計」這六個字解釋清楚。
領域驅動設計學習資料現狀
領域驅動設計的概念提出已經有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」更復雜？
基於上面的例子，我們至少可以得出兩個判斷：
系統復雜度與元素的數量和元素的關系有關；
元素的關系對系統復雜度的影響遠遠大於元素的數量所產生的影響；
回歸到領域驅動設計，為啥要劃分領域？因為「劃分領域就是在用數量簡化關系」，用明確的邊界將問題拆解，逐個擊破。其意圖是控制系統復雜度，盡可能降低系統的復雜度，而復雜度的降低，是與我們軟體工程的投入產出利益一致的。
到此，我們就形成了一個核心邏輯鏈條：「劃分領域->降低復雜度->降低成本」，因此劃分領域符合我們價值取向，我們願意認同「領域驅動設計」的價值觀。
重新審視對待「領域驅動設計」的分歧
假如你認同「領域驅動設計是一種價值觀」這樣的觀點，我們重新來回到前面說的「完全沒用，不可落地」和「軟體工程困境的解藥」這兩派觀點的分歧上，就會發現大家的分歧底層就是價值觀的分歧，一方面大家的討論維度都停留在「領域驅動設計怎麽落地」這個層面，缺少了「領域驅動設計到底是什麽」這個問題的共識；另一方面大家沒有察覺到核心分歧其實是價值觀的分歧，導致了對於「領域驅動設計」的理解和判斷過程缺乏底層認知的共識。
對於本質沒有共識，其之上的所有討論如同「空中樓閣」，缺乏嚴密邏輯鏈條的推導，那麽表達者不得不用一些抽象的概念來模糊化自己表達的東西，從而使得「領域驅動設計」這個詞變得越發抽象，越發「不明覺厲」。
後續
本文從why的角度解析了「領域驅動設計」，並未涉及到How的部份，但以我的經驗來看，理解了why，在執行How的操作時會更加地篤定和自信，更容易成功。
且聽我後續慢慢道來。
