大白話DDD（DDD黑話終結者）

一、吐槽的話

相信聽過DDD的人有很大一部分都不知道這玩意具體是干嘛的，甚至覺得它有那么一些虛無縹緲。原因之一是但凡講DDD的，都是一堆特別高大上的概念，然后冠之以一堆讓人看不懂的解釋，。作者曾經在極客時間上買了本DDD實戰的電子書，被那些概念一路從頭灌到尾，灌得作者頭昏腦漲，一本電子書那么多文章愣是沒有一點點像樣的案例，看到最后也沒明白那本電子書的作者究竟想寫啥。原因之二是DDD經常出現在互聯網黑話中，如果不能稍微了解一下DDD中的名詞，我們一般的程序員甚至都不配和那些說這些黑話的人一起共事。

為了幫助大家更好的理解這種虛無縹緲的概念，也為了更好的減少大家在新詞頻出的IT行業工作的痛苦，作者嘗試用人話來解釋下DDD，并且最后會舉DDD在不同層面上使用的例子，來幫助大家徹底理解這個所謂的“高大上”的概念。

二、核心概念

核心的概念還是必須列的，否則你都不知道DDD的名詞有多么惡心，但我會用讓你能聽懂的話來解釋。

1、領域/子域/核心域/支撐域/通用域

領域

DDD中最重要的一個概念，也是黑話中說的最多的，領域指的是特定的業務問題領域，是專門用來確定業務的邊界。

子域

有時候一個業務領域可能比較復雜，因此會被分為多個子域，子域分為了如下幾種:

核心子域：業務成功的核心競爭力。用人話來說，就是領域中最重要的子域，如果沒有它其他的都不成立，比如用戶服務這個領域中的用戶子域
通用子域：不是核心，但被整個業務系統所使用。在領域這個層面中，這里指的是通用能力，比如通用工具，通用的數據字典、枚舉這類（感嘆DDD簡直恨不得無孔不入）。在整個業務系統這個更高層面上，也會有通用域的存在，指的通用的服務（用戶服務、權限服務這類公共服務可以作為通用域）。
支撐子域：不是核心，不被整個系統使用，完成業務的必要能力。

2、通用語言/限界上下文

通用語言

指的是一個領域內，同一個名詞必須是同一個意思，即統一交流的術語。比如我們在搞用戶中心的時候，用戶統一指的就是系統用戶，而不能用其他名詞來表達，目的是提高溝通的效率以及增加設計的可讀性

限界上下文

限界上下文指的是領域的邊界，通常來說，在比較高的業務層面上，一個限界上下文之內即一個領域。這里用一張不太好看的圖來解釋：

3、事件風暴/頭腦風暴/領域事件

事件風暴

指的是領域內的業務事件，比如用戶中心中，新增用戶，授權，用戶修改密碼等業務事件。

頭腦風暴

用最俗的人話解釋，就是一堆人坐在一個小會議室中開會，去梳理業務系統都有哪些業務事件。

領域事件

領域內，子域和子域之間交互的事件，如用戶服務中用戶和角色交互是為用戶分配角色，或者是為角色批量綁定用戶，這里的領域事件有兩個，一個是“為用戶分配角色”,另一個是“為角色批量綁定用戶”。

4、實體/值對象

實體

這里可以理解為有著唯一標識符的東西，比如用戶實體。

值對象

實體的具體化，比如用戶實體中的張三和李四。

實體和值對象可以簡單的理解成java中類和對象，只不過這里通常需要對應數據實體。

5、聚合/聚合根

聚合

實體和實體之間需要共同協作來讓業務運轉，比如我們的授權就是給用戶分配一個角色，這里涉及到了用戶和角色兩個實體，這個聚合即是用戶和角色的關系。

聚合根

聚合根是聚合的管理者，即一個聚合中必定是有個聚合根的，通常它也是對外的接口。比如說，在給用戶分配角色這個事件中涉及兩個實體分別是用戶和角色，這時候用戶就是聚合根。而當這個業務變成給角色批量綁定用戶的時候，聚合根就變成了角色。即使沒有這樣一個名詞，我們也會有這樣一個標準，讓業務按照既定規則來運行，舉個上文中的例子，給用戶A綁定角色1，用戶為聚合根，這樣往后去查看用戶擁有的角色，也是以用戶的唯一標識來查，即訪問聚合必須通過聚合根來訪問，這個也就是聚合根的作用。

三、用途及案例

目前DDD的應用主要是在戰略階段和戰術階段，這兩個名詞也是非常的不講人話，所謂的戰略階段，其實就是前期去規劃業務如何拆分服務，服務之間如何交互。戰術階段，就是工程上的應用，用工程化做的比較好的java語言舉例子，就是把傳統的三層架構變成了四層架構甚至是N層架構而已。

1、微服務的服務領域劃分

這是對于DDD在戰略階段做的事情：假如目前我司有個客服系統，內部的客服人員使用這個系統對外上億的用戶提供了形形色色的服務，同時內部人員覺得我們的客服系統也非常好用，老板覺得我們的系統做的非常好，可以拿出去對外售賣以提高公司的利潤，那么這時候問題就來了，客服系統需要怎樣去改造，才能夠支持對外售賣呢？經過激烈的討論，大致需求如下：

對外售賣的形式有兩種，分別是SaaS模式和私有化部署的模式。
SaaS模式需要新開發較為復雜的基礎設施來支持，比如租戶管理，用戶管理，基于用戶購買的權限系統，能夠根據購買情況來給予不同租戶不同的權限。而私有化的時候，由于客戶是打包購買，這時候權限系統就不需要再根據用戶購買來判斷。
數據同步能力，很多公司原本已經有一套員工管理系統，通常是HR系統或者是ERP，這時候客服系統也有一套員工管理，需要把公司人員一個一個錄入進去，非常麻煩，因此需要和公司原有的數據來進行同步。
老板的野心還比較大，希望造出來的這套基礎設施可以為公司其他業務系統賦能，能支持其他業務系統對外售賣

在經過比較細致的梳理（DDD管這個叫事件風暴/頭腦風暴）之后，我們整理出了主要的業務事件，大致如下：

1、用戶可以自行注冊租戶，也可以由運營在后臺為用戶開通租戶，每個租戶內默認有一個超級管理員，租戶開通之后默認有系統一個月的試用期，試用期超級管理員即可在管理端進行用戶管理，添加子用戶，分配一些基本權限，同時子用戶可以使用系統的一些基本功能。

2、高級的功能，比如客服中的機器人功能是屬于要花錢買的，試用期不具備此權限，用戶必須出錢購買。每次購買之后會生成購買訂單，訂單對應的商品即為高級功能包。

3、權限系統需要能夠根據租戶購買的功能以及用戶擁有的角色來鑒權，如果是私有化，由于客戶此時購買的是完整系統，所以此時權限系統僅僅根據用戶角色來鑒權即可。

4、基礎設施還需要對其他業務系統賦能。

根據上面的業務流程，我們梳理出了下圖中的實體

最后再根據實體和實體之間的交互，劃分出了用戶中心服務以及計費服務，這兩個服務是兩個通用能力服務，然后又劃分出了基于通用服務的業務層，分別是租戶管理端和運營后臺以及提供給業務接入的應用中心，架構圖如下：

基礎設施層即為我們要做的東西，為業務應用層提供通用的用戶權限能力、以及售賣的能力，同時構建開發者中心、租戶控制臺以及運營后臺三個基礎設施應用。

2、工程層面

這個是對于DDD在戰術設計階段的運用，以java項目來舉例子，現在的搞微服務的，都是把工程分為了主要的三層，即控制層->邏輯層->數據層，但是到了DDD這里，則是多了一層，變成了控制層->邏輯層->領域能力層->數據層。這里一層一層來解釋下：

四、總結

在解釋完了各種概念以及舉例子之后，我們對DDD是什么有了個大概的認知，相信也是有非常多的爭議。作者搞微服務已經搞了多年，也曾經在梳理業務的時候被DDD的各種黑話毒打過，也使用過DDD搞過工程。經歷了這么多這方面的實踐之后覺得DDD最大的價值其實還是在梳理業務的時候劃分清楚業務領域的邊界，其核心思想其實還是高內聚低耦合而已。至于工程方面，現在微服務的粒度已經足夠細，完全沒必要再多這么一層。這多出來的這一層，多少有種沒事找事的感覺。更可笑的是，這個概念本身在對外普及自己的東西的時候，玩足了文字游戲，讓大家學的一頭霧水。真正好的東西，是能夠解決問題，并且能夠很容易的讓人學明白，而不是一昧的造新詞去迷惑人，也希望以后互聯網行業多一些實干，少說一些黑話。