Go项目中优雅实现CleanArchitecture

本文深入剖析了在Go项目中如何真正落地Clean Architecture，强调协议层（HTTP/gRPC/WebSocket）必须严格隔离于adapters/interfaces层，杜绝任何框架或序列化细节（如json tag、time.Time、数据库注解）侵入domain核心；通过强制DTO与domain实体的显式单向转换、Clock接口抽象时间逻辑、controller仅作请求解析与响应包装、usecase专注纯业务逻辑等关键实践，确保架构具备真正的可测试性、可维护性与协议无关性——这不是简单的分层命名，而是守护业务核心不被技术细节腐蚀的工程纪律。

协议层必须放在 adapters 或 interfaces 层，否则 domain 和 usecase 会随 HTTP/gRPC 协议变更而被动修改——这不是分层，是套壳。

HTTP controller 怎么写才不污染 usecase

controller 的唯一职责是：解析请求 → 调用 usecase → 格式化响应。它不能持有任何 infra 实例（如 *sql.DB、*redis.Client），也不能 import infrastructure 包。

• 构造函数只接收 usecase 接口，例如 func NewUserController(createUser CreateUserUsecase)
• request binding 和 response writing 全部在 controller 内完成，usecase 输入输出类型必须是纯 domain struct 或自定义 error
• HTTP 状态码（如 http.StatusConflict）只出现在 controller，usecase 返回的错误必须是 domain 定义的（如 ErrEmailAlreadyExists）
• 别在 controller 里做业务判断，比如 if user.IsActive { ... } —— 这属于 usecase 或 domain 方法该干的事

domain struct 为什么不能带 json: tag 和 time.Time

加了 json:"id" 就等于把 HTTP 序列化逻辑钉死在核心模型上；直接用 time.Time 则把时区、格式化、Now() 行为耦合进业务规则。

• domain struct 字段只能是基础类型（string, int64）、自定义枚举（type Role string）或 domain 内定义的值对象（type Email string）
• 时间字段统一用 int64（Unix timestamp）或 string（ISO8601）表示，生成和比较操作移至 application 层
• 若必须保留 time.Time，则定义 Clock 接口并在 usecase 构造时注入，避免调用 time.Now()
• json:、protobuf:、gorm: 等所有 tag 必须剥离，DTO（如 UserHTTPResponse）才负责适配

gRPC / WebSocket 协议适配的关键约束

它们不是“更高级的 HTTP”，而是生命周期和调用模型不同的适配器——但依赖流向不能变：协议状态归 adapter，业务动作仍走 usecase。

• gRPC 的 .proto 生成代码放 adapters/grpc/pb，服务实现（UnimplementedUserServiceServer）放 adapters/grpc，只调用 usecase 接口
• WebSocket 连接管理（心跳、广播、连接池）全在 adapters/ws，ConnectionManager 持有 domain 实体 ID（如 userID string），不持有 domain struct
• 长连接中触发的业务动作（如“用户上线通知好友”）必须封装成明确的 usecase 调用，而非在 handler 里直接查 DB 或发消息
• 不要让 domain 实体实现 proto.Message 接口——DTO 才该实现，且转换必须显式单向（mapToDomain() / mapToProto()）

最容易被忽略的是 DTO 和 domain struct 的指针混用：一旦 controller 把 &user 直接传给 usecase，后续任何对这个 struct 的修改都会穿透到 domain 层——必须用值拷贝或显式映射切断引用链。

今天关于《Go项目中优雅实现CleanArchitecture》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！