前言

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

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

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

一、重構優惠中心的背景

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

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

出現的問題

隨着業務的發展，優惠的形式不斷推陳出新，業務形態逐漸多樣，業務方的需求也越來越個性化，導致後期的優惠中心無論從功能上還是系統上都出現了一些具體的問題：

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

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

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

2. 從系統層面看，不易擴展

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

3. 不利於迭代

由於優惠信息僅僅作爲商品的一個屬性，沒有自己的生命週期，所以很難去統計某一次設置的優惠的投入產出比，從而指導後續的功能優化。

重構優惠中心的預期

系統層面上，要把優惠相關的業務邏輯獨立出來，單獨設計和實現；

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

二、分什麼選擇 DDD

避免貧血模型

基於傳統的 MVC 架構開發功能的時候，Model 層本質上是一個 DAO 層，業務邏輯通常會封裝在 Service 層，然後 Controller 通過調用 Service 層來完成對外的功能。這種模式下，數據和行爲分別被割裂到了 Model 和 Service 兩層。我們把這種只承載數據，但沒有業務行爲的 Model 稱爲「貧血模型」。

我們在和業務方瞭解需求的過程中，使用到的對象都是現實業務的映射，是行爲和屬性的綜合體。需求確定好之後，我們開發的過程中，人爲把行爲和數據拆分成了兩部分，做了一次轉換。隨着需求的迭代，人員的更迭，開發看到的代碼和業務方的需求越來越對應不上，導致很多代碼誰也不知道對應的是什麼業務邏輯，這種現象被稱爲由貧血模型帶來的「失憶症」，最終導致的是一個維護成本極高的大泥潭系統。

領域驅動設計的核心就是基於業務邏輯去建模，避免貧血模型，減少設計和開發過程中對業務信息的丟失和轉換。在業務邏輯迭代的過程中，系統通過調整對應的業務模型就可以完成迭代。

三、落地過程

關鍵點：業務邏輯抽象

要做到基於業務邏輯建模，就要合理地抽象。因爲業務表象千差萬別，產品經理和軟件設計人員需要和業務專家深入交流，並且從離散的信息中抽象出業務內在的邏輯。

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

3.1 戰術設計

第一步：統一語言，提煉關鍵詞

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

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

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

優惠發現：根據指定的商品、人員和平臺，找出可以使用的優惠活動列表服務；

優惠計算：根據指定的商品、人員、平臺以及購買數量，計算出這一次購買行爲可以享受的優惠金額及優惠明細；

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

優惠互斥：某些優惠之間存在互斥的關係，比如使用了金卡 96 折優惠，就不能使用馬蜂窩優惠券。

第二步：抽象領域模型

根據單一職責的原則，一個領域概念對應一個領域對象。領域對象有實體和值對象之分：

實體：實體是有狀態的和唯一標識的，包含屬性和行爲；

值對象：值對象是無狀態的，是隻讀的，包含屬性和行爲。

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

但也存在某些業務行爲是不能歸於某個實體或值對象的，可以將它們歸爲領域服務：

領域服務：領域服務本質上就是一些操作，不包含狀態，通常用於協調多個實體。實體和值都屬於領域對象，領域對象之間的交互邏輯不能放在領域對象內部，必須由服務來實現，從而有效地保護領域模型。

有一些領域邏輯，比如「優惠排序」和「優惠互斥」，他們涉及到多個優惠類型，也就是多個領域對象。如果也被設計爲領域對象，就打破了單一職責的原則，所以我們把這部分跨多個領域對象的業務邏輯放到「領域服務」層。

第三步：抽象領域對象之間的關聯關係

將相關聯的領域對象進行顯式分組，來表達整體的概念（也可以是單一的領域對象），也就是「聚合」。

比如優惠活動是優惠類型、優惠範圍等的聚合；優惠類型是優惠規則和優惠方案的聚合；優惠規則是限制維度的聚合；優惠方案是優惠手段的聚合：

聚合的主要功能是把領域對象分組，外部的唯一訪問點就是聚合根，這樣可以避免處理領域對象間的一一對應關係，只需要處理聚合和聚合之間的關係就行了。

第四步：走查場景，調整領域模型

領域模型的調整是貫穿整個設計和開發過程的，隨着業務的調整，領域模型也需要調整。比如優惠中心後期引入了會員卡的優惠類型，那麼就需要把優惠券這個優惠類型的顯示，調整爲與會員卡互斥的優惠券和與會員卡不互斥的兩種。

第五步：簡化設計，降低系統複雜度

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

再如，對優惠的限制我們最初是設計在優惠活動維度，經過權衡，爲了降低系統複雜度，最後實現在了優惠類型層面。以「蜂搶」優惠類型爲例，它的規則是所有的蜂搶活動都是 1 個用戶只能搶一次，沒有必要把這個限制放在優惠活動維度，在優惠類型層面控制就可以了。

3.2 戰略設計

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

這裏需要說明一點，如果是從零搭建一個全新的電商系統，首先需要做的應該是戰略設計。而優惠中心是建立在現有大的電商系統基礎上，相當於作爲其中一個子領域進行重構，所以我們纔會先來做戰術設計，再考慮在完整的電商系統下它與外部其他環境之間的關係，也就是戰略設計。

優惠中心內部場景區分

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

優惠活動處理的是優惠活動的增刪改查，以及配套的統計等業務；優惠活動在這裏是一個實體，有完整的生命週期，有上線、下線等狀態，可以被創建和刪除；

優惠計算處理的是一個訂單能享受哪些優惠，並減多少錢的問題；在這個場景裏，優惠活動是一個值對象，只提供優惠計算需要的必要參數即可。

優惠中心與外部系統集成

在整個電商系統的環境下，優惠中心作爲一個子域，處於自己的限界上下文當中。使用優惠中心服務的詳情頁、下單頁都處於自己各自的限界上下文，所以調用優惠中心的時候就需要設計它們之間的上下文映射方式。

調用和被調用方使用的戰略設計方法通常有以下幾種：

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

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

防腐層：適用於上游不關心下游的標準，但是下游不甘心「逆來順受」，就增加一層，來做轉換處理，保持下游系統的獨立性；

開放主機服務：適用於中臺（通用能力平臺），對接方非常多，業務重複度高，並且已經有完善的測試機制和通用的模型。

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

下圖是優惠中心的業務架構示意，中間的應用服務層採用的就是防腐層的設計，反映優惠中心與外部系統集成時的上下文映射關係：

3.3 架構實現

優惠中心選擇的是經典的分層架構。從上到下爲用戶接口層、應用服務層、領域層和倉儲層。圖中不同的顏色塊分別對映外部服務、應用服務、領域服務、聚合根、實體、值對象和倉儲。

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

應用服務層：負責封裝和轉換領域層的返回數據給用戶接口層；

領域層：優惠中心的核心邏輯都在這一層，包括領域對象和領域服務。

倉儲層：倉儲層負責把內存中的領域對象落地到存儲介質，也負責從存儲介質拿到原始數據後構造領域對象給領域層使用；這一層對領域層隱藏了底層的存儲細節。雖然倉儲層處在領域層下方，但是我們實現過程中採用了依賴注入的方式，將倉儲層的具體實現注入到領域層中。

四、問題及近期規劃

1. 價格層優惠

現在公司面沒有一個統一的商品中心，並且各業務線對商品的定義差別很大。比如自由行的商品包括出行日期、價格類別（成人價、兒童價）和套餐類別等層級；而火車票的商品包含座次、席別、目的地和出發地等層級。

如果優惠中心抽象出一種通用的商品層級來適配各個業務線，那實際上就是優惠中心要對商品進行標準定義，但是這個標準與後續商品中心的標準定義很有可能是不一致的，如果不一致優惠中心就要做大的改版。所以最終的解決方案可能還要通過推進統一商品中心的建立來解決。

2. 性能問題

領域驅動設計帶來的弊端就是類的增多。目前優惠中心的技術棧基於 PHP， PHP 是一種解釋型語言，在DDD 模式下即使有了 OPCode 等緩存技術，執行階段的耗時相對其他靜態數據類型的語言還是較大。所以後面計劃將優惠中心使用 Java 技術棧重構，來進行性能上的優化。

五、小結

本文介紹了馬蜂窩電商優惠中心基於 DDD 進行重構的一些實踐經驗。DDD 的思想也幫助我們在業務迭代的過程中將架構設計得更加合理。

當然，是否採用業務驅動設計的思想，需要取決於業務和團隊的實際情況。在馬蜂窩業務的快速發展下，我們在架構設計上還將做更多的探索，也將持續與大家交流。

本文作者：徐興旺，馬蜂窩電商研發平臺服務團隊技術專家。

（馬蜂窩技術原創內容，轉載務必註明出處，謝謝配合。）