微服务下 DTO 设计核心原则

文章目录


前言

微服务下 DTO 设计核心原则:

对外稳定,对内隔离,禁止直接复用数据库对象。


一、微服务调用链

text 复制代码
order-service
   ↓ Feign / RPC
user-service
stock-service
coupon-service
pay-service

服务之间传的对象一般就是:

text 复制代码
RequestDTO / ResponseDTO

二、推荐命名

请求对象

java 复制代码
CreateOrderRequest
DeductStockRequest
UserQueryRequest

或者:

java 复制代码
CreateOrderDTO
DeductStockDTO

我更推荐微服务接口用:

text 复制代码
XXXRequest / XXXResponse

因为语义更清楚。


三、Feign 接口示例

stock-api 模块

java 复制代码
@FeignClient(name = "stock-service")
public interface StockClient {

    @PostMapping("/api/stock/deduct")
    StockDeductResponse deduct(@RequestBody StockDeductRequest request);
}

请求 DTO

java 复制代码
public class StockDeductRequest {
    private Long skuId;
    private Integer count;
    private String requestId;
}

返回 DTO

java 复制代码
public class StockDeductResponse {
    private Boolean success;
    private String code;
    private String message;
}

四、微服务 DTO 不要放在哪?

不要放在:

text 复制代码
order-service 内部 domain 包
stock-service 内部 entity 包

否则其他服务依赖会很乱。

推荐建独立 API 包:

text 复制代码
stock-api
  ├── client
  │   └── StockClient.java
  ├── dto
  │   ├── StockDeductRequest.java
  │   └── StockDeductResponse.java

然后:

text 复制代码
order-service 依赖 stock-api
stock-service 实现 stock-api

五、不要直接暴露 Entity / DO

错误示例:

java 复制代码
@PostMapping("/user/get")
UserDO getUser(@RequestBody UserDO user);

问题:

text 复制代码
数据库结构泄露
字段一改,调用方全炸
可能暴露敏感字段
服务边界不清晰

正确:

java 复制代码
UserQueryRequest
UserResponse

六、DTO 要分"入参"和"出参"

不要一个对象到处复用。

错误:

java 复制代码
UserDTO 同时用于创建、修改、查询、返回

正确:

java 复制代码
UserCreateRequest
UserUpdateRequest
UserQueryRequest
UserResponse

因为不同场景字段不一样:

text 复制代码
创建需要 password
返回不能有 password
修改可能只传 nickname
查询可能只传 userId/mobile

七、统一返回结构

微服务之间建议统一响应:

java 复制代码
public class RpcResult<T> {
    private boolean success;
    private String code;
    private String message;
    private T data;
}

例如:

java 复制代码
RpcResult<UserResponse> getUser(UserQueryRequest request);

八、版本兼容很重要

DTO 一旦被其他服务依赖,就不能随便改。

推荐规则:

text 复制代码
新增字段:可以
删除字段:谨慎
改字段类型:禁止
改字段含义:禁止
字段重命名:基本等于破坏兼容

如果必须大改:

text 复制代码
/api/v2/user/query
UserQueryV2Request
UserV2Response

九、订单服务调用用户服务示例

java 复制代码
@Service
public class OrderService {

    private final UserClient userClient;

    public OrderService(UserClient userClient) {
        this.userClient = userClient;
    }

    public void createOrder(Long userId) {
        RpcResult<UserResponse> result =
                userClient.getUser(new UserQueryRequest(userId));

        if (!result.isSuccess()) {
            throw new RuntimeException("查询用户失败");
        }

        UserResponse user = result.getData();

        // 创建订单逻辑
    }
}

十、推荐目录结构

text 复制代码
user-api
  ├── client
  │   └── UserClient.java
  ├── request
  │   └── UserQueryRequest.java
  ├── response
  │   └── UserResponse.java
  └── result
      └── RpcResult.java

user-service
  ├── controller
  ├── service
  ├── domain
  ├── mapper
  └── converter

order-service
  ├── controller
  ├── service
  └── client

一句话总结

微服务 DTO 是服务契约,不是数据库对象;Feign/RPC 接口要用独立 API 模块维护 Request/Response,并注意版本兼容。

相关推荐
dsyuan0012 小时前
基于 Vue3 + ElementPlus 极简搭建仿钉钉流程设计器,简洁架构、极易扩展,纯div+css布局
css·架构·钉钉
隔窗听雨眠3 小时前
无辅助损失函数的负载均衡:DeepSeek MoE架构的核心突破
运维·架构·负载均衡
SelectDB技术团队4 小时前
Apache Doris 多云原生实践:SaaS、BYOC 与四大公有云覆盖
数据库·阿里云·云原生·华为云·腾讯云·亚马逊云·写入更新
ZGIAI12 小时前
ZGI 让那些"等你去处理"的事,真正跑起来
人工智能·架构
ZGIAI12 小时前
ZGI:别再做Agent Demo了,先问问它在业务里能不能撑过下周三
人工智能·架构
鹤落晴春12 小时前
有状态应用 vs 无状态应用
运维·云原生·k8s
mohesashou14 小时前
k8s的service
云原生·容器·kubernetes
黑马程序员毕设16 小时前
基于Java的医院药品管理系统的优化设计与实现
java·开发语言·spring boot·小程序·架构·课程设计·毕设
头茬韭菜16 小时前
第 01 篇:「架构鸟瞰与进程启动链路」—— JobManager / TaskManager 从零长出来的完整调用链
架构·flink
CaseyWei16 小时前
Harness 架构 Multi‑Agent(多智能体)完整深度解析
人工智能·ai·架构·harness