Spring Boot中服务返回DTO而非实体时，跨服务调用该如何处理DTO？

方案选型建议 #

优先选择给Service A新增返回Entity的内部专属方法，次选调用Service A后转DTO为Entity，禁止直接在Service B中调用Repository A。 #

为什么不能直接跨Service调用Repository

• 破坏职责边界：所有和Entity A相关的业务规则（校验逻辑、缓存逻辑、字段补全、权限控制）都收敛在Service A层，直接调用Repository A会跳过所有上述逻辑，极易产生数据不一致问题
• 提升维护成本：后续Entity A的查询规则调整时，所有直接调用Repository A的位置都要同步修改，不符合单一职责原则

为什么不推荐DTO转Entity的方案

• 存在字段缺失风险：DTO是面向外部调用裁剪后的传输对象，通常不会包含Entity的全量字段，强制转回Entity很容易触发空指针异常
• 存在冗余开销：多了一层不必要的对象转换性能消耗，同时属于语义错配（DTO的设计目标就是对外输出，不是内部服务流转用的数据结构）

最优落地方案

给Service A拆分两类方法，通过命名区分使用场景：

1. 对外暴露方法：给Controller/外部系统调用，返回DTO，命名以DTO后缀标识，比如getXXXDTO()
2. 对内共享方法：给项目内部其他Service调用，返回Entity，命名不带后缀，也可以增加@Internal注解标注为内部方法，控制访问权限

调整后的代码示例：

// Service A 调整后代码
@Service
public class ServiceA {
    @Resource
    private RepositoryA repositoryA;
    @Resource
    private ModelMapper modelMapper;

    // 对内方法：仅内部服务调用，返回全量Entity，包含所有业务校验逻辑
    public EntityA getEntityA(Long id) {
        return repositoryA.findById(id)
                .orElseThrow(() -> new IllegalArgumentException("对应A实体不存在，id:" + id));
    }

    // 对外方法：给Controller调用，返回裁剪后的DTO
    public DTOA getDTOA(Long id) {
        EntityA entityA = getEntityA(id);
        return modelMapper.map(entityA, DTOA.class);
    }
}

// Service B 调用示例
@Service
public class ServiceB {
    @Resource
    private ServiceA serviceA;

    public void yourBusinessMethod() {
        // 直接调用ServiceA的对内方法拿完整Entity，无转换开销，不会漏掉业务逻辑
        EntityA entityA = serviceA.getEntityA(1001L);
        // 后续业务逻辑处理
    }
}

如果受限于代码规范/历史包袱无法修改Service A的代码，再考虑DTO转Entity的方案，转换前需要做好必填字段的非空校验，避免运行时异常。

内容的提问来源于stack exchange，提问作者Sung Woo Hwang