前言

正如領(lǐng)域驅(qū)動設(shè)計之父 Eric Evans 所著一書的書名所述，領(lǐng)域驅(qū)動設(shè)計（Domain Driven Design）是一種軟件核心復(fù)雜性應(yīng)對之道。

在我們解決現(xiàn)實業(yè)務(wù)問題時，會面對非常復(fù)雜的業(yè)務(wù)邏輯。即使是同一個事物，在多個子業(yè)務(wù)單元下代表的意思也是不完全一樣的。比如「商品」這個詞，在商品詳情頁語境中，是指「商品基本信息」；在下單頁語境中，是指「購買項」；而在物流頁面語境中，又變成了「被運(yùn)送的貨物」。

DDD 的核心思想就是讓正確的領(lǐng)域模型發(fā)揮作用。所謂「術(shù)業(yè)有專攻」，DDD 指導(dǎo)軟件開發(fā)人員將不同的子業(yè)務(wù)單元劃分為不同的子領(lǐng)域，在各個子領(lǐng)域內(nèi)部分別對事物進(jìn)行建模，來應(yīng)對業(yè)務(wù)的復(fù)雜性。

一、重構(gòu)優(yōu)惠中心的背景

我們在實際的開發(fā)過程中都遇到過這種情況，最初因為業(yè)務(wù)邏輯比較單一，為了快速實現(xiàn)功能， 以及對成本、風(fēng)險等因素的綜合考慮，我們會為業(yè)務(wù)統(tǒng)一創(chuàng)建一個大的模型，各個模塊都使用這同一個模型。但隨著業(yè)務(wù)的發(fā)展，各子領(lǐng)域的邏輯越來越復(fù)雜，對這個大模型的修改就會變成一種災(zāi)難，有時明明是要改一個 A 子領(lǐng)域的邏輯，卻莫名其妙影響到了 B 或者 C 子領(lǐng)域的線上功能。

優(yōu)惠中心就是一個例子。優(yōu)惠中心主要負(fù)責(zé)馬蜂窩各業(yè)務(wù)線商品的優(yōu)惠活動管理，以及計算不同用戶的優(yōu)惠結(jié)果?！干唐饭芾怼购汀竷?yōu)惠管理」作為兩個不同的業(yè)務(wù)單元，在初期被設(shè)計為共用一個商品模型，由商品模塊統(tǒng)一管理。

圖1 ：初期商品模型

出現(xiàn)的問題

隨著業(yè)務(wù)的發(fā)展，優(yōu)惠的形式不斷推陳出新，業(yè)務(wù)形態(tài)逐漸多樣，業(yè)務(wù)方的需求也越來越個性化，導(dǎo)致后期的優(yōu)惠中心無論從功能上還是系統(tǒng)上都出現(xiàn)了一些具體的問題：

1. 功能上來說，不夠靈活

優(yōu)惠信息是作為商品信息的一個屬性在商品管理模塊配置的。比如為了引導(dǎo)用戶使用 App 需要設(shè)置 A 類型優(yōu)惠，就通過在商品信息的編輯頁面增加一個 A 類型優(yōu)惠配置項實現(xiàn)；如果某個商品的 A 類型優(yōu)惠需要在 0:00 分生效，業(yè)務(wù)同學(xué)就必須在電腦前等到 0:00 更新商品信息來上線優(yōu)惠活動。

另外，如果想要創(chuàng)建針對所有商品都適用的優(yōu)惠，按照之前的模式，所有的商品都要設(shè)置一遍，這幾乎是不可接受的。

2. 從系統(tǒng)層面看，不易擴(kuò)展

優(yōu)惠信息存儲在商品信息中，優(yōu)惠信息是通過商品管理模塊的接口輸出的。如果要新增一種優(yōu)惠類型，商品信息相關(guān)的表就要增加字段，商品的表會越來越大；如果要迭代一個優(yōu)惠的邏輯，就有可能影響到商品管理模塊的功能。

3. 不利于迭代

由于優(yōu)惠信息僅僅作為商品的一個屬性，沒有自己的生命周期，所以很難去統(tǒng)計某一次設(shè)置的優(yōu)惠的投入產(chǎn)出比，從而指導(dǎo)后續(xù)的功能優(yōu)化。

重構(gòu)優(yōu)惠中心的預(yù)期

• 系統(tǒng)層面上，要把優(yōu)惠相關(guān)的業(yè)務(wù)邏輯獨立出來，單獨設(shè)計和實現(xiàn)；

• 應(yīng)用層面上，優(yōu)惠中心會有自己的獨立后臺，負(fù)責(zé)管理優(yōu)惠活動；也會有獨立的優(yōu)惠計算接口，負(fù)責(zé) C 端用戶使用優(yōu)惠時的計算。

二、為什么選擇 DDD

避免貧血模型

基于傳統(tǒng)的 MVC 架構(gòu)開發(fā)功能的時候，Model 層本質(zhì)上是一個 DAO 層，業(yè)務(wù)邏輯通常會封裝在 Service 層，然后 Controller 通過調(diào)用 Service 層來完成對外的功能。這種模式下，數(shù)據(jù)和行為分別被割裂到了 Model 和 Service 兩層。我們把這種只承載數(shù)據(jù)，但沒有業(yè)務(wù)行為的 Model 稱為「貧血模型」。

我們在和業(yè)務(wù)方了解需求的過程中，使用到的對象都是現(xiàn)實業(yè)務(wù)的映射，是行為和屬性的綜合體。需求確定好之后，我們開發(fā)的過程中，人為把行為和數(shù)據(jù)拆分成了兩部分，做了一次轉(zhuǎn)換。隨著需求的迭代，人員的更迭，開發(fā)看到的代碼和業(yè)務(wù)方的需求越來越對應(yīng)不上，導(dǎo)致很多代碼誰也不知道對應(yīng)的是什么業(yè)務(wù)邏輯，這種現(xiàn)象被稱為由貧血模型帶來的「失憶癥」，最終導(dǎo)致的是一個維護(hù)成本極高的大泥潭系統(tǒng)。

領(lǐng)域驅(qū)動設(shè)計的核心就是基于業(yè)務(wù)邏輯去建模，避免貧血模型，減少設(shè)計和開發(fā)過程中對業(yè)務(wù)信息的丟失和轉(zhuǎn)換。在業(yè)務(wù)邏輯迭代的過程中，系統(tǒng)通過調(diào)整對應(yīng)的業(yè)務(wù)模型就可以完成迭代。

三、落地過程

關(guān)鍵點：業(yè)務(wù)邏輯抽象

要做到基于業(yè)務(wù)邏輯建模，就要合理地抽象。因為業(yè)務(wù)表象千差萬別，產(chǎn)品經(jīng)理和軟件設(shè)計人員需要和業(yè)務(wù)專家深入交流，并且從離散的信息中抽象出業(yè)務(wù)內(nèi)在的邏輯。

比如旅游業(yè)務(wù)售賣的商品和標(biāo)品不同，有些優(yōu)惠是不考慮人群的，比如使用優(yōu)惠券，所有類型的庫存都可以享受；但如 N 人 N 折這類優(yōu)惠，成人價可以享受，兒童價和單房差就不可以。基于這個特點，我們對優(yōu)惠中心的商品模型做了抽象，抽象出來「是否可以參與件數(shù)計算」和 「是否可以參與價格計算」兩個通用屬性。這樣既實現(xiàn)了基于業(yè)務(wù)邏輯建模，又不會陷入業(yè)務(wù)邏輯千差萬別的表象中。

3.1 戰(zhàn)術(shù)設(shè)計

第一步：統(tǒng)一語言，提煉關(guān)鍵詞

準(zhǔn)確的語言對于產(chǎn)品、運(yùn)營、開發(fā)等各方對齊需求非常重要，我們需要將優(yōu)惠邏輯當(dāng)中的概念抽象為各方都能理解的詞語，以達(dá)成共識。作為開發(fā)人員來說，對領(lǐng)域的理解一般來說是比較少的，為了抽象出合理的語言讓產(chǎn)品和業(yè)務(wù)方都能理解，就需要充分理解業(yè)務(wù)背景和需求。在熟悉業(yè)務(wù)和需求的過程中，提煉出若干關(guān)鍵字，這些關(guān)鍵詞就是最初產(chǎn)生的領(lǐng)域概念和通用語言。比如：

• 優(yōu)惠類型：表示一種優(yōu)惠規(guī)則和對應(yīng)的優(yōu)惠方案。比如早鳥優(yōu)惠，就是早多少錢買（優(yōu)惠規(guī)則），減多少錢/打幾折（優(yōu)惠方案）;

• 優(yōu)惠活動：擁有完整的生命周期，需要包含時間、平臺、人員、商品等（限制維度）的某種優(yōu)惠類型的使用過程信息；

• 優(yōu)惠發(fā)現(xiàn)：根據(jù)指定的商品、人員和平臺，找出可以使用的優(yōu)惠活動列表服務(wù)；

• 優(yōu)惠計算：根據(jù)指定的商品、人員、平臺以及購買數(shù)量，計算出這一次購買行為可以享受的優(yōu)惠金額及優(yōu)惠明細(xì)；

• 優(yōu)惠排序：各種優(yōu)惠類型在計算的時候是有先后順序的，如果有打折的優(yōu)惠存在，那順序不同，計算的結(jié)果也會不同；

• 優(yōu)惠互斥：某些優(yōu)惠之間存在互斥的關(guān)系，比如使用了金卡 96 折優(yōu)惠，就不能使用馬蜂窩優(yōu)惠券。

第二步：抽象領(lǐng)域模型

根據(jù)單一職責(zé)的原則，一個領(lǐng)域概念對應(yīng)一個領(lǐng)域?qū)ο?。領(lǐng)域?qū)ο笥?strong>實體和值對象之分：

• 實體：實體是有狀態(tài)的和唯一標(biāo)識的，包含屬性和行為；

• 值對象：值對象是無狀態(tài)的，是只讀的，包含屬性和行為。

區(qū)分實體和值對象對系統(tǒng)設(shè)計有很大意義，實體是我們需要重點關(guān)注和設(shè)計的，而值對象則只使用它的「值」就可以了。這樣可以簡化系統(tǒng)的復(fù)雜度，將精力聚焦在核心領(lǐng)域?qū)ο?。不難理解，優(yōu)惠活動毋庸置疑是一個實體，優(yōu)惠類型就是一個值對象。

但也存在某些業(yè)務(wù)行為是不能歸于某個實體或值對象的，可以將它們歸為領(lǐng)域服務(wù)：

• 領(lǐng)域服務(wù)：領(lǐng)域服務(wù)本質(zhì)上就是一些操作，不包含狀態(tài)，通常用于協(xié)調(diào)多個實體。實體和值都屬于領(lǐng)域?qū)ο螅I(lǐng)域?qū)ο笾g的交互邏輯不能放在領(lǐng)域?qū)ο髢?nèi)部，必須由服務(wù)來實現(xiàn)，從而有效地保護(hù)領(lǐng)域模型。

有一些領(lǐng)域邏輯，比如「優(yōu)惠排序」和「優(yōu)惠互斥」，他們涉及到多個優(yōu)惠類型，也就是多個領(lǐng)域?qū)ο?。如果也被設(shè)計為領(lǐng)域?qū)ο螅痛蚱屏藛我宦氊?zé)的原則，所以我們把這部分跨多個領(lǐng)域?qū)ο蟮臉I(yè)務(wù)邏輯放到「領(lǐng)域服務(wù)」層。

第三步：抽象領(lǐng)域?qū)ο笾g的關(guān)聯(lián)關(guān)系

將相關(guān)聯(lián)的領(lǐng)域?qū)ο筮M(jìn)行顯式分組，來表達(dá)整體的概念（也可以是單一的領(lǐng)域?qū)ο螅簿褪?strong>「聚合」。

比如優(yōu)惠活動是優(yōu)惠類型、優(yōu)惠范圍等的聚合；優(yōu)惠類型是優(yōu)惠規(guī)則和優(yōu)惠方案的聚合；優(yōu)惠規(guī)則是限制維度的聚合；優(yōu)惠方案是優(yōu)惠手段的聚合：

圖2 ：關(guān)聯(lián)關(guān)系示意

聚合的主要功能是把領(lǐng)域?qū)ο蠓纸M，外部的唯一訪問點就是聚合根，這樣可以避免處理領(lǐng)域?qū)ο箝g的一一對應(yīng)關(guān)系，只需要處理聚合和聚合之間的關(guān)系就行了。

第四步：走查場景，調(diào)整領(lǐng)域模型

領(lǐng)域模型的調(diào)整是貫穿整個設(shè)計和開發(fā)過程的，隨著業(yè)務(wù)的調(diào)整，領(lǐng)域模型也需要調(diào)整。比如優(yōu)惠中心后期引入了會員卡的優(yōu)惠類型，那么就需要把優(yōu)惠券這個優(yōu)惠類型的顯示，調(diào)整為與會員卡互斥的優(yōu)惠券和與會員卡不互斥的兩種。

第五步：簡化設(shè)計，降低系統(tǒng)復(fù)雜度

建模的本質(zhì)是對現(xiàn)實事物的一種簡化和抽象，指導(dǎo)我們忽略和問題域無關(guān)的事實，提取和問題域息息相關(guān)的信息。以優(yōu)惠中心為例，最初的方案里我們設(shè)計了優(yōu)惠類型管理的功能，根據(jù)不同的優(yōu)惠規(guī)則和優(yōu)惠方案自動組合成不同類型的優(yōu)惠類型。但是可以預(yù)見，未來的優(yōu)惠類型是有限的，并且每個優(yōu)惠類型都有會自己的特殊配置，比如 N 人優(yōu)惠里的 每 N 人/第 N 人；早鳥中的提前 N 天等。也就是說，根據(jù)優(yōu)惠規(guī)則和優(yōu)惠方案自動生成優(yōu)惠類型基本是沒有使用場景的，因此也就去掉了這個設(shè)計。

再如，對優(yōu)惠的限制我們最初是設(shè)計在優(yōu)惠活動維度，經(jīng)過權(quán)衡，為了降低系統(tǒng)復(fù)雜度，最后實現(xiàn)在了優(yōu)惠類型層面。以「蜂搶」優(yōu)惠類型為例，它的規(guī)則是所有的蜂搶活動都是 1 個用戶只能搶一次，沒有必要把這個限制放在優(yōu)惠活動維度，在優(yōu)惠類型層面控制就可以了。

3.2 戰(zhàn)略設(shè)計

戰(zhàn)略設(shè)計處理的是不同限界上下文之間的拆分和集成邏輯。限界上下文比較抽象，結(jié)合我們在文章開始提到的不同語境中的「商品」例子來理解，同一個詞如果不說明白所處的語境，是無法準(zhǔn)確描述清楚其表達(dá)的含義的?！刚Z境」其實就是「上下文」，對應(yīng)不同「子領(lǐng)域」。同理，如果不在一個限定好的上下文中去設(shè)計領(lǐng)域模型，設(shè)計出的領(lǐng)域模型是不清晰的，它就會同時支持多個上下文。

這里需要說明一點，如果是從零搭建一個全新的電商系統(tǒng)，首先需要做的應(yīng)該是戰(zhàn)略設(shè)計。而優(yōu)惠中心是建立在現(xiàn)有大的電商系統(tǒng)基礎(chǔ)上，相當(dāng)于作為其中一個子領(lǐng)域進(jìn)行重構(gòu)，所以我們才會先來做戰(zhàn)術(shù)設(shè)計，再考慮在完整的電商系統(tǒng)下它與外部其他環(huán)境之間的關(guān)系，也就是戰(zhàn)略設(shè)計。

優(yōu)惠中心內(nèi)部場景區(qū)分

優(yōu)惠中心包括了服務(wù)于 B 端用戶的優(yōu)惠活動管理和服務(wù)于 C 端用戶的優(yōu)惠計算這兩個不同的子業(yè)務(wù)單元：

、

圖3 ：優(yōu)惠中心內(nèi)部場景區(qū)分

• 優(yōu)惠活動處理的是優(yōu)惠活動的增刪改查，以及配套的統(tǒng)計等業(yè)務(wù)；優(yōu)惠活動在這里是一個實體，有完整的生命周期，有上線、下線等狀態(tài)，可以被創(chuàng)建和刪除；

• 優(yōu)惠計算處理的是一個訂單能享受哪些優(yōu)惠，并減多少錢的問題；在這個場景里，優(yōu)惠活動是一個值對象，只提供優(yōu)惠計算需要的必要參數(shù)即可。

優(yōu)惠中心與外部系統(tǒng)集成

在整個電商系統(tǒng)的環(huán)境下，優(yōu)惠中心作為一個子域，處于自己的限界上下文當(dāng)中。使用優(yōu)惠中心服務(wù)的詳情頁、下單頁都處于自己各自的限界上下文，所以調(diào)用優(yōu)惠中心的時候就需要設(shè)計它們之間的上下文映射方式。

調(diào)用和被調(diào)用方使用的戰(zhàn)略設(shè)計方法通常有以下幾種：

• 客戶方-供應(yīng)方：適用于同一個團(tuán)隊之間的協(xié)作，上游會有嚴(yán)格的自動化測試，來保證給到下游的數(shù)據(jù)是一定符合約定的；

• 遵奉者：適用于不同團(tuán)隊協(xié)作，且上游不關(guān)心下游的標(biāo)準(zhǔn)，下游又完全「逆來順受」地接受了上游給的數(shù)據(jù)的場景；

• 防腐層：適用于上游不關(guān)心下游的標(biāo)準(zhǔn)，但是下游不甘心「逆來順受」，就增加一層，來做轉(zhuǎn)換處理，保持下游系統(tǒng)的獨立性；

• 開放主機(jī)服務(wù)：適用于中臺（通用能力平臺），對接方非常多，業(yè)務(wù)重復(fù)度高，并且已經(jīng)有完善的測試機(jī)制和通用的模型。

結(jié)合我們的實際情況來看，調(diào)用優(yōu)惠中心的可能會是不同團(tuán)隊的開發(fā)人員，而優(yōu)惠中心又不想被不同的上游侵入內(nèi)部設(shè)計中，所以「客戶方-供應(yīng)方」和「遵奉者」模型都不適合；另外優(yōu)惠中心前期接入方會比較少，而且會不斷迭代，使用「開放主機(jī)服務(wù)」也不太合適。綜合考慮下，防腐層的設(shè)計比較適合優(yōu)惠中心。

下圖是優(yōu)惠中心的業(yè)務(wù)架構(gòu)示意，中間的應(yīng)用服務(wù)層采用的就是防腐層的設(shè)計，反映優(yōu)惠中心與外部系統(tǒng)集成時的上下文映射關(guān)系：

圖4 ：優(yōu)惠中心業(yè)務(wù)架構(gòu)

3.3 架構(gòu)實現(xiàn)

優(yōu)惠中心選擇的是經(jīng)典的分層架構(gòu)。從上到下為用戶接口層、應(yīng)用服務(wù)層、領(lǐng)域?qū)雍蛡}儲層。圖中不同的顏色塊分別對映外部服務(wù)、應(yīng)用服務(wù)、領(lǐng)域服務(wù)、聚合根、實體、值對象和倉儲。

圖5 ：優(yōu)惠中心分層領(lǐng)域模型

• 用戶接口層：處理和終端用戶的交互邏輯；

• 應(yīng)用服務(wù)層：負(fù)責(zé)封裝和轉(zhuǎn)換領(lǐng)域?qū)拥姆祷財?shù)據(jù)給用戶接口層；

• 領(lǐng)域?qū)?/strong>：優(yōu)惠中心的核心邏輯都在這一層，包括領(lǐng)域?qū)ο蠛皖I(lǐng)域服務(wù)。

• 倉儲層：倉儲層負(fù)責(zé)把內(nèi)存中的領(lǐng)域?qū)ο舐涞氐酱鎯橘|(zhì)，也負(fù)責(zé)從存儲介質(zhì)拿到原始數(shù)據(jù)后構(gòu)造領(lǐng)域?qū)ο蠼o領(lǐng)域?qū)邮褂?；這一層對領(lǐng)域?qū)与[藏了底層的存儲細(xì)節(jié)。雖然倉儲層處在領(lǐng)域?qū)酉路剑俏覀儗崿F(xiàn)過程中采用了依賴注入的方式，將倉儲層的具體實現(xiàn)注入到領(lǐng)域?qū)又小?/p>