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

作者 | 殷浩
來源 | 阿里技術公眾號

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

一 案例簡介

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

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

@RestController @RequestMapping("/") public class CheckoutController {@Resourceprivate ItemService itemService;@Resourceprivate InventoryService inventoryService;@Resourceprivate 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對象？

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

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

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

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> {@Overridepublic OrderDTO handle(CheckoutCommand cmd) {//} }public class CheckoutServiceImpl implements CheckoutService {@Resourceprivate CheckoutCommandHandler checkoutCommandHandler;@Overridepublic OrderDTO checkout(@Valid CheckoutCommand cmd) {return checkoutCommandHandler.handle(cmd);} }

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

// 在這里框架通常可以根據接口識別到這個負責處理PaymentReceivedEvent // 也可以通過增加注解識別 @Component public class PaymentReceivedHandler implements EventHandler<PaymentReceivedEvent> {@Overridepublic void process(PaymentReceivedEvent event) {//} }// Interface層，這個是RocketMQ的Listener public class OrderMessageListener implements MessageListenerOrderly {@Resourceprivate EventBus eventBus;@Overridepublic 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;@Resourceprivate ItemService itemService;@Resourceprivate InventoryService inventoryService;@Resourceprivate OrderRepository orderRepository;@Overridepublic 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;@Overridepublic 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 {@Resourceprivate ExternalItemService externalItemService;@Overridepublic 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 {@Resourceprivate ExternalInventoryService externalInventoryService;@Overridepublic boolean withhold(Long itemId, Integer quantity) {return externalInventoryService.withhold(itemId, quantity);} }

通過ACL改造之后，我們ApplicationService的代碼改為：

@Service public class CheckoutServiceImpl implements CheckoutService {@Resourceprivate ItemFacade itemFacade;@Resourceprivate InventoryFacade inventoryFacade;@Overridepublic 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防腐層將外部依賴轉化為內部代碼，隔離外部的影響。

業務流程設計模式：

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

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的殷浩详解DDD：如何避免写流水账代码？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。