首页 > Golang > Go问答

Go 服务为什么要把外部 DTO 隔离在防腐层：接口演进与领域模型边界

来源：17golang原创

时间：2026-08-26 06:45:27 406浏览收藏

支付供应商把订单状态字段从 paid 改成了 settled，最先出问题的通常不是支付代码，而是 Go 服务里到处都在直接使用供应商 DTO。把外部 DTO 隔离在一层防腐层里，领域模型只接收自己的状态和值对象，接口变化就会被收拢在一个可测试的边界内。

防腐层不是为了多写几个 struct，而是让外部协议只在适配边界出现一次；核心业务只依赖自己的模型和语义。

要点速览

外部 DTO 负责协议形状，领域模型负责业务语义，两者不要混用。
映射函数要同时完成字段转换、枚举校验和缺失字段检查。
供应商版本变化时先改适配器，再用契约测试确认核心流程不变。

防腐层到底隔离了什么

这里的“腐化”不是代码质量抽象评价，而是外部系统的命名、空值规则和状态枚举逐渐渗入自己的业务模型。比如供应商响应可能长这样：

type VendorOrder struct {
    ID     string `json:"order_id"`
    Status string `json:"state"`
    PaidAt string `json:"paid_at"`
}

如果 VendorOrder 被订单服务、退款服务和消息消费者直接传递，任何一个调用方都可能依赖 state 的拼写、空字符串的含义或供应商的时间格式。防腐层的职责，就是把这些协议细节停在边界上。

业务压力出现时，为什么直接复用 DTO 会失控

直接复用最初看起来很省事：少一个类型，少一组赋值。但当供应商增加 refunded 状态，或者把付款时间改成 RFC3339Nano，影响面就不再是一个 HTTP 客户端。数据库映射、领域判断、日志字段和测试样例都会被迫跟着外部协议改。

更隐蔽的问题是语义错位。供应商的 paid 可能表示“已收到支付通知”，而业务里的“已支付”还要求金额核对通过。两个字段名字相近，业务含义却不等价。

用端口和适配器收住依赖方向

可以让应用层只依赖一个获取订单状态的端口，供应商客户端放在 adapter 包中。映射函数是唯一允许看见供应商字段名的地方：

type OrderStatus string

const (
    StatusPaid     OrderStatus = "paid"
    StatusRefunded OrderStatus = "refunded"
)

type OrderSnapshot struct {
    ID     string
    Status OrderStatus
    PaidAt time.Time
}

func mapVendorOrder(v VendorOrder) (OrderSnapshot, error) {
    if v.ID == "" {
        return OrderSnapshot{}, errors.New("vendor order_id is empty")
    }
    status, err := mapStatus(v.Status)
    if err != nil {
        return OrderSnapshot{}, err
    }
    paidAt, err := time.Parse(time.RFC3339, v.PaidAt)
    if err != nil {
        return OrderSnapshot{}, fmt.Errorf("parse paid_at: %w", err)
    }
    return OrderSnapshot{ID: v.ID, Status: status, PaidAt: paidAt}, nil
}

这里的校验顺序有意放在映射函数里：先挡住空主键，再转换状态，最后解析时间。应用层拿到的是可用的 OrderSnapshot，不需要重复猜测供应商字段是否可信。