DDD分層架構的應用

開篇

上周有機會去上海參加了2021年的架構師峰會牵辣，分享中提到了很多云原生的概念，但是云原生的概念更多適合云廠商而非業(yè)務相關的開發(fā)择浊。作為業(yè)務開發(fā)的我更關注的是業(yè)務相關的分享逾条，也就是這次分享中的DDD相關的概念。
DDD有很多概念师脂，包括通用語言、實體攒磨、Repository泳桦、分層架構等等，這次主要總結的是分層架構和實體定義谒府。DDD是一個仁者見仁智者見智的概念，很多東西都可以直接往上套完疫。
這次分享給我最大的感觸就是沒有為了DDD而DDD，而是運用其中提到的分層架構來解決實際遇到的問題盛龄，而這種解決方案是比較有參考性和落地意義的芳誓。

架構規(guī)范

業(yè)務開發(fā)的整體架構規(guī)范如上圖所示，整體的訪問是從左到右锹淌。
從架構維度的分層為Interface層、application層挟憔、domain層烟号、infrastructure層。
Interface層接收和轉化參數(shù)訪問application層汪拥，響應application層返回值進行返回。
Application層負責串聯(lián)業(yè)務流程趟大，通過Domain層的Service來完成業(yè)務處理铣焊。
Domain層負責以領域模型的劃分處理具體的業(yè)務。
Infrastructure層作為基礎設施層曲伊，主要封裝第三方業(yè)務訪問包含MQ數(shù)據(jù)庫RPC等。

對比我們日常spring mvc模式的分層架構岛蚤，我們能夠發(fā)現(xiàn)本質上MVC就是在踐行DDD的分層架構懈糯，但不是每個使用mvc分層架構的實現(xiàn)都有明確的分層邊界定義，不是每個使用mvc分層架構的實現(xiàn)都定義了每層使用的領域對象赚哗。

所以在原來的基礎上定義每層的業(yè)務邊界和數(shù)據(jù)邊界就是更好的應用分層實現(xiàn)業(yè)務擴展

分層架構

服務層定義

服務對外提供的接口包括面向web client的rest接口或者面向rpc client的dubbo接口硅堆。我們定義Controller為對應的Api Layer（Interface層）贿讹，Api層負責接收請求并交由Service層進行處理。
Service層包含Application和Domain兩個維度的Service茄菊，Application Service主要是負責業(yè)務流程的編排赊堪，Domain Service負責具體業(yè)務的處理，但是根據(jù)具體業(yè)務的復雜性我們可能只有Application Service而沒有Domain Service雹食，但是建議包含Domain Service。
Persist Layer或者Rpc Layer可以映射為Infrastructure層吃挑，主要用來訪問DB或者外部的rpc服務街立，為了屏蔽底層差異新增的屏蔽層。

數(shù)據(jù)層定義

Api層對外定義參數(shù)變量Param赎离，對Service層轉化為DO/BO對象，負責Param到DO/BO的轉換梁剔。
Service層對Api層定義DO/BO對象，對Persist/Rpc層定義PO/DTO對象码撰，對內負責DO/BO到PO的轉換个盆，對外負責DO/BO到VO/DTO的轉換。
Persist/Rpc層對Service定義PO/DTO對象颊亮，對外PO/DTO到DO/BO的轉換。
不同層定義了的參數(shù)之間相互轉換通過MapStruct來實現(xiàn)降低成本绍在。
從分層依賴的角度來看上層依賴于下層，因此數(shù)據(jù)對象定義應該在下層進行定義揣苏；上層傳給下層的數(shù)據(jù)由上層負責轉換件舵，下層傳給上層的數(shù)據(jù)由下層負責轉換。

Api層異常處理

通過切面來解決Spring Mvc返回結果的異常處理铅祸，通過Filter來解決Dubbo返回結果的異常處理坑质。

@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());
    }
}

Controller層所有Api接口都有重復的異常處理邏輯盟庞，代碼重復率極高。
通過自定義注解和切面來優(yōu)化代碼邏輯什猖，Api層只包含正常的業(yè)務處理流程。

@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;
    }
}

切面統(tǒng)一封裝異常的處理的流程降铸。

總結

目前我對于DDD的理解更多是在分層的理念上摇零，從外到層依次氛圍Api層、Application Service層驻仅、Domain Service層、Repository層铃彰、Infrastructure層芯咧。
相比較傳統(tǒng)spring mvc的三層架構牙捉，為了分層的更加明確性DDD做了更多的細化敬飒。針對Service層拆分為了Application Service層和Domain Service層，Domain Service負責處理特定域的服務带到，Application Service層負責通過Domain Service進行業(yè)務流程編排英染；針對數(shù)據(jù)訪問層或者外部的Rpc服務調用層被饿，我們增加了Repository來進行依賴隔離搪搏。
明確了每層的數(shù)據(jù)邊界和數(shù)據(jù)轉換的方法，各層數(shù)據(jù)包含Param+DO+VO+PO等疯溺。通過MapStruct降低數(shù)據(jù)轉換的成本，也利于提高我們分層定義對象的積極性恃疯。

參考

感謝架構師峰會殷浩的分享收貨頗多墨闲，準備去分享并推廣今妄，提高大家的代碼效率鸳碧。