加一个字段要改 8 个文件？你写的可能不是 Go 架构

Wed, 01 Jul 2026 15:30:00 +0800

产品说，订单列表加一个 coupon_code。

你以为就是 SQL 多 select 一个字段，response 多返回一个字段。结果打开项目以后，手开始慢慢凉下来：

OrderDTO 要加，OrderEntity 要加，OrderModel 要加。mapper 要补一行。OrderRepository interface 要动。OrderUsecase 要接。handler 要再转一遍。测试里的 mock 还要跟着改。

业务逻辑没有变。

你只是多传了一个字段，却改了 8 个文件。

这不是 Go 项目“有架构”。这更像是 Java 包袱搬进 Go 以后，外面包了一层整洁架构的壳。

我不反对分层，也不反对 DDD、Clean Architecture、六边形架构。它们在复杂业务、复杂团队、复杂边界里当然有价值。

但很多 Go 项目的问题不在“没有架构”。恰恰相反，问题是一开始就太有架构了。

目录看起来很专业，修改点却到处散。interface 很多，真正替换实现的地方几乎没有。DTO、domain model、db model 分得很干净，字段却 1:1 复制。新人进来先学半天目录宗教，再开始找业务逻辑。

这篇想压住一个判断：

Go 项目的架构，不看目录层数，看你能不能在 30 秒内找到修改点，用一个业务词 grep 出主要路径。

分层不是错，空转的分层才是成本

一个常见的后端惯性是：handler 不能碰业务，service 承接业务，usecase 编排流程，domain 保持纯净，repository 负责存储，adapter 负责外部系统。

听起来都对。

问题是，真实项目里很多层并没有承担真实边界，只是在转发参数。

1
2
3
4
5
6
7


func (h *OrderHandler) List(ctx context.Context, req ListReq) (ListResp, error) {
 return h.uc.List(ctx, req.ToDTO())
}

func (u *OrderUsecase) List(ctx context.Context, dto ListOrderDTO) (ListOrderDTO, error) {
 return u.repo.List(ctx, dto)
}

这种代码不是不能写。问题是，如果每一层都只是换个名字继续往下传，它没有降低复杂度，只是在制造跳转。

Clean Architecture on Zampo Blog

加一个字段要改 8 个文件？你写的可能不是 Go 架构

分层不是错，空转的分层才是成本