您现在的位置：程式碼之家 >> 編程語言 > >> 更多程式語言 >> 程式設計綜合問答

接口封裝邊界設計：薄適配層 vs 獨立 DTO，取決於業務擴展性與差異度

編輯：程式設計綜合問答

對接多家第三方服務（A、B），參數結構各異，重合度約 50%。統一接口層該直接透傳 A/B 的 Bean，還是定義自己的 DTO 再轉換？

兩種模式對比

維度	薄適配（直接用 A/B Bean）	獨立 DTO（自定義統一模型）
開發速度	快，少寫轉換代碼	慢，需定義 DTO + 映射邏輯
耦合度	高，上層感知第三方細節	低，上層只依賴自有模型
擴展新服務 C	需修改統一接口簽名	只需新增 Mapper，接口不變
字段差異處理	直接暴露差異，調用端需判斷	在 Mapper 層屏蔽差異，補默認值
測試難度	需 Mock 第三方具體類	只需 Mock 統一 DTO

決策建議

業務穩定、無新接入計劃、團隊小 → 薄適配，YAGNI 原則。
持續接入新渠道、需單元測試、想屏蔽第三方變更 → 獨立 DTO + MapStruct/Dozer 自動映射。
折中：核心共用字段定義統一 DTO，差異字段用 `Map` 或 `Extension` 字段攜帶，兼顧靈活與結構。

代碼骨架（獨立 DTO 模式）

public interface UnifiedService {
    Result process(UnifiedRequest req);
}

@Component
public class AdapterA implements UnifiedService {
    @Autowired AClient aClient;
    public Result process(UnifiedRequest req) {
        ARequest aReq = AMapper.toARequest(req); // MapStruct 生成
        AResponse aResp = aClient.call(aReq);
        return AMapper.toUnifiedResult(aResp);
    }
}

引入 MapStruct 後，映射代碼編譯期生成，無運行時反射開銷，維護成本極低。