前言

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

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

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

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

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

優(yōu)惠中心就是一個例子。優(yōu)惠中心主要負責馬蜂窩各業(yè)務線商品的優(yōu)惠活動管理，以及計算不同用戶的優(yōu)惠結果。「商品管理」和「優(yōu)惠管理」作為兩個不同的業(yè)務單元，在初期被設計為共用一個商品模型，由商品模塊統(tǒng)一管理。

圖1 ：初期商品模型

出現(xiàn)的問題

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

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

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

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

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

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

3. 不利于迭代

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

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

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

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

二、為什么選擇 DDD

避免貧血模型

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

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

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

三、落地過程

關鍵點：業(yè)務邏輯抽象

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

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

3.1 戰(zhàn)術設計

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

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

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

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

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

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

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

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

第二步：抽象領域模型

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

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

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

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

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

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

有一些領域邏輯，比如「優(yōu)惠排序」和「優(yōu)惠互斥」，他們涉及到多個優(yōu)惠類型，也就是多個領域?qū)ο?。如果也被設計為領域?qū)ο?，就打破了單一職責的原則，所以我們把這部分跨多個領域?qū)ο蟮臉I(yè)務邏輯放到「領域服務」層。

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

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

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

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

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

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

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

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

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

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

3.2 戰(zhàn)略設計

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

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

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

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

、

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

• 優(yōu)惠活動處理的是優(yōu)惠活動的增刪改查，以及配套的統(tǒng)計等業(yè)務；優(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)惠中心作為一個子域，處于自己的限界上下文當中。使用優(yōu)惠中心服務的詳情頁、下單頁都處于自己各自的限界上下文，所以調(diào)用優(yōu)惠中心的時候就需要設計它們之間的上下文映射方式。

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

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

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

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

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

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

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

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

3.3 架構實現(xiàn)

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

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

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

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

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

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