前言

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

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

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

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

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

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

圖1 ：初期商品模型

出現(xiàn)的問題

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

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

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

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

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

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

3. 不利于迭代

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

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

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

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

二、為什么選擇 DDD

避免貧血模型

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

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

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

三、落地過程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

有一些領(lǐng)域邏輯，比如「優(yōu)惠排序」和「優(yōu)惠互斥」，他們涉及到多個(gè)優(yōu)惠類型，也就是多個(gè)領(lǐng)域?qū)ο?。如果也被設(shè)計(jì)為領(lǐng)域?qū)ο?，就打破了單一職?zé)的原則，所以我們把這部分跨多個(gè)領(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)惠活動(dòng)是優(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，外部的唯一訪問點(diǎn)就是聚合根，這樣可以避免處理領(lǐng)域?qū)ο箝g的一一對(duì)應(yīng)關(guān)系，只需要處理聚合和聚合之間的關(guān)系就行了。

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

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

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

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

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

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

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

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

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

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

、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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