不同于其它的架構(gòu)方法，領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)DDD(Domain Driven Design)提出了從業(yè)務(wù)設(shè)計(jì)到代碼實(shí)現(xiàn)一致性的要求，不再對(duì)分析模型和實(shí)現(xiàn)模型進(jìn)行區(qū)分。也就是說從代碼的結(jié)構(gòu)中我們可以直接理解業(yè)務(wù)的設(shè)計(jì)，命名得當(dāng)?shù)脑挘浅绦蛉藛T也可以“讀”代碼。

[[209114]]

然而在整個(gè)DDD的建模過程中，我們更多關(guān)注的是核心領(lǐng)域模型的建立，我們認(rèn)為完成業(yè)務(wù)的需求就是在領(lǐng)域模型上的一系列操作(應(yīng)用)。這些操作包括了對(duì)核心實(shí)體狀態(tài)的改變，領(lǐng)域事件的存儲(chǔ)，領(lǐng)域服務(wù)的調(diào)用等。在良好的領(lǐng)域模型之上，實(shí)現(xiàn)這些應(yīng)用應(yīng)該是輕松而愉快的。

筆者經(jīng)歷過很多次DDD的建模工作坊，在經(jīng)歷了數(shù)天一輪又一輪激烈討論和不厭其煩的審視之后，大家欣慰地看著白板上各種顏色紙貼所展示出來的領(lǐng)域模型，成就感寫滿大家的臉龐。就在這個(gè)大功告成的時(shí)刻，往往會(huì)有人問：這個(gè)模型我們?cè)趺绰涞啬?然后大家臉上的愉悅消失了，換上了對(duì)細(xì)節(jié)就是魔鬼的焦慮。但這是我們不可避免的實(shí)現(xiàn)細(xì)節(jié)，DDD的原始方法論中雖然給出了“分層架構(gòu)”(Layered Architecture)的元模型，但如何分層卻沒有明確定義。

分層架構(gòu)

在DDD方法提出后的數(shù)年里，分層架構(gòu)的具體實(shí)現(xiàn)也經(jīng)歷了幾代演進(jìn)，直到Martin Fowler提煉出下圖的分層實(shí)現(xiàn)架構(gòu)后，才逐步為大家所認(rèn)可。DDD的方法也得到了有效的補(bǔ)充，模型落地的問題也變得更容易，核心領(lǐng)域模型的范圍也做出了比較明確的定義：包括了Domain，Service Layer和Repositories。

(Martin Fowler總結(jié)提出的分層架構(gòu)實(shí)現(xiàn)，注意“Resources”是基于RESTful架構(gòu)的抽象，我們也可以理解為更通用的針對(duì)外界的接口Interface。而HTTP Client主要是針對(duì)互聯(lián)網(wǎng)的通信協(xié)議，Gateways實(shí)際才是交換過程中組裝信息的邏輯所在。)

我們的核心實(shí)體(Entity)和值對(duì)象(Value Object)應(yīng)該在Domain層，定義的領(lǐng)域服務(wù)(Domain Service)在Service Layer，而針對(duì)實(shí)體和值對(duì)象的存儲(chǔ)和查詢邏輯都應(yīng)該在Repositories層。值得注意的是，不要把Entity的屬性和行為分離到Domain和Service兩層中去實(shí)現(xiàn)，即所謂的貧血模型，事實(shí)證明這樣的實(shí)現(xiàn)方式會(huì)造成很大的維護(hù)問題。DDD戰(zhàn)術(shù)建模中的元模型定義不應(yīng)該在實(shí)現(xiàn)過程中被改變，作為元模型中元素之一的實(shí)體本身就應(yīng)該包含針對(duì)自身的行為定義。

基于這個(gè)模型，下面我們來談?wù)劯唧w的代碼結(jié)構(gòu)。對(duì)于這個(gè)分層架構(gòu)還有疑惑的讀者可以精讀一下Martin的 原文 。有意思的一點(diǎn)是，這個(gè)模型的敘述實(shí)際是在微服務(wù)架構(gòu)的測(cè)試文章中，其中深意值得大家體會(huì)。

這里需要明確的是，我們談?wù)摯a結(jié)構(gòu)的時(shí)候，針對(duì)的是一個(gè)經(jīng)過DDD建模后的子問題域(參見戰(zhàn)略設(shè)計(jì)篇)，這是我們明確的組件化邊界。是否進(jìn)一步組件化，比如按照限界上下文(Bounded Context)模塊化，或采用微服務(wù)架構(gòu)服務(wù)化，核心實(shí)體都是進(jìn)一步可能采用的組件化方法。從抽象層面講，老馬提煉的分層架構(gòu)適用于面向業(yè)務(wù)的服務(wù)化架構(gòu)，所以如果要進(jìn)一步組件化也是可以按照這個(gè)代碼結(jié)構(gòu)來完成的。

總體的代碼目錄結(jié)構(gòu)如下：

- DDD-Sample/src/ 
    domain 
    gateways 
    interface 
    repositories 
    services 

這個(gè)目錄結(jié)構(gòu)一一對(duì)應(yīng)了前文的分層架構(gòu)圖。完整的案例代碼請(qǐng)從GitHub 下載 。

可以看到實(shí)際上我們并沒有建立外部存儲(chǔ)(Data Mappers/ORM)和對(duì)外通信(HTTP Client)的目錄。從領(lǐng)域模型和應(yīng)用的角度，這兩者都是我們不必關(guān)心的，能夠驗(yàn)證整個(gè)領(lǐng)域模型的輸入和輸出就足夠了。至于什么樣的外部存儲(chǔ)和外部通信機(jī)制是可以被“注入”的。這樣的隔離是實(shí)現(xiàn)可獨(dú)立部署服務(wù)的基礎(chǔ)，也是我們能夠測(cè)試領(lǐng)域模型實(shí)現(xiàn)的要求。

[[209115]]

模型表達(dá)

根據(jù)分層架構(gòu)確立了代碼結(jié)構(gòu)后，我們需要首先定義清楚我們的模型。如前面講到的，這里主要涉及的是從戰(zhàn)術(shù)建模過程中得到的核心實(shí)體和服務(wù)的定義。我們利用C++頭文件(.h文件)來展示一個(gè)Domain模型的定義，案例靈感來源于DDD原著里的集裝箱貨運(yùn)例子。

namespace domain{ 
struct Entity 
{ 
    int getId(); 
protected: 
    int id; 
}; 
 
struct AggregateRoot: Entity 
{ 
}; 
 
struct ValueObject 
{ 
}; 
 
struct Provider 
{ 
 
}; 
 
struct Delivery: ValueObject 
{ 
    Delivery(int); 
    int AfterDays; 
}; 
 
struct Cargo: AggregateRoot 
{ 
    Cargo(Delivery*, int); 
    ~Cargo(); 
    void Delay(int); 
private: 
    Delivery* delivery; 
}; 
} 

這個(gè)實(shí)現(xiàn)首先申明了元模型實(shí)體Entity和值對(duì)象ValueObject。實(shí)體一定會(huì)有一個(gè)標(biāo)識(shí)id。在實(shí)體的基礎(chǔ)上聲明了DDD中的重要元素聚合根 AggregateRoot。根據(jù)定義，聚合根本身就應(yīng)該是一個(gè)實(shí)體，所以AggregateRoot繼承了Entity。

這個(gè)案例中我們定義了一個(gè)實(shí)體Cargo，同時(shí)也是一個(gè)聚合根。Delivery是一個(gè)值對(duì)象。雖然這里為了實(shí)現(xiàn)效率采用的是struct，在C++里可以理解為定義一個(gè)class類。

依賴關(guān)系

代碼目錄結(jié)構(gòu)并不能表達(dá)分層體系中各層的依賴關(guān)系，比如Domain層是不應(yīng)該依賴于其它任何一層的。維護(hù)各層的依賴關(guān)系是至關(guān)重要的，很多團(tuán)隊(duì)在實(shí)施的過程中都沒有能夠建立起這樣的工程紀(jì)律，最后造成代碼結(jié)構(gòu)的混亂，領(lǐng)域模型也被打破。

根據(jù)分層架構(gòu)的規(guī)則，我們可以看到示例中的代碼結(jié)構(gòu)如下圖。

Domain是不依賴于任何的其它對(duì)象的。Repositories是依賴于Domain的，實(shí)現(xiàn)如下：引用了model.h。

#include "model.h" 
#include <vector> 
 
using namespace domain; 
 
namespace repositories { 
struct Repository 
{ 
}; 
... 

Services是依賴于Domain和Repositories的，實(shí)現(xiàn)如下：引用了model.h和repository.h

#include "model.h" 
#include "repository.h" 
 
using namespace domain; 
using namespace repositories; 
 
namespace services { 
struct CargoProvider : Provider { 
    virtual void Confirm(Cargo* cargo){}; 
}; 
 
struct CargoService { 
    ... ... 
}; 
... 

為了維護(hù)合理的依賴關(guān)系，依賴注入(Depedency Injection)是需要經(jīng)常采用的實(shí)現(xiàn)模式，它作為解耦合的一種方法相信大家都不會(huì)陌生，具體定義參見 這里 。

在測(cè)試構(gòu)建時(shí)，我們利用了一個(gè)IoC框架(依賴注入的實(shí)現(xiàn))來構(gòu)造了一個(gè)Api，并且把相關(guān)的依賴(如CargoService)注入給了這個(gè)Api。這樣既沒有破壞Interface和Service的單向依賴關(guān)系，又解決了測(cè)試過程中Api的實(shí)例化要求。

auto provider = std::make_shared< StubCargoProvider >(); 
 
api::Api* createApi()  { 
    ContainerBuilder builder; 
    builder.registerType< CargoRepository >().singleInstance(); 
    builder.registerInstance(provider).as<CargoProvider>(); 
    builder.registerType< CargoService >().singleInstance(); 
    builder.registerType<api::Api>().singleInstance(); 
 
    auto container = builder.build(); 
 
    std::shared_ptr<api::Api> api = container->resolve<api::Api>(); 
 
    return api.get(); 
} 

測(cè)試實(shí)現(xiàn)

有了領(lǐng)域模型，大家自然會(huì)想著如何去實(shí)現(xiàn)業(yè)務(wù)應(yīng)用了，而實(shí)現(xiàn)應(yīng)用的過程中一定會(huì)考慮到單元測(cè)試的設(shè)計(jì)。在構(gòu)建高質(zhì)量軟件過程中，單元測(cè)試已經(jīng)成為了標(biāo)準(zhǔn)規(guī)范，但高質(zhì)量的單元測(cè)試卻是困擾很多團(tuán)隊(duì)的普遍問題。很多時(shí)候設(shè)計(jì)測(cè)試比實(shí)現(xiàn)應(yīng)用本身更加困難。

這里很難有一個(gè)固定標(biāo)準(zhǔn)來評(píng)判某個(gè)時(shí)間點(diǎn)的單元測(cè)試質(zhì)量，但一個(gè)核心的原則是讓用例盡量測(cè)試業(yè)務(wù)需求而不是實(shí)現(xiàn)方式本身。滿足業(yè)務(wù)需求是我們的目標(biāo)，實(shí)現(xiàn)方式可能有多種，我們不希望需要持續(xù)重構(gòu)的實(shí)現(xiàn)代碼影響到我們的測(cè)試用例。比如針對(duì)實(shí)現(xiàn)過程中的某個(gè)函數(shù)進(jìn)行入?yún)⒑统鰠⒌膯卧獪y(cè)試，當(dāng)這個(gè)函數(shù)發(fā)生一點(diǎn)改變(即使是重命名)，我們也需要改動(dòng)測(cè)試。

[[209116]]

測(cè)試驅(qū)動(dòng)開發(fā)TDD無疑是一種好的實(shí)踐，如果應(yīng)用得當(dāng)，它確實(shí)能夠?qū)崿F(xiàn)我們上述的原則，并且能夠幫助我們交流業(yè)務(wù)的需求。比較有意思的是，在基于DDD建立的核心模型之上應(yīng)用TDD似乎更加順理成章。類比DDD和TDD雖然是不恰當(dāng)?shù)?，但我們?huì)發(fā)現(xiàn)兩者在遵循的原則上是一致的，即都是面向業(yè)務(wù)做分解和設(shè)計(jì)：DDD就整個(gè)業(yè)務(wù)問題域進(jìn)行了分解，形成子問題域;TDD就業(yè)務(wù)需求在實(shí)現(xiàn)時(shí)進(jìn)行任務(wù)分解，從簡(jiǎn)單場(chǎng)景到復(fù)雜場(chǎng)景逐步通過測(cè)試驅(qū)動(dòng)出實(shí)現(xiàn)。下面的測(cè)試用例展現(xiàn)了在核心模型上的TDD過程。

TEST(bc_demo_test, create_cargo) 
{ 
    api::CreateCargoMsg* msg = new api::CreateCargoMsg(); 
    msg->Id = ID; 
    msg->AfterDays = AFTER_DAYS; 
    createCargo(msg); 
    EXPECT_EQ(msg->Id, provider->cargo_id); 
    EXPECT_EQ(msg->AfterDays, provider->after_days); 
} 

上面測(cè)試了收到一條創(chuàng)建信息后實(shí)例化一個(gè)Cargo的簡(jiǎn)單場(chǎng)景，要求創(chuàng)建后的Cargo的標(biāo)識(shí)id跟信息里的一致，并且出貨的日期一致。這個(gè)測(cè)試驅(qū)動(dòng)出來一個(gè)Interface的Api::CreateCargo。

下面是另外一個(gè)測(cè)試推遲delay的場(chǎng)景，同樣我們看到了驅(qū)動(dòng)出的Api::Delay的實(shí)現(xiàn)。

TEST(bc_demo_test, delay_cargo) 
{ 
    api::Api* api = createApi(); 
    api::CreateCargoMsg* msg = new api::CreateCargoMsg(); 
    msg->Id = ID; 
    msg->AfterDays = AFTER_DAYS; 
    api->CreateCargo(msg); 
    api->Delay(ID,2); 
    EXPECT_EQ(ID, provider->cargo_id); 
    EXPECT_EQ(12, provider->after_days); 
} 

長(zhǎng)期以來對(duì)于TDD這個(gè)實(shí)踐大家都有架構(gòu)設(shè)計(jì)上的疑惑，很多資深架構(gòu)師擔(dān)心完全從業(yè)務(wù)需求驅(qū)動(dòng)出實(shí)現(xiàn)沒法形成有效的技術(shù)架構(gòu)，而且每次實(shí)現(xiàn)的重構(gòu)成本都可能很高。DDD的引入從某種程度上解決了這個(gè)顧慮，通過前期的戰(zhàn)略和戰(zhàn)術(shù)建模確定了核心領(lǐng)域架構(gòu)，這個(gè)架構(gòu)是通過預(yù)先綜合討論決策的，考慮了更廣闊的業(yè)務(wù)問題，較之TDD應(yīng)用的業(yè)務(wù)需求層面更加宏觀。在已有核心模型基礎(chǔ)上我們也會(huì)發(fā)現(xiàn)測(cè)試用例的設(shè)計(jì)更容易從應(yīng)用視角出發(fā)，從而降低了測(cè)試設(shè)計(jì)的難度。

關(guān)于預(yù)先設(shè)計(jì)

如果沒有讀戰(zhàn)略篇直接看本文的讀者肯定會(huì)提出關(guān)于預(yù)先設(shè)計(jì)的顧慮，畢竟DDD是被敏捷開發(fā)圈子認(rèn)可的一種架構(gòu)方式，其目標(biāo)應(yīng)該是構(gòu)建架構(gòu)模型的響應(yīng)力。而這里給大家的更多是模式化的實(shí)現(xiàn)過程，好似從建模到代碼一切都預(yù)先設(shè)計(jì)好了。

值得強(qiáng)調(diào)的是，我們?nèi)匀环磳?duì)前期設(shè)計(jì)的大而全(Big-Design-Up-Front，BDUF)。 但我們應(yīng)該認(rèn)可前期對(duì)核心領(lǐng)域模型的分析和設(shè)計(jì)，這樣能夠幫助我們更快地響應(yīng)后續(xù)的業(yè)務(wù)變化(即在核心模型之上的應(yīng)用)。這不代表著核心領(lǐng)域模型未來會(huì)一成不變，或者不能改變，而是經(jīng)過統(tǒng)一建模的核心部分變化頻率較之外部應(yīng)用會(huì)低很多。如果核心領(lǐng)域模型也變化劇烈，那么我們可能就要考慮是否業(yè)務(wù)發(fā)生了根本性的變化，需要建立新的模型。

另外不能忘記我們預(yù)先定義的模型也是被局限在一個(gè)分解出來的核心問題域里的，也就是說我們并不希望一口氣把整個(gè)復(fù)雜的業(yè)務(wù)領(lǐng)域里的所有模型都建立起來。這種范圍的局限某種程度上也限制了我們預(yù)先設(shè)計(jì)的范圍，促使我們更多用迭代的方式來看待建模工作本身。

最后顯然我們應(yīng)該有一個(gè)核心團(tuán)隊(duì)來守護(hù)核心領(lǐng)域模型，這不代表著任何模型的設(shè)計(jì)和改動(dòng)都必須由這個(gè)團(tuán)隊(duì)的人做出(雖然有不少的團(tuán)隊(duì)確實(shí)是這樣落地DDD的)。我們期望的是任何對(duì)核心模型的改動(dòng)都能夠通過這個(gè)核心團(tuán)隊(duì)來促進(jìn)更大范圍的交流和溝通。檢驗(yàn)一個(gè)模型是否落地的唯一標(biāo)準(zhǔn)是應(yīng)用這個(gè)模型的團(tuán)隊(duì)能否就模型本身達(dá)成共識(shí)。在這點(diǎn)上我們看到很多團(tuán)隊(duì)持續(xù)通過代碼走查(code review)的方式在線上和線下實(shí)踐基于核心模型的交流，從而起到了真正意義上的“守護(hù)”作用，讓模型本身成為團(tuán)隊(duì)的共同責(zé)任。

實(shí)踐DDD時(shí)仍然需要遵循“模型是用來交流的”的這一核心原則。我們希望本文介紹的方法及模式能夠幫助大家更容易地交流領(lǐng)域模型，也算是對(duì)DDD戰(zhàn)略和戰(zhàn)術(shù)設(shè)計(jì)的一點(diǎn)補(bǔ)充。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文