客觀的理解DDD

DDD，即領域驅動設計，不僅帶給我們一套新的概念，還提供了一套全新的設計思路，應用在構建大型復雜軟件系統之上。

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

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

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

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

DDD在轉轉價格系統的實踐過程

業務理解

轉轉價格系統（估價器），是個十分復雜的系統，它承載著轉轉回收以及眾多賣場的價格計算和等級計算能力，同時提供價格實驗能力。由于系統的復雜性高，以下介紹的內容，是系統的一個簡版。

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

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

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

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

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

在開始實踐之前，對于業務的理解十分重要，對于各個概念要做到統一語言，也就是消除團隊成員之間的理解的偏差。我們的目標，就是構建一個架構良好，可測試性強，學習成本低，易于擴展和維護的系統。

戰略設計

通過對業務邏輯的理解，我們可以得到以下的子域劃分：

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

戰術設計

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

上下文集成

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

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

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

架構設計

架構理論發展至今，各種新型的架構不斷出現。除了我們常用的分層架構外，還有整潔架構，六邊形架構，洋蔥架構，CQRS架構等。各有特色，各有利弊。出于學習成本，團隊成員經驗的角度考慮，這里采用松散型（可跨層調用）的分層架構。

api層作接口定義層，被其他服務所依賴。application層作應用服務層，實現api層的接口。domain作領域層，實現核心的業務邏輯。infrastructure作基礎數據層，為上層提供數據接口和外部調用的防腐。

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

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

evaluation_sys
? api
? application
? domain
? infrastructure
? common

業務邏輯實現

在使用傳統的mvc模式下，我們往往使用三層架構，即controller，service，dao或者其類似的方式。這種架構會把所有的業務邏輯堆積在service之下，領域實體只做數據傳輸，沒有行為。隨著項目的迭代，可能出現service臃腫的情況，大量業務邏輯，把service搞成一個胖子，業務邏輯就會變得混亂不堪，理解和維護成本極大。

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

如價格系統中，估價的應用服務中是這樣實現的：

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

其次DDD提倡領域對象擁有行為，這不僅僅是更加符合面向對象所講的，讓對象貼近客觀世界，而且又一次的劃分了邏輯，讓領域服務中的主干邏輯和細節的邏輯實現做了鮮明的分離。如估價流程的領域服務是這樣實現的：

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);
// 執行估價流程
reutrn process.evaluate();
}
// ...
}

其中一種估價流程的實現是這樣的：

/**
? 取最高價的估價流程實現
*/
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);
}
// ...
}

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

寫在最后

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