控制器与业务服务间中间层的实现实践及相关问题

先看当前控制器的实现代码：

public class Controller {
    public Response1 test1(Request1 request1){
        ServiceInputDto1 serviceInputDto1 = mapper.map(request1, ServiceInputDto1.class);
        ServiceOutputDto1 serviceOutputDto1 = service1.test(serviceInputDto1);
        Response1 response1 = mapper.map(serviceOutputDto1, Response1.class);
        return response1;
    }

    public Response2 test2(Request2 request2){
        ServiceInputDto2 serviceInputDto2 = mapper.map(request2, ServiceInputDto2.class);
        ServiceOutputDto2 serviceOutputDto2 = service2.test(serviceInputDto2);
        Response2 response2 = mapper.map(serviceOutputDto2, Response2.class);
        return response2;
    }
}

针对将DTO映射、业务服务调用逻辑从控制器中分离的需求，以下是对应问题的解答：

问题1：此类场景下单独设置该中间层是否合理？ #

完全合理。控制器的核心职责应该是处理HTTP协议相关逻辑（比如接收请求、返回响应、处理状态码），把DTO映射、初步校验、服务调用这些和业务衔接的逻辑抽出来，能让控制器更简洁，职责更单一。同时，后续调整映射规则、修改校验逻辑时，不用改动控制器代码，复用逻辑也能集中管理，降低维护成本。

问题2：该中间层属于哪种设计模式？ #

这个中间层最贴合的是服务层门面（Service Facade）模式，属于Facade（外观）模式的细分场景。和传统Facade统一对外提供粗粒度接口不同，这里的Facade专门承担控制器与业务服务之间的适配工作：将控制器的Request/Response DTO转换为业务服务能识别的DTO，执行初步校验（比如必填项检查、格式校验），调用对应业务服务，最后把服务返回结果转成响应DTO。核心作用是适配和解耦，让控制器与业务服务互不依赖对方的DTO结构。

问题3：是否值得将所有业务服务调用整合到同一层（单个类）中？ #

不建议这么做。如果业务场景复杂，单个类会迅速变得臃肿，违反单一职责原则，后续维护和扩展会非常麻烦。更好的做法是按业务领域拆分：比如订单相关的适配逻辑放到OrderFacade，用户相关的放到UserFacade，每个类只负责一个领域的适配工作，代码结构更清晰，也方便团队分工维护。当然，如果是小型项目或业务极简单，暂时整合到单个类没问题，但业务扩张后一定要拆分。

内容的提问来源于stack exchange，提问作者CostaVi