阿里大佬:DDD中Interface層、Application層的設計規範

文章很長,且持續更新,建議收藏起來,慢慢讀!瘋狂創客圈總目錄 博客園版 爲您奉上珍貴的學習資源 :

免費贈送 :《尼恩Java面試寶典》 持續更新+ 史上最全 + 面試必備 2000頁+ 面試必備 + 大廠必備 +漲薪必備
免費贈送 :《尼恩技術聖經+高併發系列PDF》 ,幫你 實現技術自由,完成職業升級, 薪酬猛漲!加尼恩免費領
免費贈送 經典圖書:《Java高併發核心編程(卷1)加強版》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
免費贈送 經典圖書:《Java高併發核心編程(卷2)加強版》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
免費贈送 經典圖書:《Java高併發核心編程(卷3)加強版》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領

免費贈送 資源寶庫: Java 必備 百度網盤資源大合集 價值>10000元 加尼恩領取


阿里大佬:DDD中Interface層、Application層的設計規範

說在前面

在40歲老架構師 尼恩的讀者交流羣(50+)中,最近有小夥伴拿到了一線互聯網企業如阿里、滴滴、極兔、有贊、希音、百度、網易、美團的面試資格,遇到很多很重要的面試題:

談談你的DDD落地經驗?

談談你對DDD的理解?

如何保證RPC代碼不會腐爛,升級能力強?

最近有小夥伴在字節,又遇到了相關的面試題。小夥伴懵了, 他從來沒有用過DDD,面掛了。關於DDD,尼恩之前給大家梳理過一篇很全的文章: 阿里一面:談一下你對DDD的理解?2W字,幫你實現DDD自由

但是尼恩的文章, 太過理論化,不適合剛入門的人員。所以,尼恩也在不斷的爲大家找更好的學習資料。

前段時間,尼恩在阿里的技術公衆號上看到了一篇文章《殷浩詳解DDD:領域層設計規範》 作者是阿里 技術大佬殷浩,非常適合於初學者入門,同時也足夠的有深度。

美中不足的是, 殷浩那篇文章的行文風格,對初學者不太友好, 尼恩剛開始看的時候,也比較晦澀。

於是,尼恩在讀的過程中,把那些晦澀的內容,給大家用尼恩的語言, 淺化了一下, 這樣大家更容易懂。

本着技術學習、技術交流的目的,這裏,把尼恩修改過的 《殷浩詳解DDD:領域層設計規範》,通過尼恩的公衆號《技術自由圈》發佈出來。

特別聲明,由於沒有殷浩同學的聯繫方式,這裏沒有找殷浩的授權,

如果殷浩同學或者阿里技術公衆號不同意我的修改,不同意我的發佈, 我即刻從《技術自由圈》公衆號扯下來。

另外, 文章也特別長, 我也特別準備了PDF版本。如果需要尼恩修改過的PDF版本,也可以通過《技術自由圈》公衆號找到尼恩來獲取。

本文目錄

尼恩總結:DDD的本質和最終收益

在正式開始第4篇之前,尼恩說一下自己對DDD的 親身體驗、和深入思考。

DDD的本質:

  • 大大提升 核心代碼 業務純度

    老的mvc架構,代碼中緊緊的耦合着特定ORM框架、特定DB存儲、特定的緩存、特定的事務框架、特定中間件,特定對外依賴解耦, 很多很多。

    總之就是 業務和技術緊密耦合,代碼的 業務純度低, 導致軟件“固化”, 沒法做快速擴展和升級。

  • 大大提升 代碼工程 測維擴 能力

    DDD進行了多個層次的解耦,包括 持久層的DB解耦,第三方依賴的隔離解耦,大大提升了 可測試度、可維護度、可擴展度

  • 更大限度 積累 業務領域模型 資產

    由於spring mvc 模式下, 代碼的業務純度不高, 導致尼恩的曾經一個項目,10年多時間, 衍生出 50多個不同的版本,推導重來5次,付出巨大的 時間成本、經濟成本

DDD的收益:

  • 極大的降低升級的工作量
  • 極大的降低推到重來的風險
  • 極大提升代碼的核心代碼業務純度,積累更多的代碼資產

不用DDD的反面案例,尼恩曾經見過一個項目:

  • 10年多時間, 衍生出 50多個不同的版本, 每個版本80%的功能相同,但是代碼各種衝突,沒有合併
  • 10年多時間,經歷過至少 5次推倒重來, 基本換一個領導,恨不得推導重來一次, 感覺老的版本都是不行,只有自己設計的纔好
  • 5次推倒重來,每次都是 風風火火/加班到進ICU, 投入了大量的人力/財力。其實大多是重複投入、重複建設
  • 可謂, 一將不才累死三軍, 所以, 一個優秀的架構師,對一個項目來說是多麼的重要

本文說明:

本文是 《阿里DDD大佬:從0到1,帶大家精通DDD》系列的第6篇

本文是 《從0到1,帶大家精通DDD》系列的的鏈接地址是:

阿里DDD大佬:從0到1,帶大家精通DDD

阿里大佬:DDD 落地兩大步驟,以及Repository核心模式

阿里面試:讓代碼不腐爛,DDD是怎麼做的?

阿里大佬:DDD 領域層,該如何設計?

極兔面試:微服務爆炸,如何解決?Uber 是怎麼解決2200個微服務爆炸的?

大家可以先看前面的文章,再來看本篇,效果更佳。

另外,尼恩會結合一個工業級的DDD實操項目,在第34章視頻《DDD的頂奢面經》中,給大家徹底介紹一下DDD的實操、COLA 框架、DDD的面試題。

第6篇 - Interface層、Application層的設計規範

在日常工作中我觀察到,面對老系統重構和遷移場景,有大量代碼屬於流水賬代碼,

通常能看到開發在對外的API接口裏直接寫業務邏輯代碼,或者在一個服務裏大量的堆接口,導致業務邏輯實際無法收斂,接口複用性比較差。

本文主要想系統性的解釋一下如何通過DDD的重構,將原有的流水賬代碼,改造爲邏輯清晰、職責分明的模塊

領域驅動設計沒有特定的架構風格,它的核心是域模型驅動業務的思想,常見的領域驅動設計架構有傳統的四層架構模式、事件驅動架構、CQRS架構、六邊形架構等。

1. 傳統的四層架構模式

  • User Interface爲用戶界面層(對外訪問層API),負責向用戶顯示信息和解釋用戶命令。
  • Application爲應用層,定義軟件要完成的任務,並且指揮表達領域概念的對象來解決問題。
  • Domain爲領域層(或模型層),負責表達業務概念,業務狀態信息以及業務規則。
  • Infrastructure層爲基礎實施層,向其他層提供通用的技術能力。
    DDD四層架構圖
  • 基礎設施層:基本上都是需要固化的代碼,一次寫成,需要變動的次數很少,一旦變動,就需要大量謹慎的迴歸測試。將所有的存儲調用、中間件調用都沉澱在這一層中。

2. 下單鏈路案例簡介

這裏舉一個簡單的常見案例:下單鏈路。

假設我們在做一個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。每個應用層的方法應該代表整個業務流程中的一個節點。
  • 處理一些跨層的橫切關注點,如鑑權、異常處理、校驗、緩存、日誌等。

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

3. 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接口層,作爲所有對外的門戶,將網絡協議和業務邏輯解耦。

3.1 接口層的組成

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

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

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

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

3.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.3 接口層的接口的數量和業務間的隔離

在傳統REST和RPC的接口規範中,同一個領域的方法放在一個領域的服務或Controller中。

具體來說:通常一個領域的接口,無論是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(Single Responsibility Principle,簡稱 SRP)一致。

也許會有人問,如果按照這種做法,會不會產生大量的接口類,導致代碼邏輯重複?

答案是不會,因爲在DDD分層架構裏,接口類的核心作用僅僅是協議層,每類業務的協議可以是不同的,而真實的業務邏輯會沉澱到應用層。

也就是說Interface和Application的關係是多對多的:

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

4. Application層

4.1 Application層的組成部分

Application層的幾個核心類:

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

Application層最核心的對象是ApplicationService,它的核心功能是承接“業務流程“。

但是在講ApplicationService的規範之前,必須要先重點的講幾個特殊類型的對象,即Command、Query和Event。

4.2 使用Command、Query、Event對象語意化我們的參數

首先,回顧一下基礎 的 CQRS 模式

  • CQRS(Command and Query Responsibility Segregation)命令查詢職責分離模式,分別對讀和寫建模。

  • CQRS從定義上要求:

    • 一個方法修改了對象的狀態,該方法便是一個Command,它不應該返回數據。
    • 一個方法返回了數據,該方法便是一個Query,此時它不應該通過直接的或間接的手段修改對象的狀態。

    CQRS架構圖

從本質上來看,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;

}

4.3 ApplicationService 流程編排

要點1: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:

// 在這裏框架通常可以根據接口識別到這個負責處理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是運行時的,很難摸清楚具體調用到的對象。

所以我們雖然曾經有過這種嘗試,但現在已經不建議這麼做了。

要點2: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裏。

但,這不代表Application Service 完全不能有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或防腐層。

一般ApplicationService的“套路”如下:

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

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

4.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之間的關係如下圖:

4.5 Result vs Exception

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

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

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

所以在Application層、Domain層,以及Infrastructure層,遇到錯誤直接拋異常是最合理的方法。

4.6 Anti-Corruption Layer防腐層

在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,含義是一樣的。

5. Orchestration編排 vs Choreography協作

在複雜的業務流程裏,我們通常面臨兩種模式:Orchestration 和 Choreography。

很無奈,這兩個英文單詞的百度翻譯/谷歌翻譯,都是“編排”,但實際上這兩種模式是完全不一樣的設計模式。

  • Orchestration的編排(比如SOA/微服務的服務編排Service Orchestration)是我們通常熟悉的用法
  • Choreography是最近出現了事件驅動架構EDA才慢慢流行起來。

5.1 模式簡介

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

5.2 案例

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

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

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

5.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,然後再選擇相對應的框架。

5.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 面試題,是非常常見的面試題。 DDD的學習材料, 汗牛塞屋,又缺乏經典。

《殷浩詳解DDD:領域層設計規範》做到從0到1帶大家精通DDD,非常難得。

這裏,把尼恩修改過的 《殷浩詳解DDD:領域層設計規範》,通過尼恩的公衆號《技術自由圈》發佈出來。

大家面試的時候, 可以參考以上的內容去組織答案,如果大家能做到對答如流,如數家珍,基本上 面試官會被你 震驚到、吸引到。

另外在面試之前,建議大家系統化的刷一波 5000頁《尼恩Java面試寶典PDF》,並且在刷題過程中,如果有啥問題,大家可以來 找 40歲老架構師尼恩交流。

最終,讓面試官愛到 “不能自已、口水直流”。offer, 也就來了。

當然,關於DDD,尼恩即將給大家發佈一波視頻 《第34章:DDD的頂奢面經》。

技術自由的實現路徑:

實現你的 架構自由:

喫透8圖1模板,人人可以做架構

10Wqps評論中臺,如何架構?B站是這麼做的!!!

阿里二面:千萬級、億級數據,如何性能優化? 教科書級 答案來了

峯值21WQps、億級DAU,小遊戲《羊了個羊》是怎麼架構的?

100億級訂單怎麼調度,來一個大廠的極品方案

2個大廠 100億級 超大流量 紅包 架構方案

… 更多架構文章,正在添加中

實現你的 響應式 自由:

響應式聖經:10W字,實現Spring響應式編程自由

這是老版本 《Flux、Mono、Reactor 實戰(史上最全)

實現你的 spring cloud 自由:

Spring cloud Alibaba 學習聖經》 PDF

分庫分表 Sharding-JDBC 底層原理、核心實戰(史上最全)

一文搞定:SpringBoot、SLF4j、Log4j、Logback、Netty之間混亂關係(史上最全)

實現你的 linux 自由:

Linux命令大全:2W多字,一次實現Linux自由

實現你的 網絡 自由:

TCP協議詳解 (史上最全)

網絡三張表:ARP表, MAC表, 路由表,實現你的網絡自由!!

實現你的 分佈式鎖 自由:

Redis分佈式鎖(圖解 - 秒懂 - 史上最全)

Zookeeper 分佈式鎖 - 圖解 - 秒懂

實現你的 王者組件 自由:

隊列之王: Disruptor 原理、架構、源碼 一文穿透

緩存之王:Caffeine 源碼、架構、原理(史上最全,10W字 超級長文)

緩存之王:Caffeine 的使用(史上最全)

Java Agent 探針、字節碼增強 ByteBuddy(史上最全)

實現你的 面試題 自由:

4800頁《尼恩Java面試寶典 》 40個專題

免費獲取11個技術聖經PDF:

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章