如何正確理解并科學實踐DDD

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

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

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

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

對于DDD的眾多概念，學習成本會變高，更是為落地增加了很多困難，一個專案下來，也許會伴隨著一個擔憂，那就是“一不小心就回到了傳統方式上”，最后覺得自己做了個“四不像”，其實我們要做的DDD，并不是說我們要完全按照Eric Evans所總結的那樣把所有內容都按照理論概念來實踐，它只能起到指導作用，具體的情況，要結合自身公司，專案組成員，業務情況等因素來決定，這就好比是，馬克思主義理論，在中國的實踐，要結合中國的具體國情才可以，為了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的實踐，書中所講述的思想，案例，往往不是全部適用于你的專案，哪些適合自己，哪些可以解決自己的問題，才是我們應該思考的，