寫在前面：要不要DDD

網上關於領域驅動的相關文章數不勝數，但是就跟我一個同事說的，具體落地的到底有多少呢？我們說領域驅動最核心的就是領域模型，一個穩定的領域模型勝過千軍萬馬，然而在當下依然是互聯網的時代，業務告訴發展的時期，一切的產品設計和技術都是服務於業務，然而有多少業務是隨心所欲閉門造車臨時方案的情況，我想程序員們應該是深有體會。於是帶來一個問題，業務層面如此的不固定，我們如何跟業務通過領域建模來統一語言，更別說穩定我們的領域模型了（一段時間範圍內的相對穩定）。同時在那些不懂技術的老闆眼裡，他們只關注完成系統的開發通過時間點壓榨，哪裡管你因為使用了 DDD 而帶來的開發周期和開發成本的增加，他們只會認為你技術不行，做這麼簡單的東西要那麼久。好了，吐槽到此為止！

既然沒有多少企業實際落地 DDD，那我們還需要 DDD 嗎？

我的答案：需要，我們需要一個抓手，任何新系統的開發和老系統的重構乃至系統技術應用架構或者功能架構圖，都需要一個抓手，一個切入點，一個可以撬動大家思路的武器，包括微服務的拆分，拆分的理論依據是什麼？ by experience ？出於慎重考慮我們需要一個抓手，因為 DDD 可能是一個。

​ 然而雖說眾多企業並沒有實際落地 DDD ，或許因為其書籍和資料都過於高大上，但實際上我們平時的工作中都用到了 DDD 的部分理念和方法。例如聚合，在 DDD 建模種聚合是構建領域模型的基礎。那我們在日常技術方案設計過程中多多少少都會涉及聚合，甚至我們在畫 UML 類圖的時候聚合就是六種關係的其中一種。

​ 本篇文章屬於軟實力的修鍊，而修鍊內功是程序員的基本素養。

一、 模型

領域驅動最核心的莫過於領域模型，我們先聊一聊什麼是模型？

百度百科解釋有很多解釋，我們一一理解理解。

模型是通過主觀意識藉助實體或者虛擬表現，構成客觀闡述形態結構的一種表達目的的物件（物件並不等於物體，不局限於實體與虛擬、不限於平面與立體）

從這裡的描述有幾點有必要說明，首先模型並不一定是現實世界真是存在的一個東西，其次模型的建立渠道是我們的主管意識，也就是我們的大腦經過思考形成的，但不是瞎說瞎想，有依據和道理的。當然我們也可以把客觀世界存在的事物直接定義成我們的模型，而在當今 MVC 的開發模式下，大部分公司大部分程序員都是如此做的也可能是如此想的。如果軟體開發都是如此，那麼我們確實是大家嘴裡的「農民工」。

另外我們可以得到的一個信息，模型的範圍很大很廣，甚至不限形式不限地域和空間。

模型≠商品。任何物件定義為商品之前的研發過程中形態均為模型，當定義型號、規格並匹配相應價格的時候，模型將會以商品形式呈現出來。

這句話的描述我覺得至關重要，我們可以理解模型它其實是一種過程性的產物，不是結果的呈現，模型本身還比較靠近業務或者技術化，客戶所關心的是完全商業化的呈現。

這就從另一個角度體現了建模的重要性，我們可以直接做拿來主義將一個事物直接映射成模型且一一對應，我們也需要做一些深入的思考和沉澱，好好打磨一下我們的模型。

從廣義上講：如果一件事物能隨著另一件事物的改變而改變，那麼此事物就是另一件事物的模型。模型的作用就是表達不同概念的性質，一個概念可以使很多模型發生不同程度的改變，但只要很少模型就能表達出一個概念的性質，所以一個概念可以通過參考不同的模型從而改變性質的表達形式。

廣義的定義告訴我們模型是變化的，而且不是拘泥於一種形式或者某一個單一的模型，甚至有時候非常負責的模型才能讓我們理解和明白某一個定義和概念，所以模型本身又是複雜的，而建模的過程又是非常有意思的。

當模型與事物發生聯繫時會產生一個具有性質的框架，此性質決定模型怎樣隨事物變化。

這裡引出了框架，讓我們從中聞到了一絲絲架構的氣息，這再一次說明模型是多麼的重要，並且當他和真實世界發生關聯的時候，所產生的蝴蝶效應也將預示著事物發展的過程和結局。

總結：模型是用來表達現實世界的真實或者虛擬的事物，用來表達某種概念，讓我們獲得某種認識，並在在未來事物的發展和演變過程中，我們可以通過某種框架來控制和穩定事情的發展，以防止出現我們無法控制的局面出現。

最後模型屬於數據領域，所以誰說我們小學、初中和高中學習的語數外沒有用，其實作用和用途無處不在，只是說出這種話的人們不自知。

二、領域

我們看一看什麼是領域。

其英文叫：domain

中文含義：

具體指一種特定的範圍或區域.

我們畫出重點範圍二字，也就是領域模型其實是表示某種具有範圍的概念、認識、事物。就如同我們作為技術 PM 上線某個項目一樣，一定是在一個有限的時間內，完成某個工作清單里的一個一個的任務，項目管理最重要的事情就是項目範圍。同樣在我們領域建模最重要的也是確定模型涉及的範圍。以下是其他的解釋，不過大體意思相似：

一國主權所達之地。

一種專門活動或事業的範圍、部類或部門。

學術思想或社會活動的範圍。

三、領域模型

領域驅動有幾個非常重要的概念：核心域、子域、通用域、限界上下文。

核心域：決定產品和公司核心競爭力的子域，是業務成功的主要因素和公司的核心競爭力。從這個定義中我們可以看到核心域其實就是我們當前業務最直接最忒且的內容，例如點餐的 APP ，那麼其核心域就應該是跟點菜、菜品管理、發布菜品、菜品評價、菜品訂單，那在這個 APP 里的其他功能比如用戶、庫存、配料、支付、用戶的訂單甚至賬務這些要麼通用域要麼是支撐域。

通用域：顧名思義，具有通用性，在點餐的 APP 中，用戶、庫存、配料這些就屬於通用域，被多個子域所引用。

支撐域：它是用來解決某一個業務問題，在點菜的 APP 中用戶的支付訂單、賬務、支付就是支撐域，為了解決 APP 支付相關的某一個業務問題。

限界上下文的理解非常重要，它也將確定我們領域劃分邊界。我們在弄清楚哪些是核心域、通用域、支撐域後，我們需要對產生的聚合進行分組，通過業務的內聚性和關聯度劃分邊界，結合上下文含義並給出上下文名稱。限界上下文不是跟模型一一對應，可以是多個模型組成一個限界上下文，它的作用可以明確模型有解決的問題，並保持每個模型的清晰。我們講領域的核心在於確定範圍，而限界上下文就是領域模型的邊界，也是我們對領域認知的邊界。我們常說的高內聚低耦合意思就是在某一個限界上下文內，模型之間緊密關聯，而其他模型應該在其他的領域限界上下文中。

那為什麼說限界上下文跟模型不是一對一的，可以是一對多的？

模型不是萬能的，模型存在的意義就是描述現實的真實或者虛擬事物，並一定要能夠解決現實的問題。世界也是不停變化的，事物也是發展變化的，所以現實情況的種種問題也是複雜多樣的，往往用一個或者兩個模型也無法能夠非常清晰的面面俱到的描述和解決所有問題，這個時候我們就需要把多個模型圍起來，形成一個整體來解決問題，對這個整體進行建模。

子域：可以解決某個特定的問題。

四、如何領域建模

​ 網上有各種領域模型的詳解，也有很多領域建模的方法和例子，在這裡把個人認為比較好理解，比較好實施落地的方法列舉出來。其實對於如何領域建模的方法論也不是每次都按部步驟去實現，在某些領域劃分不清或者分歧較大的時候，通過對業務流程的重塑也許就找到解決問題的鑰匙。

​ 所有的開發工作都離不開業務流程的梳理，然後將業務轉化成產品語言，技術將產品設計落地實現。所以第一步就是畫出所有的核心業務流程，任何業務也都存在一條穩定的業務流程，而業務流程中節點的產物就是我們的業務骨架。一般我們採用如下形式畫出業務流程：

​ 這裡強調的是核心業務流程，核心業務流程可以覺得我們的核心業務域，同樣也可以對我們的界限上下文的確定有一定的輔助作用。

​ 挖成第一步後，接下來就是業務子流程的再分解，一般我們會形成如下形式的圖：

​ 簡單的兩部，可以大概確定我們的領域模型有哪些，可以支撐什麼業務解決什麼問題，但是哪些是核心域、支撐域、通用域，限界上下文如何執行還需要通過抽象和分析，結合各自的作用進行細緻的劃分。

​ 有的同行甚至把領域建模的方法總結成了三字經方法：找名詞、加屬性、連關係。

五、就這麼結束了

​ 本文沒有舉真實的案例，並不是從來沒有實踐過 ，而是我亦在總結和找到個人認為比較能接手的方法論，用來知道以後遇到的一些情況，也是為了強化和修鍊內功心法，作為程序員技術不可丟，但是只有上層劍法秘籍，沒有深厚的內功方法論，如何合二為一具備持續的競爭力呢。在這個浮躁的社會，越是晦澀難懂的東西越需要靜下心來好好總結，現在網路流程叫沉浸式！

​ 在未來我還會總結一些其他方面更為晦澀難懂的理論，人們總是在找一種平衡點，理論過於深奧讀不懂，過於白話那是別人總結的精華不是自己的，最後要問自己一句：核心競爭力在哪裡！