轉轉價格系統 DDD 實踐

客觀的理解 DDD

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

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

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

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

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

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

業務理解

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

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

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

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

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

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

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

戰略設計

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

戰術設計

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

上下文集成

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

這其中很多概念應用較少，引入過多的概念對於我們解決問題可能沒有太大意義，這裏只採用 “合作者”，“開放主機服務和發佈語言” 和“防腐層”。“合作者”能夠表示出本系統中兩個限界上線文的依賴關係，後兩者能夠表示出，與外部系統的限界上線文的依賴關係。其中 “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<EvaluateAlgorithm> 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<EvaluateAlgorithm> 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 的實踐，書中所講述的思想，案例，往往不是全部適用於你的項目，哪些適合自己，哪些可以解決自己的問題，纔是我們應該思考的。（全文完）

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/5Spjq7wivXKH5q5gSE0K6w

猜你喜歡