客觀的理解DDD

DDD，即領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)，不僅帶給我們一套新的概念，還提供了一套全新的設(shè)計(jì)思路，應(yīng)用在構(gòu)建大型復(fù)雜軟件系統(tǒng)之上。

相對(duì)于DDD，我們使用的傳統(tǒng)的設(shè)計(jì)思路，常被稱為數(shù)據(jù)驅(qū)動(dòng)設(shè)計(jì)，常被應(yīng)用于中小型的項(xiàng)目?；ヂ?lián)網(wǎng)的項(xiàng)目，往往是快速迭代，起初一個(gè)小項(xiàng)目，慢慢會(huì)演化為一個(gè)中大型的項(xiàng)目，在演化過程中，很容易出現(xiàn)架構(gòu)腐化，內(nèi)部各模塊的邊界不清晰，耦合嚴(yán)重，所謂牽一發(fā)而動(dòng)全身，而此時(shí)，往往會(huì)重構(gòu)的方法來解決。然而重構(gòu)畢竟是個(gè)耗時(shí)費(fèi)力，對(duì)業(yè)務(wù)而言收益不直觀的事情，所以人們常常想，在長期的迭代中，如果能有一些方式能夠讓系統(tǒng)一直保持穩(wěn)定的架構(gòu)，清晰的邏輯，那么就能夠節(jié)省很多成本，甚至可以節(jié)省撰寫文檔的成本（代碼即文檔）。

對(duì)于問題的解決方案往往很多，Eric Evans為我們總結(jié)了一套DDD理論。其實(shí)解決問題的思路，不僅限于DDD，或者說，我們所理解的DDD，可以不同于Eric Evans所總結(jié)的那樣，只要是為解決問題行之有效的方式，都是值得推崇的。

DDD與傳統(tǒng)的設(shè)計(jì)思路，二者其實(shí)沒必要把各個(gè)點(diǎn)拿出來對(duì)比，其各有各的優(yōu)勢(shì)和劣勢(shì)，一概的追捧和否定某一個(gè)，都是不客觀的。我們解決不同類型的問題，會(huì)用不同的手段。在解決一個(gè)問題時(shí)，盡可能用最簡單的思路。對(duì)于那種不會(huì)進(jìn)行過多迭代的小型系統(tǒng)而言，沒必要使用DDD（或者DDD全套），它反而會(huì)給你帶來更多的問題，保持它的精簡是很有必要的。而大型的系統(tǒng)，或持續(xù)朝著大型系統(tǒng)方向迭代的系統(tǒng)，一些在小型系統(tǒng)中不容易凸顯的問題，就會(huì)慢慢被放大，凸顯（比如邏輯臃腫，模塊邊界不清晰）。使用簡單的設(shè)計(jì)思路，往往無法約束這些問題的擴(kuò)大。這個(gè)時(shí)候，就需要更多的細(xì)節(jié)規(guī)范來抑制問題產(chǎn)生，發(fā)展。因此也可能會(huì)產(chǎn)生更多的概念，這也是DDD概念很多的原因。

對(duì)于DDD的眾多概念，學(xué)習(xí)成本會(huì)變高，更是為落地增加了很多困難。一個(gè)項(xiàng)目下來，也許會(huì)伴隨著一個(gè)擔(dān)憂，那就是“一不小心就回到了傳統(tǒng)方式上”，最后覺得自己做了個(gè)“四不像”。其實(shí)我們要做的DDD，并不是說我們要完全按照Eric Evans所總結(jié)的那樣把所有內(nèi)容都按照理論概念來實(shí)踐，它只能起到指導(dǎo)作用，具體的情況，要結(jié)合自身公司，項(xiàng)目組成員，業(yè)務(wù)情況等因素來決定。這就好比是，馬克思主義理論，在中國的實(shí)踐，要結(jié)合中國的具體國情才可以。為了DDD而DDD，是沒有意義的。始終關(guān)注我們的目的，是個(gè)十分重要的原則，目的也決定了我們遇到一些細(xì)節(jié)技術(shù)的抉擇時(shí)如果做出取舍。

DDD在轉(zhuǎn)轉(zhuǎn)價(jià)格系統(tǒng)的實(shí)踐過程

業(yè)務(wù)理解

轉(zhuǎn)轉(zhuǎn)價(jià)格系統(tǒng)（估價(jià)器），是個(gè)十分復(fù)雜的系統(tǒng)，它承載著轉(zhuǎn)轉(zhuǎn)回收以及眾多賣場(chǎng)的價(jià)格計(jì)算和等級(jí)計(jì)算能力，同時(shí)提供價(jià)格實(shí)驗(yàn)?zāi)芰ΑＳ捎谙到y(tǒng)的復(fù)雜性高，以下介紹的內(nèi)容，是系統(tǒng)的一個(gè)簡版。

價(jià)格系統(tǒng)估價(jià)的大致流程是，估價(jià)器拿到驗(yàn)機(jī)報(bào)告后，首先進(jìn)行驗(yàn)機(jī)報(bào)告的解析，然后將驗(yàn)機(jī)報(bào)告轉(zhuǎn)換為估價(jià)項(xiàng)。然后根據(jù)請(qǐng)求的參數(shù)，找到合適的報(bào)價(jià)流程，在報(bào)價(jià)流程中執(zhí)行其所配置的報(bào)價(jià)方式進(jìn)行價(jià)格計(jì)算。

因?yàn)橛?jì)算價(jià)格是區(qū)分多種不同的場(chǎng)景的，比如如轉(zhuǎn)轉(zhuǎn)C2B線上回收，轉(zhuǎn)轉(zhuǎn)門店回收，轉(zhuǎn)轉(zhuǎn)B2C賣場(chǎng)，轉(zhuǎn)轉(zhuǎn)門店零售賣場(chǎng)等。不同的場(chǎng)景需要關(guān)聯(lián)的參數(shù)配置和報(bào)價(jià)方式都有所不同，所以我們這里抽象出一個(gè)概念“場(chǎng)景”，用來關(guān)聯(lián)這些參數(shù)配置和報(bào)價(jià)方式。

對(duì)價(jià)格的計(jì)算，一定是建立在客觀的商品各項(xiàng)情況，成色等基礎(chǔ)上的。轉(zhuǎn)轉(zhuǎn)作為專業(yè)的二手交易平臺(tái)，是能夠產(chǎn)出專業(yè)的驗(yàn)機(jī)報(bào)告的。那么對(duì)價(jià)格的計(jì)算，就依賴驗(yàn)機(jī)報(bào)告給出的數(shù)據(jù)。

轉(zhuǎn)轉(zhuǎn)的驗(yàn)機(jī)報(bào)告中的數(shù)據(jù)，都是驗(yàn)機(jī)工程師填寫的比較專業(yè)的，詳細(xì)的，豐富的驗(yàn)機(jī)項(xiàng)，如果直接拿給運(yùn)營人員對(duì)其進(jìn)行價(jià)格的維護(hù)，會(huì)有較大的維護(hù)成本。所以，需要將驗(yàn)機(jī)報(bào)告的項(xiàng)，通過一種關(guān)系，轉(zhuǎn)換為人工易維護(hù)的估價(jià)項(xiàng)，后續(xù)運(yùn)營人員對(duì)價(jià)格進(jìn)行維護(hù)時(shí)，就比較方便高效。這一步就是估價(jià)項(xiàng)轉(zhuǎn)換。

估價(jià)項(xiàng)轉(zhuǎn)換好后，就要執(zhí)行估價(jià)流程了。估價(jià)流程封裝了某一個(gè)或某幾個(gè)估價(jià)的方式或估價(jià)的算法，我們暫且叫它估價(jià)方式，如人工價(jià)格表，等級(jí)價(jià)格，算法模型等。除此之外，估價(jià)流程還封裝了不同估價(jià)方式的執(zhí)行過程，如B2C零售賣場(chǎng)優(yōu)先使用算法模型，如果無法給出價(jià)格，則使用人工價(jià)格表。最后根據(jù)這些邏輯，輸出一個(gè)價(jià)格。

在開始實(shí)踐之前，對(duì)于業(yè)務(wù)的理解十分重要，對(duì)于各個(gè)概念要做到統(tǒng)一語言，也就是消除團(tuán)隊(duì)成員之間的理解的偏差。我們的目標(biāo)，就是構(gòu)建一個(gè)架構(gòu)良好，可測(cè)試性強(qiáng)，學(xué)習(xí)成本低，易于擴(kuò)展和維護(hù)的系統(tǒng)。

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

通過對(duì)業(yè)務(wù)邏輯的理解，我們可以得到以下的子域劃分：

• 場(chǎng)景子域，通用域，為其他域提供配置參數(shù)。
• 驗(yàn)機(jī)報(bào)告解析子域，支撐域，為估價(jià)提供前置的數(shù)據(jù)支撐。
• 估價(jià)項(xiàng)轉(zhuǎn)換子域，支撐域，也是為估價(jià)提供前置的數(shù)據(jù)支撐。
• 報(bào)價(jià)流程子域，支撐域，為報(bào)價(jià)提供流程的封裝。
• 報(bào)價(jià)方式子域，核心域，提供報(bào)價(jià)的計(jì)算方式，這是業(yè)務(wù)的核心，需要花費(fèi)主要的精力。

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

這一步我們對(duì)限界上下文做設(shè)計(jì)。這里每一個(gè)限界上下文對(duì)應(yīng)一個(gè)子域，得到的領(lǐng)域模型詳細(xì)設(shè)計(jì)。例如下圖為驗(yàn)機(jī)報(bào)告解析上下文，綠色代表實(shí)體，黃色代表值對(duì)象。此上下文依賴外部的驗(yàn)機(jī)報(bào)告服務(wù)，使用防腐層來做適配。該上下文輸出解析后的驗(yàn)機(jī)報(bào)告。對(duì)于驗(yàn)機(jī)報(bào)告，每一個(gè)商品有唯一一份，存在唯一標(biāo)識(shí)，所以屬于一個(gè)實(shí)體。驗(yàn)機(jī)報(bào)告中，應(yīng)該包含商品的品類，品牌，型號(hào)，以及它的驗(yàn)機(jī)項(xiàng)，這三者都屬于值對(duì)象，被聚合為驗(yàn)機(jī)報(bào)告實(shí)體。

上下文集成

上下文集成可以簡單理解為，每一個(gè)上下文都是什么樣的關(guān)系。從概念上講，上下文集成關(guān)系有很多種：

• 分離方式 separate way
• 客戶-供應(yīng) customer/supplier
• 發(fā)布-訂閱 publisher/subscriber
• 開放主機(jī)服務(wù)和發(fā)布語言 open host service, publicshed language
• 防腐層 anti corruption layer
• 尊奉者 conformist
• 共享內(nèi)核 shared kernel
• 合作者 partnership

這其中很多概念應(yīng)用較少，引入過多的概念對(duì)于我們解決問題可能沒有太大意義，這里只采用“合作者”，“開放主機(jī)服務(wù)和發(fā)布語言”和“防腐層”。“合作者”能夠表示出本系統(tǒng)中兩個(gè)限界上線文的依賴關(guān)系，后兩者能夠表示出，與外部系統(tǒng)的限界上線文的依賴關(guān)系。其中“PS”代表合作關(guān)系，“U”代表上游，“D”代表下游，這里的上下游和依賴方向正好相反?！癆CL”代表防腐層，與“OHS/PL”開發(fā)主機(jī)服務(wù)和發(fā)布語言搭配使用。

架構(gòu)設(shè)計(jì)

架構(gòu)理論發(fā)展至今，各種新型的架構(gòu)不斷出現(xiàn)。除了我們常用的分層架構(gòu)外，還有整潔架構(gòu)，六邊形架構(gòu)，洋蔥架構(gòu)，CQRS架構(gòu)等。各有特色，各有利弊。出于學(xué)習(xí)成本，團(tuán)隊(duì)成員經(jīng)驗(yàn)的角度考慮，這里采用松散型（可跨層調(diào)用）的分層架構(gòu)。

api層作接口定義層，被其他服務(wù)所依賴。application層作應(yīng)用服務(wù)層，實(shí)現(xiàn)api層的接口。domain作領(lǐng)域?qū)樱瑢?shí)現(xiàn)核心的業(yè)務(wù)邏輯。infrastructure作基礎(chǔ)數(shù)據(jù)層，為上層提供數(shù)據(jù)接口和外部調(diào)用的防腐。

除了核心的估價(jià)業(yè)務(wù)邏輯外，系統(tǒng)還包含后臺(tái)維護(hù)的功能，這一部分多為數(shù)據(jù)的增刪查改操作，邏輯簡單，可以不進(jìn)入domain層，由application層直接從infrastructure獲取。

工程結(jié)構(gòu)和架構(gòu)一致，在此基礎(chǔ)上，每一層可能都會(huì)依賴相同的一些常量，工具，和基本算法，這些內(nèi)容可以單獨(dú)封裝為一個(gè)common的包。于是得到如下工程結(jié)構(gòu)：

evaluation_sys
? api
? application
? domain
? infrastructure
? common

業(yè)務(wù)邏輯實(shí)現(xiàn)

在使用傳統(tǒng)的mvc模式下，我們往往使用三層架構(gòu)，即controller，service，dao或者其類似的方式。這種架構(gòu)會(huì)把所有的業(yè)務(wù)邏輯堆積在service之下，領(lǐng)域?qū)嶓w只做數(shù)據(jù)傳輸，沒有行為。隨著項(xiàng)目的迭代，可能出現(xiàn)service臃腫的情況，大量業(yè)務(wù)邏輯，把service搞成一個(gè)胖子，業(yè)務(wù)邏輯就會(huì)變得混亂不堪，理解和維護(hù)成本極大。

然而我們希望代碼不僅僅是用來執(zhí)行的，更是用來閱讀的，表達(dá)的業(yè)務(wù)邏輯給人一目了然，一看就懂，是我們追求的。好的代碼結(jié)構(gòu)，就是要把各個(gè)業(yè)務(wù)邏輯按一定原則拆分開，再用一種機(jī)制將它們很好的組織在一起。按照DDD的思想，應(yīng)用服務(wù)編排領(lǐng)域服務(wù)，用以描述業(yè)務(wù)主干邏輯，每個(gè)領(lǐng)域的細(xì)節(jié)邏輯由領(lǐng)域服務(wù)封裝實(shí)現(xiàn)，這就把邏輯做了鮮明的分離。

如價(jià)格系統(tǒng)中，估價(jià)的應(yīng)用服務(wù)中是這樣實(shí)現(xiàn)的：

public EvaluateResult eval(Scenario scenario, EvaluateContext context) {
// 獲得驗(yàn)機(jī)報(bào)告
QcReport report = qcReportService.parseReport(context.getQcCode());
// 估價(jià)項(xiàng)轉(zhuǎn)換
EvaluateItems evaluateItems = evaluateItemsService.transfer(report, scenario);
// 執(zhí)行估價(jià)流程
EvaluateResult result = evaluateProcessService.evaluate(scenario, context, evaluateItems);
// 返回結(jié)果
return presult;
}

其次DDD提倡領(lǐng)域?qū)ο髶碛行袨椋@不僅僅是更加符合面向?qū)ο笏v的，讓對(duì)象貼近客觀世界，而且又一次的劃分了邏輯，讓領(lǐng)域服務(wù)中的主干邏輯和細(xì)節(jié)的邏輯實(shí)現(xiàn)做了鮮明的分離。如估價(jià)流程的領(lǐng)域服務(wù)是這樣實(shí)現(xiàn)的：

public class EvaluateProcessService {
public EvaluateResult evaluate(Scenario scenario, EvaluateContext context, EvaluateItems evaluateItems) {
// 獲取估價(jià)方式（或估價(jià)算法）
List algorithms = EvaluateAlgorithmFactory.create(scenario);
// 獲得估價(jià)流程
EvaluateProcess process = EvaluateProcessFactory.create(scenario, context, algorithms, evaluateItems);
// 執(zhí)行估價(jià)流程
reutrn process.evaluate();
}
// ...
}

其中一種估價(jià)流程的實(shí)現(xiàn)是這樣的：

/**
? 取最高價(jià)的估價(jià)流程實(shí)現(xiàn)
*/
public class MaxPriceEvaluateProcess implements EvaluateProcess {
// 對(duì)象屬性
private Scenario scenario;
private EvaluateProcess context;
private List algorithms;
private EvaluateItems evaluateItems;
/**? 對(duì)象行為，計(jì)算價(jià)格
*/
public EvaluateResult evaluate() {
long maxPrice = 0;
// 遍歷算法，分別計(jì)算價(jià)格
for (EvaluateAlgorithm algorithm : algorithms) {
long price = algorithm.calculate(context, evaluateItems);
if (maxPrice < price) {
maxPrice = price;
}
}
return new EvaluateResult(maxPrice);
}
// ...
}

經(jīng)過一級(jí)一級(jí)的邏輯拆分和組織，最終讓代碼有極強(qiáng)的可讀性，更加符合人的思考問題的方式，讓維護(hù)，學(xué)習(xí)更加容易。

寫在最后

DDD實(shí)踐，需要花費(fèi)大量的精力去學(xué)習(xí)理論，概念和前人實(shí)踐的案例，過程中還會(huì)出現(xiàn)很多的問題，很多的抉擇，能夠得到一個(gè)滿意的結(jié)果，絕不是一件輕松的事情。所以，再次強(qiáng)調(diào)，一定要明確自己的目的，我們不應(yīng)該懷著趕時(shí)髦的心態(tài)去實(shí)踐它，應(yīng)理性的思考是否真正的需要它。當(dāng)然對(duì)于DDD的實(shí)踐，書中所講述的思想，案例，往往不是全部適用于你的項(xiàng)目，哪些適合自己，哪些可以解決自己的問題，才是我們應(yīng)該思考的。（全文完）