殷浩詳解 DDD：如何避免寫流水賬代碼？

在日常工作中我觀察到，面對老系統重構和遷移場景，有大量代碼屬於流水賬代碼，通常能看到開發在對外的 API 接口裏直接寫業務邏輯代碼，或者在一個服務裏大量的堆接口，導致業務邏輯實際無法收斂，接口複用性比較差。所以本文主要想系統性的解釋一下如何通過 DDD 的重構，將原有的流水賬代碼改造爲邏輯清晰、職責分明的模塊。

一案例簡介

這裏舉一個簡單的常見案例：下單鏈路。假設我們在做一個 checkout 接口，需要做各種校驗、查詢商品信息、調用庫存服務扣庫存、然後生成訂單：

一個比較典型的代碼如下：

@RestController
@RequestMapping("/")
public class CheckoutController {
    @Resource
    private ItemService itemService;
    @Resource
    private InventoryService inventoryService;
    @Resource
    private OrderRepository orderRepository;
    @PostMapping("checkout")
    public Result<OrderDO> checkout(Long itemId, Integer quantity) {
        // 1) Session管理
        Long userId = SessionUtils.getLoggedInUserId();
        if (userId <= 0) {
            return Result.fail("Not Logged In");
        }
        // 2）參數校驗
        if (itemId <= 0 || quantity <= 0 || quantity >= 1000) {
            return Result.fail("Invalid Args");
        }
        // 3）外部數據補全
        ItemDO item = itemService.getItem(itemId);
        if (item == null) {
            return Result.fail("Item Not Found");
        }
        // 4）調用外部服務
        boolean withholdSuccess = inventoryService.withhold(itemId, quantity);
        if (!withholdSuccess) {
            return Result.fail("Inventory not enough");
        }
        // 5）領域計算
        Long cost = item.getPriceInCents() * quantity;
        // 6）領域對象操作
        OrderDO order = new OrderDO();
        order.setItemId(itemId);
        order.setBuyerId(userId);
        order.setSellerId(item.getSellerId());
        order.setCount(quantity);
        order.setTotalCost(cost);
        // 7）數據持久化
        orderRepository.createOrder(order);
        // 8）返回
        return Result.success(order);
    }
}

爲什麼這種典型的流水賬代碼在實際應用中會有問題呢？其本質問題是違背了 SRP（Single Responsbility Principle）單一職責原則。這段代碼裏混雜了業務計算、校驗邏輯、基礎設施、和通信協議等，在未來無論哪一部分的邏輯變更都會直接影響到這段代碼，當後人不斷地在上面疊加新的邏輯時，會使代碼複雜度增加、邏輯分支越來越多，最終造成 bug 或者沒人敢重構的歷史包袱。

所以我們才需要用 DDD 的分層思想去重構一下以上的代碼，通過不同的代碼分層和規範，拆分出邏輯清晰，職責明確的分層和模塊，也便於一些通用能力的沉澱。

主要的幾個步驟分爲：

分離出獨立的 Interface 接口層，負責處理網絡協議相關的邏輯。
從真實業務場景中，找出具體用例（Use Cases），然後將具體用例通過專用的 Command 指令、Query 查詢、和 Event 事件對象來承接。
分離出獨立的 Application 應用層，負責業務流程的編排，響應 Command、Query 和 Event。每個應用層的方法應該代表整個業務流程中的一個節點。
處理一些跨層的橫切關注點，如鑑權、異常處理、校驗、緩存、日誌等。

下面會針對每個點做詳細的解釋。

二 Interface 接口層

隨着 REST 和 MVC 架構的普及，經常能看到開發同學直接在 Controller 中寫業務邏輯，如上面的典型案例，但實際上 MVC Controller 不是唯一的重災區。以下的幾種常見的代碼寫法通常都可能包含了同樣的問題：

HTTP 框架：如 Spring MVC 框架，Spring Cloud 等。
RPC 框架：如 Dubbo、HSF、gRPC 等。
消息隊列 MQ 的 “消費者”：比如 JMS 的 onMessage，RocketMQ 的 MessageListener 等。
Socket 通信：Socket 通信的 receive、WebSocket 的 onMessage 等。
文件系統：WatcherService 等。
分佈式任務調度：SchedulerX 等。

這些的方法都有一個共同的點就是都有自己的網絡協議，而如果我們的業務代碼和網絡協議混雜在一起，則會直接導致代碼跟網絡協議綁定，無法被複用。

所以，在 DDD 的分層架構中，我們單獨會抽取出來 Interface 接口層，作爲所有對外的門戶，將網絡協議和業務邏輯解耦。

1 接口層的組成

接口層主要由以下幾個功能組成：

網絡協議的轉化：通常這個已經由各種框架給封裝掉了，我們需要構建的類要麼是被註解的 bean，要麼是繼承了某個接口的 bean。
統一鑑權：比如在一些需要 AppKey+Secret 的場景，需要針對某個租戶做鑑權的，包括一些加密串的校驗
Session 管理：一般在面向用戶的接口或者有登陸態的，通過 Session 或者 RPC 上下文可以拿到當前調用的用戶，以便傳遞給下游服務。
限流配置：對接口做限流避免大流量打到下游服務
前置緩存：針對變更不是很頻繁的只讀場景，可以前置結果緩存到接口層
異常處理：通常在接口層要避免將異常直接暴露給調用端，所以需要在接口層做統一的異常捕獲，轉化爲調用端可以理解的數據格式
日誌：在接口層打調用日誌，用來做統計和 debug 等。一般微服務框架可能都直接包含了這些功能。

當然，如果有一個獨立的網關設施 / 應用，則可以抽離出鑑權、Session、限流、日誌等邏輯，但是目前來看 API 網關也只能解決一部分的功能，即使在有 API 網關的場景下，應用裏獨立的接口層還是有必要的。

在 Interface 層，鑑權、Session、限流、緩存、日誌等都比較直接，只有一個異常處理的點需要重點說下。

2 返回值和異常處理規範，Result vs Exception

注：這部分主要還是面向 REST 和 RPC 接口，其他的協議需要根據協議的規範產生返回值。

在我見過的一些代碼裏，接口的返回值比較多樣化，有些直接返回 DTO 甚至 DO，另一些返回 Result。

接口層的核心價值是對外，所以如果只是返回 DTO 或 DO 會不可避免的面臨異常和錯誤棧泄漏到使用方的情況，包括錯誤棧被序列化反序列化的消耗。所以，這裏提出一個規範：

Interface 層的 HTTP 和 RPC 接口，返回值爲 Result，捕捉所有異常

Application 層的所有接口返回值爲 DTO，不負責處理異常

Application 層的具體規範等下再講，在這裏先展示 Interface 層的邏輯。

舉個例子：

@PostMapping("checkout")
public Result<OrderDTO> checkout(Long itemId, Integer quantity) {
    try {
        CheckoutCommand cmd = new CheckoutCommand();
        OrderDTO orderDTO = checkoutService.checkout(cmd);    
        return Result.success(orderDTO);
    } catch (ConstraintViolationException cve) {
        // 捕捉一些特殊異常，比如Validation異常
        return Result.fail(cve.getMessage());
    } catch (Exception e) {
        // 兜底異常捕獲
        return Result.fail(e.getMessage());
    }
}

當然，每個接口都要寫異常處理邏輯會比較煩，所以可以用 AOP 做個註解：

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface ResultHandler {
}
@Aspect
@Component
public class ResultAspect {
    @Around("@annotation(ResultHandler)")
    public Object logExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable {
        Object proceed = null;
        try {
            proceed = joinPoint.proceed();
        } catch (ConstraintViolationException cve) {
            return Result.fail(cve.getMessage());
        } catch (Exception e) {
            return Result.fail(e.getMessage());
        }
        return proceed;
    }
}

然後最終代碼則簡化爲：

@PostMapping("checkout")
@ResultHandler
public Result<OrderDTO> checkout(Long itemId, Integer quantity) {
    CheckoutCommand cmd = new CheckoutCommand();
    OrderDTO orderDTO = checkoutService.checkout(cmd);
    return Result.success(orderDTO);
}

3 接口層的接口的數量和業務間的隔離

在傳統 REST 和 RPC 的接口規範中，通常一個領域的接口，無論是 REST 的 Resource 資源的 GET/POST/DELETE，還是 RPC 的方法，是追求相對固定的，統一的，而且會追求統一個領域的方法放在一個領域的服務或 Controller 中。

但是我發現在實際做業務的過程中，特別是當支撐的上游業務比較多時，刻意去追求接口的統一通常會導致方法中的參數膨脹，或者導致方法的膨脹。舉個例子：假設有一個寵物卡和一個親子卡的業務公用一個開卡服務，但是寵物需要傳入寵物類型，親子的需要傳入寶寶年齡。

// 可以是RPC Provider 或者 Controller
public interface CardService {
    // 1）統一接口，參數膨脹
    Result openCard(int petType, int babyAge);
    // 2）統一泛化接口，參數語意丟失
    Result openCardV2(Map<String, Object> params);
    // 3）不泛化，同一個類裏的接口膨脹
    Result openPetCard(int petType);
    Result openBabyCard(int babyAge);
}

可以看出來，無論怎麼操作，都有可能導致 CardService 這個服務未來越來越難以維護，方法越來越多，一個業務的變更有可能會導致整個服務 / Controller 的變更，最終變得無法維護。我曾經參與過的一個服務，提供了幾十個方法，上萬行代碼，可想而知無論是使用方對接口的理解成本還是對代碼的維護成本都是極高的。

所以，這裏提出另一個規範：

一個 Interface 層的類應該是 “小而美” 的，應該是面向 “一個單一的業務” 或“一類同樣需求的業務”，需要儘量避免用同一個類承接不同類型業務的需求。

基於上面的這個規範，可以發現寵物卡和親子卡雖然看起來像是類似的需求，但並非是 “同樣需求” 的，可以預見到在未來的某個時刻，這兩個業務的需求和需要提供的接口會越走越遠，所以需要將這兩個接口類拆分開：

public interface PetCardService {
    Result openPetCard(int petType);
}
public interface BabyCardService {
    Result openBabyCard(int babyAge);
}

這個的好處是符合了 Single Responsibility Principle 單一職責原則，也就是說一個接口類僅僅會因爲一個（或一類）業務的變化而變化。一個建議是當一個現有的接口類過度膨脹時，可以考慮對接口類做拆分，拆分原則和 SRP 一致。

也許會有人問，如果按照這種做法，會不會產生大量的接口類，導致代碼邏輯重複？答案是不會，因爲在 DDD 分層架構裏，接口類的核心作用僅僅是協議層，每類業務的協議可以是不同的，而真實的業務邏輯會沉澱到應用層。也就是說 Interface 和 Application 的關係是多對多的：

因爲業務需求是快速變化的，所以接口層也要跟着快速變化，通過獨立的接口層可以避免業務間相互影響，但我們希望相對穩定的是 Application 層的邏輯。所以我們接下來看一下 Application 層的一些規範。

三 Application 層

1 Application 層的組成部分

Application 層的幾個核心類：

ApplicationService 應用服務：最核心的類，負責業務流程的編排，但本身不負責任何業務邏輯。
DTO Assembler：負責將內部領域模型轉化爲可對外的 DTO。
Command、Query、Event 對象：作爲 ApplicationService 的入參。
返回的 DTO：作爲 ApplicationService 的出參。

Application 層最核心的對象是 ApplicationService，它的核心功能是承接 “業務流程 “。但是在講 ApplicationService 的規範之前，必須要先重點的講幾個特殊類型的對象，即 Command、Query 和 Event。

2 Command、Query、Event 對象

從本質上來看，這幾種對象都是 Value Object，但是從語義上來看有比較大的差異：

Command 指令：指調用方明確想讓系統操作的指令，其預期是對一個系統有影響，也就是寫操作。通常來講指令需要有一個明確的返回值（如同步的操作結果，或異步的指令已經被接受）。
Query 查詢：指調用方明確想查詢的東西，包括查詢參數、過濾、分頁等條件，其預期是對一個系統的數據完全不影響的，也就是隻讀操作。
Event 事件：指一件已經發生過的既有事實，需要系統根據這個事實作出改變或者響應的，通常事件處理都會有一定的寫操作。事件處理器不會有返回值。這裏需要注意一下的是，Application 層的 Event 概念和 Domain 層的 DomainEvent 是類似的概念，但不一定是同一回事，這裏的 Event 更多是外部一種通知機制而已。

簡單總結下：

爲什麼要用 CQE 對象？

通常在很多代碼裏，能看到接口上有多個參數，比如上文中的案例：

Result<OrderDO> checkout(Long itemId, Integer quantity);

如果需要在接口上增加參數，考慮到向前兼容，則需要增加一個方法：

Result<OrderDO> checkout(Long itemId, Integer quantity);
Result<OrderDO> checkout(Long itemId, Integer quantity, Integer channel);

或者常見的查詢方法，由於條件的不同導致多個方法：

List<OrderDO> queryByItemId(Long itemId);
List<OrderDO> queryBySellerId(Long sellerId);
List<OrderDO> queryBySellerIdWithPage(Long sellerId, int currentPage, int pageSize);

可以看出來，傳統的接口寫法有幾個問題：

接口膨脹：一個查詢條件一個方法。
難以擴展：每新增一個參數都有可能需要調用方升級。
難以測試：接口一多，職責隨之變得繁雜，業務場景各異，測試用例難以維護。

但是另外一個最重要的問題是：這種類型的參數羅列，本身沒有任何業務上的” 語意 “，只是一堆參數而已，無法明確的表達出來意圖。

CQE 的規範

所以在 Application 層的接口裏，強力建議的一個規範是：

ApplicationService 的接口入參只能是一個 Command、Query 或 Event 對象，CQE 對象需要能代表當前方法的語意。唯一可以的例外是根據單一 ID 查詢的情況，可以省略掉一個 Query 對象的創建。

按照上面的規範，實現案例是：

public interface CheckoutService {
    OrderDTO checkout(@Valid CheckoutCommand cmd);
    List<OrderDTO> query(OrderQuery query);
    OrderDTO getOrder(Long orderId); // 注意單一ID查詢可以不用Query
}
@Data
public class CheckoutCommand {
    private Long userId;
    private Long itemId;
    private Integer quantity;
}
@Data
public class OrderQuery {
    private Long sellerId;
    private Long itemId;
    private int currentPage;
    private int pageSize;
}

這個規範的好處是：提升了接口的穩定性、降低低級的重複，並且讓接口入參更加語意化。

CQE vs DTO

從上面的代碼能看出來，ApplicationService 的入參是 CQE 對象，但是出參卻是一個 DTO，從代碼格式上來看都是簡單的 POJO 對象，那麼他們之間有什麼區別呢？

CQE：CQE 對象是 ApplicationService 的輸入，是有明確的”意圖 “的，所以這個對象必須保證其” 正確性“。
DTO：DTO 對象只是數據容器，只是爲了和外部交互，所以本身不包含任何邏輯，只是貧血對象。

但可能最重要的一點：因爲 CQE 是”意圖 “，所以 CQE 對象在理論上可以有” 無限“個，每個代表不同的意圖；但是 DTO 作爲模型數據容器，和模型一一對應，所以是有限的。

CQE 的校驗

CQE 作爲 ApplicationService 的輸入，必須保證其正確性，那麼這個校驗是放在哪裏呢？

在最早的代碼裏，曾經有這樣的校驗邏輯，當時寫在了服務裏：

if (itemId <= 0 || quantity <= 0 || quantity >= 1000) {
    return Result.fail("Invalid Args");
}

這種代碼在日常非常常見，但其最大的問題就是大量的非業務代碼混雜在業務代碼中，很明顯的違背了單一職責原則。但因爲當時入參僅僅是簡單的 int，所以這個邏輯只能出現在服務裏。現在當入參改爲了 CQE 之後，我們可以利用 java 標準 JSR303 或 JSR380 的 Bean Validation 來前置這個校驗邏輯。

CQE 對象的校驗應該前置，避免在 ApplicationService 裏做參數的校驗。可以通過 JSR303/380 和 Spring Validation 來實現。

前面的例子可以改造爲：

@Validated // Spring的註解
public class CheckoutServiceImpl implements CheckoutService {
    OrderDTO checkout(@Valid CheckoutCommand cmd) { // 這裏@Valid是JSR-303/380的註解
        // 如果校驗失敗會拋異常，在interface層被捕捉
    }
}
@Data
public class CheckoutCommand {
    @NotNull(message = "用戶未登陸")
    private Long userId;
    @NotNull
    @Positive(message = "需要是合法的itemId")
    private Long itemId;
    @NotNull
    @Min(value = 1, message = "最少1件")
    @Max(value = 1000, message = "最多不能超過1000件")
    private Integer quantity;
}

這種做法的好處是，讓 ApplicationService 更加清爽，同時各種錯誤信息可以通過 Bean Validation 的 API 做各種個性化定製。

避免複用 CQE

因爲 CQE 是有 “意圖” 和“語意”的，我們需要儘量避免 CQE 對象的複用，哪怕所有的參數都一樣，只要他們的語意不同，儘量還是要用不同的對象。

規範：針對於不同語意的指令，要避免 CQE 對象的複用。

反例：一個常見的場景是 “Create 創建” 和“Update 更新”，一般來說這兩種類型的對象唯一的區別是一個 ID，創建沒有 ID，而更新則有。所以經常能看見有的同學用同一個對象來作爲兩個方法的入參，唯一區別是 ID 是否賦值。這個是錯誤的用法，因爲這兩個操作的語意完全不一樣，他們的校驗條件可能也完全不一樣，所以不應該複用同一個對象。正確的做法是產出兩個對象：

public interface CheckoutService {
    OrderDTO checkout(@Valid CheckoutCommand cmd);
    OrderDTO updateOrder(@Valid UpdateOrderCommand cmd);
}
@Data
public class UpdateOrderCommand {
    @NotNull(message = "用戶未登陸")
    private Long userId;
    @NotNull(message = "必須要有OrderID")
    private Long orderId;
    @NotNull
    @Positive(message = "需要是合法的itemId")
    private Long itemId;
    @NotNull
    @Min(value = 1, message = "最少1件")
    @Max(value = 1000, message = "最多不能超過1000件")
    private Integer quantity;
}

3 ApplicationService

ApplicationService 負責了業務流程的編排，是將原有業務流水賬代碼剝離了校驗邏輯、領域計算、持久化等邏輯之後剩餘的流程，是 “膠水層” 代碼。

參考一個簡易的交易流程：

在這個案例裏可以看出來，交易這個領域一共有 5 個用例：下單、支付成功、支付失敗關單、物流信息更新、關閉訂單。這 5 個用例可以用 5 個 Command/Event 對象代替，也就是對應了 5 個方法。

我見過 3 種 ApplicationService 的組織形態：

（1）一個 ApplicationService 類是一個完整的業務流程，其中每個方法負責處理一個 Use Case。這種的好處是可以完整的收斂整個業務邏輯，從接口類即可對業務邏輯有一定的掌握，適合相對簡單的業務流程。壞處就是對於複雜的業務流程會導致一個類的方法過多，有可能代碼量過大。這種類型的具體案例如：

public interface CheckoutService {
    // 下單
    OrderDTO checkout(@Valid CheckoutCommand cmd);
    // 支付成功
    OrderDTO payReceived(@Valid PaymentReceivedEvent event);
    // 支付取消
    OrderDTO payCanceled(@Valid PaymentCanceledEvent event);
    // 發貨
    OrderDTO packageSent(@Valid PackageSentEvent event);
    // 收貨
    OrderDTO delivered(@Valid DeliveredEvent event);
    // 批量查詢
    List<OrderDTO> query(OrderQuery query);
    // 單個查詢
    OrderDTO getOrder(Long orderId);
}

（2）針對於比較複雜的業務流程，可以通過增加獨立的 CommandHandler、EventHandler 來降低一個類中的代碼量：

@Component
public class CheckoutCommandHandler implements CommandHandler<CheckoutCommand, OrderDTO> {
    @Override
    public OrderDTO handle(CheckoutCommand cmd) {
        //
    }
}
public class CheckoutServiceImpl implements CheckoutService {
    @Resource
    private CheckoutCommandHandler checkoutCommandHandler;
    @Override
    public OrderDTO checkout(@Valid CheckoutCommand cmd) {
        return checkoutCommandHandler.handle(cmd);
    }
}

（3）比較激進一點，通過 CommandBus、EventBus，直接將指令或事件拋給對應的 Handler，EventBus 比較常見。具體案例代碼如下，通過消息隊列收到 MQ 消息後，生成 Event，然後由 EventBus 做路由到對應的 Handler：

// Application層
// 在這裏框架通常可以根據接口識別到這個負責處理PaymentReceivedEvent
// 也可以通過增加註解識別
@Component
public class PaymentReceivedHandler implements EventHandler<PaymentReceivedEvent> {
    @Override
    public void process(PaymentReceivedEvent event) {
        //
    }
}
// Interface層，這個是RocketMQ的Listener
public class OrderMessageListener implements MessageListenerOrderly {
    @Resource
    private EventBus eventBus;
    @Override
    public ConsumeOrderlyStatus consumeMessage(List<MessageExt> msgs, ConsumeOrderlyContext context) {
        PaymentReceivedEvent event = new PaymentReceivedEvent();
        eventBus.dispatch(event); // 不需要指定消費者
        return ConsumeOrderlyStatus.SUCCESS;
    }
}

不建議：這種做法可以實現 Interface 層和某個具體的 ApplicationService 或 Handler 的完全靜態解藕，在運行時動態 dispatch，做的比較好的框架如 AxonFramework。雖然看起來很便利，但是根據我們自己業務的實踐和踩坑發現，當代碼中的 CQE 對象越來越多，handler 越來越複雜時，運行時的 dispatch 缺乏了靜態代碼間的關聯關係，導致代碼很難讀懂，特別是當你需要 trace 一個複雜調用鏈路時，因爲 dispatch 是運行時的，很難摸清楚具體調用到的對象。所以我們雖然曾經有過這種嘗試，但現在已經不建議這麼做了。

Application Service 是業務流程的封裝，不處理業務邏輯

雖然之前曾經無數次重複 ApplicationService 只負責業務流程串聯，不負責業務邏輯，但如何判斷一段代碼到底是業務流程還是邏輯呢？

舉個之前的例子，最初的代碼重構後：

@Service
@Validated
public class CheckoutServiceImpl implements CheckoutService {
    private final OrderDtoAssembler orderDtoAssembler = OrderDtoAssembler.INSTANCE;
    @Resource
    private ItemService itemService;
    @Resource
    private InventoryService inventoryService;
    @Resource
    private OrderRepository orderRepository;
    @Override
    public OrderDTO checkout(@Valid CheckoutCommand cmd) {
        ItemDO item = itemService.getItem(cmd.getItemId());
        if (item == null) {
            throw new IllegalArgumentException("Item not found");
        }
        boolean withholdSuccess = inventoryService.withhold(cmd.getItemId(), cmd.getQuantity());
        if (!withholdSuccess) {
            throw new IllegalArgumentException("Inventory not enough");
        }
        Order order = new Order();
        order.setBuyerId(cmd.getUserId());
        order.setSellerId(item.getSellerId());
        order.setItemId(item.getItemId());
        order.setItemTitle(item.getTitle());
        order.setItemUnitPrice(item.getPriceInCents());
        order.setCount(cmd.getQuantity());
        Order savedOrder = orderRepository.save(order);
        return orderDtoAssembler.orderToDTO(savedOrder);
    }
}

判斷是否業務流程的幾個點

（1）不要有 if/else 分支邏輯

也就是說代碼的 Cyclomatic Complexity（循環複雜度）應該儘量等於 1。

通常有分支邏輯的，都代表一些業務判斷，應該將邏輯封裝到 DomainService 或者 Entity 裏。但這不代表完全不能有 if 邏輯，比如，在這段代碼裏：

boolean withholdSuccess = inventoryService.withhold(cmd.getItemId(), cmd.getQuantity());
if (!withholdSuccess) {
    throw new IllegalArgumentException("Inventory not enough");
}

雖然 CC > 1，但是僅僅代表了中斷條件，具體的業務邏輯處理並沒有受影響。可以把它看作爲 Precondition。

（2）不要有任何計算

在最早的代碼裏有這個計算：

// 5）領域計算
Long cost = item.getPriceInCents() * quantity;
order.setTotalCost(cost);

通過將這個計算邏輯封裝到實體裏，避免在 ApplicationService 裏做計算：

@Data
public class Order {
    private Long itemUnitPrice;
    private Integer count;
    // 把原來一個在ApplicationService的計算遷移到Entity裏
    public Long getTotalCost() {
        return itemUnitPrice * count;
    }
}
order.setItemUnitPrice(item.getPriceInCents());
order.setCount(cmd.getQuantity());

（3）一些數據的轉化可以交給其他對象來做

比如 DTO Assembler，將對象間轉化的邏輯沉澱在單獨的類中，降低 ApplicationService 的複雜度。

OrderDTO dto = orderDtoAssembler.orderToDTO(savedOrder);

常用的 ApplicationService“套路”

我們可以看出來，ApplicationService 的代碼通常有類似的結構：AppService 通常不做任何決策（Precondition 除外），僅僅是把所有決策交給 DomainService 或 Entity，把跟外部交互的交給 Infrastructure 接口，如 Repository 或防腐層。

一般的 “套路” 如下：

準備數據：包括從外部服務或持久化源取出相對應的 Entity、VO 以及外部服務返回的 DTO。
執行操作：包括新對象的創建、賦值，以及調用領域對象的方法對其進行操作。需要注意的是這個時候通常都是純內存操作，非持久化。
持久化：將操作結果持久化，或操作外部系統產生相應的影響，包括髮消息等異步操作。

如果涉及到對多個外部系統（包括自身的 DB）都有變更的情況，這個時候通常處在 “分佈式事務” 的場景裏，無論是用分佈式 TX、TCC、還是 Saga 模式，取決於具體場景的設計，在此處暫時略過。

4 DTO Assembler

一個經常被忽視的問題是 ApplicationService 應該返回 Entity 還是 DTO？這裏提出一個規範，在 DDD 分層架構中：

ApplicationService 應該永遠返回 DTO 而不是 Entity。

爲什麼呢？

構建領域邊界：ApplicationService 的入參是 CQE 對象，出參是 DTO，這些基本上都屬於簡單的 POJO，來確保 Application 層的內外互相不影響。
降低規則依賴：Entity 裏面通常會包含業務規則，如果 ApplicationService 返回 Entity，則會導致調用方直接依賴業務規則。如果內部規則變更可能直接影響到外部。
通過 DTO 組合降低成本：Entity 是有限的，DTO 可以是多個 Entity、VO 的自由組合，一次性封裝成複雜 DTO，或者有選擇的抽取部分參數封裝成 DTO 可以降低對外的成本。

因爲我們操作的對象是 Entity，但是輸出的對象是 DTO，這裏就需要一個專屬類型的對象叫 DTO Assembler。DTO Assembler 的唯一職責是將一個或多個 Entity/VO，轉化爲 DTO。注意：DTO Assembler 通常不建議有反操作，也就是不會從 DTO 到 Entity，因爲通常一個 DTO 轉化爲 Entity 時是無法保證 Entity 的準確性的。

通常，Entity 轉 DTO 是有成本的，無論是代碼量還是運行時的操作。手寫轉換代碼容易出錯，爲了節省代碼量用 Reflection 會造成極大的性能損耗。所以這裏我還是不遺餘力的推薦 MapStruct 這個庫。MapStruct 通過靜態編譯時代碼生成，通過寫接口和配置註解就可以生成對應的代碼，且因爲生成的代碼是直接賦值，其性能損耗基本可以忽略不計。

通過 MapStruct，代碼即可簡化爲：

import org.mapstruct.Mapper;
@Mapper
public interface OrderDtoAssembler {
    OrderDtoAssembler INSTANCE = Mappers.getMapper(OrderDtoAssembler.class);
    OrderDTO orderToDTO(Order order);
}
public class CheckoutServiceImpl implements CheckoutService {
    private final OrderDtoAssembler orderDtoAssembler = OrderDtoAssembler.INSTANCE;
    @Override
    public OrderDTO checkout(@Valid CheckoutCommand cmd) {
        // ...
        Order order = new Order();  
        // ...
        Order savedOrder = orderRepository.save(order);
        return orderDtoAssembler.orderToDTO(savedOrder);
    }
}

結合之前的 Data Mapper，DTO、Entity 和 DataObject 之間的關係如下圖：

5 Result vs Exception

最後，上文曾經提及在 Interface 層應該返回 Result，在 Application 層應該返回 DTO，在這裏再次重複提出規範：

Application 層只返回 DTO，可以直接拋異常，不用統一處理。所有調用到的服務也都可以直接拋異常，除非需要特殊處理，否則不需要刻意捕捉異常。

異常的好處是能明確的知道錯誤的來源，堆棧等，在 Interface 層統一捕捉異常是爲了避免異常堆棧信息泄漏到 API 之外，但是在 Application 層，異常機制仍然是信息量最大，代碼結構最清晰的方法，避免了 Result 的一些常見且繁雜的 Result.isSuccess 判斷。所以在 Application 層、Domain 層，以及 Infrastructure 層，遇到錯誤直接拋異常是最合理的方法。

6 Anti-Corruption Layer 防腐層

本文僅僅簡單描述一下 ACL 的原理和作用，具體的實施規範可能要等到另外一篇文章。

在 ApplicationService 中，經常會依賴外部服務，從代碼層面對外部系統產生了依賴。比如上文中的：

ItemDO item = itemService.getItem(cmd.getItemId());
boolean withholdSuccess = inventoryService.withhold(cmd.getItemId(), cmd.getQuantity());

會發現我們的 ApplicationService 會強依賴 ItemService、InventoryService 以及 ItemDO 這個對象。如果任何一個服務的方法變更，或者 ItemDO 字段變更，都會有可能影響到 ApplicationService 的代碼。也就是說，我們自己的代碼會因爲強依賴了外部系統的變化而變更，這個在複雜系統中應該是儘量避免的。那麼如何做到對外部系統的隔離呢？需要加入 ACL 防腐層。

ACL 防腐層的簡單原理如下：

對於依賴的外部對象，我們抽取出所需要的字段，生成一個內部所需的 VO 或 DTO 類。
構建一個新的 Facade，在 Facade 中封裝調用鏈路，將外部類轉化爲內部類。
針對外部系統調用，同樣的用 Facade 方法封裝外部調用鏈路。

無防腐層的情況：

有防腐層的情況：

具體簡單實現，假設所有外部依賴都命名爲 ExternalXXXService：

// 自定義的內部值類
@Data
public class ItemDTO {
    private Long itemId;
    private Long sellerId;
    private String title;
    private Long priceInCents;
}
// 商品Facade接口
public interface ItemFacade {
    ItemDTO getItem(Long itemId);
}
// 商品facade實現
@Service
public class ItemFacadeImpl implements ItemFacade {
    @Resource
    private ExternalItemService externalItemService;
    @Override
    public ItemDTO getItem(Long itemId) {
        ItemDO itemDO = externalItemService.getItem(itemId);
        if (itemDO != null) {
            ItemDTO dto = new ItemDTO();
            dto.setItemId(itemDO.getItemId());
            dto.setTitle(itemDO.getTitle());
            dto.setPriceInCents(itemDO.getPriceInCents());
            dto.setSellerId(itemDO.getSellerId());
            return dto;
        }
        return null;
    }
}
// 庫存Facade
public interface InventoryFacade {
    boolean withhold(Long itemId, Integer quantity);
}
@Service
public class InventoryFacadeImpl implements InventoryFacade {
    @Resource
    private ExternalInventoryService externalInventoryService;
    @Override
    public boolean withhold(Long itemId, Integer quantity) {
        return externalInventoryService.withhold(itemId, quantity);
    }
}

通過 ACL 改造之後，我們 ApplicationService 的代碼改爲：

@Service
public class CheckoutServiceImpl implements CheckoutService {
    @Resource
    private ItemFacade itemFacade;
    @Resource
    private InventoryFacade inventoryFacade;
    @Override
    public OrderDTO checkout(@Valid CheckoutCommand cmd) {
        ItemDTO item = itemFacade.getItem(cmd.getItemId());
        if (item == null) {
            throw new IllegalArgumentException("Item not found");
        }
        boolean withholdSuccess = inventoryFacade.withhold(cmd.getItemId(), cmd.getQuantity());
        if (!withholdSuccess) {
            throw new IllegalArgumentException("Inventory not enough");
        }
        // ...
    }
}

很顯然，這麼做的好處是 ApplicationService 的代碼已經完全不再直接依賴外部的類和方法，而是依賴了我們自己內部定義的值類和接口。如果未來外部服務有任何的變更，需要修改的是 Facade 類和數據轉化邏輯，而不需要修改 ApplicationService 的邏輯。

Repository 可以認爲是一種特殊的 ACL，屏蔽了具體數據操作的細節，即使底層數據庫結構變更，數據庫類型變更，或者加入其他的持久化方式，Repository 的接口保持穩定，ApplicationService 就能保持不變。

在一些理論框架裏 ACL Facade 也被叫做 Gateway，含義是一樣的。

四 Orchestration vs Choreography

在本文最後想聊一下複雜業務流程的設計規範。在複雜的業務流程裏，我們通常面臨兩種模式：Orchestration 和 Choreography。很無奈，這兩個英文單詞的百度翻譯 / 谷歌翻譯，都是 “編排”，但實際上這兩種模式是完全不一樣的設計模式。

Orchestration 的編排（比如 SOA / 微服務的服務編排 Service Orchestration）是我們通常熟悉的用法，Choreography 是最近出現了事件驅動架構 EDA 才慢慢流行起來。網上可能會有其他的翻譯，比如編制、編舞、協作等，但感覺都沒有真正的把英文單詞的意思表達出來，所以爲了避免誤解，在下文我儘量還是用英文原詞。如果誰有更好的翻譯方法歡迎聯繫我。

1 模式簡介

Orchestration：通常出現在腦海裏的是一個交響樂團（Orchestra，注意這兩個詞的相似性）。交響樂團的核心是一個唯一的指揮家 Conductor，在一個交響樂中，所有的音樂家必須聽從 Conductor 的指揮做操作，不可以獨自發揮。所以在 Orchestration 模式中，所有的流程都是由一個節點或服務觸發的。我們常見的業務流程代碼，包括調用外部服務，就是 Orchestration，由我們的服務統一觸發。
Choreography：通常會出現在腦海的場景是一個舞劇（來自於希臘文的舞蹈，Choros）。其中每個不同的舞蹈家都在做自己的事，但是沒有一箇中心化的指揮。通過協作配合，每個人做好自己的事，整個舞蹈可以展現出一個完整的、和諧的畫面。所以在 Choreography 模式中，每個服務都是獨立的個體，可能會響應外部的一些事件，但整個系統是一個整體。

2 案例

用一個常見的例子：下單後支付併發貨。

如果這個案例是 Orchestration，則業務邏輯爲：下單時從一個預存的賬戶里扣取資金，並且生成物流單發貨，從圖上看是這樣的：

如果這個案例是 Choreography，則業務邏輯爲：下單，然後等支付成功事件，然後再發貨，類似這樣：

3 模式的區別和選擇

雖然看起來這兩種模式都能達到一樣的業務目的，但是在實際開發中他們有巨大的差異。

從代碼依賴關係來看：

Orchestration：涉及到一個服務調用到另外的服務，對於調用方來說，是強依賴的服務提供方。
Choreography：每一個服務只是做好自己的事，然後通過事件觸發其他的服務，服務之間沒有直接調用上的依賴。但要注意的是下游還是會依賴上游的代碼（比如事件類），所以可以認爲是下游對上游有依賴。

從代碼靈活性來看：

Orchestration：因爲服務間的依賴關係是寫死的，增加新的業務流程必然需要修改代碼。
Choreography：因爲服務間沒有直接調用關係，可以增加或替換服務，而不需要改上游代碼。

從調用鏈路來看：

Orchestration：是從一個服務主動調用另一個服務，所以是 Command-Driven 指令驅動的。
Choreography：是每個服務被動的被外部事件觸發，所以是 Event-Driven 事件驅動的。

從業務職責來看：

Orchestration：有主動的調用方（比如：下單服務）。無論下游的依賴是誰，主動的調用方都需要爲整個業務流程和結果負責。
Choreography：沒有主動調用方，每個服務只關心自己的觸發條件和結果，沒有任何一個服務會爲整個業務鏈路負責。

小結：

另外需要重點明確的：“指令驅動”和 “事件驅動” 的區別不是 “同步” 和“異步”。指令可以是同步調用，也可以是異步消息觸發（但異步指令不是事件）；反過來事件可以是異步消息，但也完全可以是進程內的同步調用。所以指令驅動和事件驅動差異的本質不在於調用方式，而是一件事情是否 “已經” 發生。

所以在日常業務中當你碰到一個需求時，該如何選擇是用 Orchestration 還是 Choreography？

這裏給出兩個判斷方法：

（1）明確依賴的方向

在代碼中的依賴是比較明確的：如果你是下游，上游對你無感知，則只能走事件驅動；如果上游必須要對你有感知，則可以走指令驅動。反過來，如果你是上游，需要對下游強依賴，則是指令驅動；如果下游是誰無所謂，則可以走事件驅動。

（2）找出業務中的 “負責人”

第二種方法是根據業務場景找出其中的 “負責人”。比如，如果業務需要通知賣家，下單系統的單一職責不應該爲消息通知負責，但訂單管理系統需要根據訂單狀態的推進主動觸發消息，所以是這個功能的負責人。

在一個複雜業務流程裏，通常兩個模式都要有，但也很容易設計錯誤。如果出現依賴關係很奇怪，或者代碼裏調用鏈路 / 負責人梳理不清楚的情況，可以嘗試轉換一下模式，可能會好很多。

哪個模式更好？

很顯然，沒有最好的模式，只有最合適自己業務場景的模式。

反例：最近幾年比較流行的 Event-Driven Architecture（EDA）事件驅動架構，以及 Reactive-Programming 響應式編程（比如 RxJava），雖然有很多創新，但在一定程度上是 “當你有把錘子，所有問題都是釘子” 的典型案例。他們對一些基於事件的、流處理的問題有奇效，但如果拿這些框架硬套指令驅動的業務，就會感到代碼極其“不協調”，認知成本提高。所以在日常選型中，還是要先根據業務場景梳理出來是哪些流程中的部分是 Orchestration，哪些是 Choreography，然後再選擇相對應的框架。

4 跟 DDD 分層架構的關係

最後，講了這麼多 O vs C，跟 DDD 有啥關係？很簡單：

O&C 其實是 Interface 層的關注點，Orchestration = 對外的 API，而 Choreography = 消息或事件。當你決策了 O 還是 C 之後，需要在 Interface 層承接這些 “驅動力”。
無論 O&C 如何設計，Application 層都 “無感知”，因爲 ApplicationService 天生就可以處理 Command、Query 和 Event，至於這些對象怎麼來，是 Interface 層的決策。

所以，雖然 Orchestration 和 Choreography 是兩種完全不同的業務設計模式，但最終落到 Application 層的代碼應該是一致的，這也是爲什麼 Application 層是 “用例” 而不是“接口”，是相對穩定的存在。

五總結

只要是做業務的，一定會需要寫業務流程和服務編排，但不代表這種代碼一定質量差。通過 DDD 的分層架構裏的 Interface 層和 Application 層的合理拆分，代碼可以變得優雅、靈活，能更快的響應業務但同時又能更好的沉澱。本文主要介紹了一些代碼的設計規範，幫助大家掌握一定的技巧。

Interface 層：

職責：主要負責承接網絡協議的轉化、Session 管理等。
接口數量：避免所謂的統一 API，不必人爲限制接口類的數量，每個 / 每類業務對應一套接口即可，接口參數應該符合業務需求，避免大而全的入參。
接口出參：統一返回 Result。
異常處理：應該捕捉所有異常，避免異常信息的泄漏。可以通過 AOP 統一處理，避免代碼裏有大量重複代碼。

Application 層：

入參：具像化 Command、Query、Event 對象作爲 ApplicationService 的入參，唯一可以的例外是單 ID 查詢的場景。
CQE 的語意化：CQE 對象有語意，不同用例之間語意不同，即使參數一樣也要避免複用。
入參校驗：基礎校驗通過 Bean Validation api 解決。Spring Validation 自帶 Validation 的 AOP，也可以自己寫 AOP。
出參：統一返回 DTO，而不是 Entity 或 DO。
DTO 轉化：用 DTO Assembler 負責 Entity/VO 到 DTO 的轉化。
異常處理：不統一捕捉異常，可以隨意拋異常。

部分 Infra 層：

用 ACL 防腐層將外部依賴轉化爲內部代碼，隔離外部的影響。

業務流程設計模式：

沒有最好的模式，取決於業務場景、依賴關係、以及是否有業務 “負責人”。避免拿着錘子找釘子。

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

猜你喜歡