客觀的理解DDD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上下文集成

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

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

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

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

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

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

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

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

evaluation_sys
? api
? application
? domain
? infrastructure
? common

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

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

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

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

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

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

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

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

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

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

寫在最后

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