1. 背景

DDD 是一個門檻很高的設計方法，里面涉及眾多概念，各概念間相互關聯(lián)相互制約，大大增加了落地的難度。但，當真正落地之后，你會發(fā)現(xiàn)還是有很多技巧能大幅降低學習成本，實現(xiàn)快速上手。

學習 DDD 最關鍵的一點便是：使用面向對象思維去思考問題。

這個說起來很抽象，面向對象其實很簡單，就像孩子們玩的樂高積木：

• 【組件】每個小積木都有自己的形狀（對象自身功能），也都有自己的凸起或插槽（對象暴露的接口或能力）；
• 【關系】多個小積木可以組裝成一個大積木，多個大積木可以組裝成更大的積木（通過對象間的組合實現(xiàn)更強大的功能）；
• 【功能】多個大積木最終組成“藝術品”（通過對象間的協(xié)作實現(xiàn)某個功能）；
• 在 DDD 中也是一樣的：
• 【組件】聚合根是DDD中最核心的組件，對內維護高內聚的對象集合，對外提供原子業(yè)務能力；
• 【關系】應用服務、領域服務、領域事件 對多個組件進行編排，實現(xiàn)業(yè)務流程；
• 【功能】領域內部能力 通過 應用服務 暴露給外部調用者，從而滿足業(yè)務需求；

2. 原子能力

這里的原子能力主要指的是聚合根所提供的業(yè)務方法，從業(yè)務或技術視角都是不可拆分的最小操作單元。

2.1. 聚合根

在 DDD 中，聚合根是一個重要的概念，它是一組具有內在一致性的相關對象的根，用來限制對象的邊界，可以保證聚合內部的對象間關聯(lián)關系和業(yè)務規(guī)則得到統(tǒng)一的管理和維護。

聚合根是聚合的一個實體，作為整個聚合的唯一入口點，通過它才能訪問整個聚合。在DDD中，聚合被定義為一組相關對象的集合，這些對象在業(yè)務上有著緊密的聯(lián)系，需要被當作一個整體來對待。聚合根是這個整體的根節(jié)點，它負責維護整個聚合的完整性和一致性。

很抽象，讓我們看個示例：

電商訂單系統(tǒng)主要由以下幾個實體組成：

• 訂單（Order）。記錄用戶的一次生單，主要保存用戶、支付金額、訂單狀態(tài)等；
• 訂單項（OrderItem）。購買的單個商品，主要保存商品單價、售價、應付金額等；
• 支付記錄（Pay）。用戶的支付信息，包括支付渠道、支付金額、支付時間等；
• 收貨地址（Address）。用戶的收貨地址；

這幾個實體存在非常強的一致性保障，特別是在金額方面：

• 訂單的支付金額等于所有訂單項金額總和；
• 支付記錄的待支付金額必須與訂單支付金額一致；

如何保障訂單、訂單項、支付記錄上的金額是強一致的呢？小心編碼+謹慎測試？

那加入更多的應用場景又該怎么處理呢？比如 優(yōu)惠券、優(yōu)惠活動、手工改價、調整快遞費用等，這將變成一個燙手山芋。

解決方案便是將這幾個實體作為一個整體來思考，也就是聚合的概念。

聚合是DDD的一種設計模式，它的本質是建立比對象粒度更大的邊界，聚合了那些緊密聯(lián)系的對象，形成了一個業(yè)務上的整體。

圖片

如上圖所示：

• Order、OrderItem、Pay 和 Address 不在單獨處理，而是組成了一個更大的對象，也就是聚合；
• Order 是這個聚合的聚合根，對內協(xié)調各個對象，對外提供唯一的訪問入口；
• OrderItem、Pay、Address 作為非聚合根的內部實體，不可直接對外提供服務，僅接受 Order 的調用；

這樣的調整，能否保障 Order、OrderItem、Pay 三者間的強一致關系呢？讓我們從代碼層面進行細致分析：

生單：

// 靜態(tài)工廠，封裝復雜的 Order 創(chuàng)建邏輯，并保障創(chuàng)建的 Order 對象是有效的
public static Order create(CreateOrderCommand createOrderCommand) {
    Order order = new Order(createOrderCommand.getUserId());
    order.setAddress(Address.create(createOrderCommand));
    order.setPay(new Pay());
    order.addItems(createOrderCommand.getItems());
    order.init();
    return order;
}

// 添加 OrderItem，并計算總金額
private void addItems(List<OrderItemDTO> items) {
    if (!CollectionUtils.isEmpty(items)){
        items.forEach(item ->{
            // orderItem.setPrice(orderItem.getPrice() * orderItem.getQuantity());
            OrderItem orderItem = OrderItem.create(item);
            this.orderItems.add(orderItem);
            this.totalSellingPrice += item.getPrice();
        });
    }
    this.totalPrice = totalSellingPrice;
    this.pay.updatePrice(this.totalPrice);
}

// 設置狀態(tài)完成對象的初始化
private void init() {
    this.status = OrderStatus.CREATED;
}

所有流程全部封裝在 Order 的靜態(tài)方法 create 上，包括：

• 構建內部實體。根據(jù)輸入信息創(chuàng)建 Pay、Address 等關聯(lián)實體；
• 金額計算。創(chuàng)建 OrderItem 實體并添加到集合中，在添加流程完成金額計算：

根據(jù)單價和購買數(shù)量計算 OrderItem 需付金額；

對 OrderItem 需付金額進行累計，更新 Order 的需支付金額；

將 Order 需付金額同步到 Pay 實體；

• 設置訂單狀態(tài)。調用 init 方法，將訂單狀態(tài)設置為 CREATED；

然后看下改價流程:

public void changePrice(Long newPrice) {
    if (newPrice <= 0) {
        throw new IllegalArgumentException("金額必須大于0");
    }

    long discount = getTotalPrice() - newPrice;
    if (discount == 0){
        return;
    }
    // Item 均攤折扣
    discountForItem(discount);
    // Order 折扣
    discountForOrder(discount);
    // Pay 折扣
    syncForPay();
}

// Item 均攤
private void discountForItem(long discount) {
    Long totalAmount = getTotalPrice();
    Long allocatedDiscount = 0L;

    for (int i = 0; i < getOrderItems().size(); i++) {
        OrderItem item = getOrderItems().get(i);
        Long itemAmount = item.getSellingPrice();
        if (i != getOrderItems().size() - 1) {
            // 按比例進行均攤
            Long itemDiscount = itemAmount / totalAmount * discount;
            // 重新設置金額
            item.setPrice(item.getPrice() - itemDiscount);
            // 記錄累加金額
            allocatedDiscount += itemDiscount;
        }else {
            // 分攤余下的優(yōu)惠金額到最后一個訂單
            Long lastItemDiscount = discount - allocatedDiscount;
            item.setPrice(item.getPrice() - lastItemDiscount);
        }
    }
}
// Order 折扣
private void discountForOrder(long discount) {
    Long newTotalPrice = getTotalPrice() - discount;
    setTotalPrice(newTotalPrice);
}
// 將價格同步到 Pay
private void syncForPay() {
    this.pay.updatePrice(getTotalPrice());
}

改價流程由 Order 的實體方法 changePrice 承載，核心流程如下：

• 入?yún)⑿ｒ?。修改后的金額不可為負數(shù)；
• Item金額均攤。按OrderItem金額對折扣信息按比例進行均攤，并更新 Item 上的應付金額；
• Order金額更新。重新計算 Order 應付金額并對金額進行更新（也可以使用所有 Item 的金額總和）；
• Pay金額同步。將Order上的最新金額同步到 Pay 實體；

如此操作，便可以保證聚合根內各個實體對象間的強一致性關系。

那原子能力又體現(xiàn)在哪呢？

• 不可分割。從業(yè)務視角，每個操作都是一個不可被拆分的最小執(zhí)行單元；從技術視角，操作過程不會被打斷；
• 不可破壞規(guī)則。必須從一個有效狀態(tài)轉換到另一個有效狀態(tài)，聚合根內多個實體間的業(yè)務規(guī)則不允許被破壞；
• 持久化層的原子性保障。整個聚合根的狀態(tài)要么全部更新到DB，要么全不更新，不允許只更新部分信息；

聚合根上的這些“原子業(yè)務”操作形成了聚合根的生命周期，如下圖所示：

圖片

這是 Order 聚合根的生命周期，每個業(yè)務操作均由以下部分組成：

• 業(yè)務驗證。包括入?yún)⑿ｒ?、前置條件校驗；
• 狀態(tài)或數(shù)據(jù)更新。對聚合內實體狀態(tài)或數(shù)據(jù)進行更新；
• 領域事件發(fā)布。對外發(fā)布領域事件；

以訂單的支付成功為例：

public void paySuccess(){
    // 前置校驗
    if (getStatus() != OrderStatus.CREATED){
        throw new RuntimeException("非待支付狀態(tài)，無法操作");
    }

    // 更新狀態(tài)
    setStatus(OrderStatus.PAID);
    // 如果 OrderItem 需要更新的話進行調用
    // paySuccessForItem();

    // 發(fā)布事件
    publishEvent(new OrderPaidEvent(this));
}

2.2. 聚合根設計原則

想設計出好的聚合根非常不容易，需要豐富的經(jīng)驗，更需要對領域概念有很深的認知，但有些原則可以幫助你避免不少坑：

1. 盡量簡單。聚合根不應該包含太多的業(yè)務對象，應該保持簡單，以保證可維護性；
2. 對內部實體提供保護。非聚合根實體或值對象只能通過聚合根來間接訪問，不能被外部直接訪問；
3. 業(yè)務操作具備原子性。內部實體操作必須滿足聚合根的業(yè)務規(guī)則，以保證數(shù)據(jù)的一致性和完整性；
4. 謹慎處理與其他聚合根的關系。聚合根不能包含其它聚合根的引用，聚合根之間可以通過 ID 引用來關聯(lián)，而不能直接引用其它聚合根，以避免概念的擴大；
5. 有效的版本管理。聚合根是狀態(tài)變化的載體，為了避免并發(fā)情況下狀態(tài)不一致，需要有效的版本管理對其進行保障，比如最常見的樂觀鎖機制；
6. 具有清晰的職責。聚合根只處理自己的領域問題，不應該處理其它聚合根的領域問題；

2.3. 聚合根的優(yōu)勢

聚合根的引入會對系統(tǒng)產(chǎn)生非常大的影響，具體如下：

1. 簡化系統(tǒng)架構。使用聚合根將整個領域劃分為多個聚合，可以使系統(tǒng)架構更加清晰。每個聚合都有自己的聚合根，聚合根之間只有松散的關聯(lián)，這樣可以降低系統(tǒng)的復雜度和耦合度；
2. 提高系統(tǒng)性能。聚合根可以作為一組數(shù)據(jù)的操作單元，因此可以減少數(shù)據(jù)庫的訪問次數(shù)。例如，在多次更新一個聚合后，最終狀態(tài)只需要一次數(shù)據(jù)庫操作便能完成；
3. 支持并發(fā)處理。使用聚合根可以支持更好的并發(fā)處理，聚合是一個最小的操作單元，同一聚合可以使用樂觀鎖等機制來控制并發(fā)，而聚合之間不存在共享數(shù)據(jù)可以進行并行處理；
4. 提高可測試性。將整個領域劃分為多個聚合，可以將測試場景限定在單個聚合內，從而提高測試的可控性和可重復性；

3. 流程編排

有了小“積木塊”（聚合根上的原子業(yè)務操作），接下來就是如何將其組裝成更大的業(yè)務操作。常見的編排方式有：

1. 應用服務。對模型中的組件進行編排，為調用者提供完整的業(yè)務能力，比如生單、改價等；
2. 領域服務。應用服務之下，主要解決跨聚合根操作的業(yè)務流程，比如轉賬等；
3. 事件編排。應用服務之上，對多個業(yè)務域的操作進行編排，實現(xiàn)聚合間、服務間的解耦，比如支付成功后需要給用戶發(fā)送短信等；

3.1. 應用服務

應用服務是DDD中重要的一層，它主要根據(jù)業(yè)務場景對流程進行編排，從而滿足不同場景對領域能力的不同訴求。應用服務位于領域層和接口層之間，對內統(tǒng)一協(xié)調多個組件，對外滿足不同場景下的 User Story。

下圖是應用服務所在的位置：

圖片

簡單一句話形容便是：應用服務在領域模型各個組件的能力之上進行流程編排，以滿足上層不同場景下的業(yè)務需求。

應用服務使用最多的便是對單個聚合的流程編排，主要包括創(chuàng)建和更新：

創(chuàng)建流程如下：

圖片

更新流程如下：

圖片

兩者最大的區(qū)別在于聚合根獲取方式：

• 創(chuàng)建流程，使用工廠完成復雜對象的創(chuàng)建，從而開啟聚合的生命周期；
• 更新流程，使用倉庫從持久化存儲中恢復聚合對象，從而推動聚合生命周期的演進；

那這個的價值在哪呢？因為規(guī)范所以可以做到非常好的封裝，具體見代碼：

生單并改價流程編排：

@Transactional
public void createAndChangePrice(CreateOrderAndChangePriceCommand command) {
    // 1. 檢查庫存，如果足夠則進行鎖定；如果不夠，則拋出異常
    this.inventoryService.checkIsEnoughAndLock(command.getItems());

    // 2. 流程編排
    // 設置存儲倉庫
    creatorFor(this.orderRepository)
            // 配置事件發(fā)布器
            .publishBy(eventPublisher)
            // 配置聚合根初始化
            .instance(() -> Order.create(command))
            // 配置執(zhí)行額外操作
            .update(order -> order.changePrice(command.getNewPrice()))
            // 執(zhí)行操作
            .call();
}

支付成功流程編排：

@Transactional
public void paySuccess(Long orderId){
    // 流程編排
    // 設置存儲倉庫
    updaterFor(this.orderRepository)
            // 設置 id
            .id(orderId)
            // 配置事件發(fā)布器
            .publishBy(this.eventPublisher)
            // 未找到時拋出異常
            .onNotExist(id -> new AggregateNotFountException(id))
            // 配置業(yè)務動作
            .update(order -> order.paySuccess())
            // 執(zhí)行操作
            .call();

}

代碼的可讀性得到很大的提升。

3.2. 領域服務

領域服務通常是無狀態(tài)操作，當一些職責不適合放在任何一個領域對象上時，我們可以考慮將其放在一個領域服務中。

整個流程是一個標準的業(yè)務概念，并且流程中涉及多個領域對象，當這個操作放在哪個領域對象上都不合適時，可以將其放在一個單獨的服務中，這個服務就是領域服務。

領域服務只做流程編排，不直接處理業(yè)務邏輯，業(yè)務邏輯直接調用領域模型中的其他對象。

一個例子就是轉賬，“轉賬”作為一個標準的業(yè)務概念，需要提供一個轉賬服務來承載這個領域概念。轉賬服務需要協(xié)調兩個領域對象：源賬戶和目標賬戶，源賬號做轉出，目標賬號做轉入，從而實現(xiàn)轉賬邏輯。

簡單的單機場景可以基于數(shù)據(jù)庫事務進行保障，具體如下：

圖片

image

從嚴格意義上講，在一個事務中只能對一個聚合進行修改，這條原則更適合于分布式系統(tǒng)。在單機系統(tǒng)中，直接使用數(shù)據(jù)庫本地事務對一致性進行保障，是一種投入產(chǎn)出比極高的事情。

在復雜的分布式場景需要引入“協(xié)調器”來對流程進行總控，以實現(xiàn)系統(tǒng)的最終一致性，具體如下：

圖片

image

【注】領域服務只做流程編排，不處理業(yè)務邏輯！?。。?/p>

領域服務不會直接暴露給業(yè)務方使用，而是由應用服務負責協(xié)作。切記應用服務是領域模型的門面（Facade）。

領域服務是基于面向過程編程范式構建的，目的是降低領域模型之間的耦合關系。切記不要被濫用，將太多的邏輯放在領域服務中，這會導致領域服務變得臃腫和難以維護。

3.3. 領域事件編排

領域事件是一種輕量級的通信機制，聚合根可以發(fā)布領域事件來通知其他聚合根或外部系統(tǒng)發(fā)生了某個事件，而其他聚合根或外部系統(tǒng)則可以訂閱這些事件，進行相應的處理，從而推動流程向下發(fā)展。

在系統(tǒng)中，基于領域事件的流程編排極為重要，他是系統(tǒng)間解耦的利器，也是分布式環(huán)境下最終一致性的保障。

首先，看一個簡單場景：

圖片

訂單支付成功后，向外發(fā)布領域事件，下游接受到領域事件后，做如下動作：

• 為用戶發(fā)送購買成功的短信通知；
• 為用戶增加積分；
• 通知倉庫進行發(fā)貨；

然后，看一個更復雜的外賣場景：

圖片

在分布式系統(tǒng)中極為常見，將事件串聯(lián)起來從而完成一個復雜的業(yè)務操作：

• 用戶完成支付，訂單服務向外發(fā)布“支付成功”事件；
• 餐廳服務接收到“支付成功”事件后，執(zhí)行下單動作，將菜品增加到大廚的制菜清單上；
• 餐廳做完菜后對外發(fā)送“飯菜準備好”事件；
• 物流系統(tǒng)接收到“飯菜準備好”事件后，通知外賣小哥上門取餐（這點不太合適，應該是支付成功后，快遞小哥便收到通知。為了更好的描述流程，先忽略現(xiàn)實操作）
• 快遞小哥完成取餐、送餐后，物流系統(tǒng)發(fā)出“外賣已送達”事件；
• 訂單服務接收到“外賣已送到”事件后，更新訂單為“已完成”狀態(tài)；

不管簡單場景還是復雜場景，事件玩的就是一個連線游戲：

• 各個系統(tǒng)已經(jīng)提供了豐富的業(yè)務操作，也就是游戲中的“節(jié)點”；
• MQ中間件是一個標準的橋梁，用于連接消息發(fā)送方和訂閱方，也就是游戲中的“線”；
• 根據(jù)業(yè)務流程，將業(yè)務操作與消息發(fā)送端&消費端鏈接起來，并完成了整個業(yè)務操作；

4. 小節(jié)

在一個系統(tǒng)中，“元素”的數(shù)量是有限的，“元素”間的“關系”是無限的。我們需要用好流程編排這把利器，在有限“元素”基礎上，構建無限的“關系”，從而應對多變的業(yè)務場景。

• 原子能力。主要以聚合根為中心，對外暴露的各種 原子業(yè)務操作；
• 流程編排。通過多種手段，將原子能力和基礎設施編排起來，最終實現(xiàn)業(yè)務需求：

應用服務。對領域模型中的組件進行組裝，以實現(xiàn)不同的業(yè)務訴求；

領域服務。對于有明確的業(yè)務概念，但找不到合適的領域對象作承載的操作，可以封裝成領域服務；

領域事件編排。主要解決聚合之間、服務之間耦合問題，對于有明確的 “因果” 關系的場景最為實用；