Golang微服务项目如何组织代码_Golang微服务工程结构_网络技术

domain层只放纯粹的领域模型、核心规则及接口定义，如User结构体、Activate()方法、UserRegisteredEvent事件和UserRepository接口，禁止依赖外部包或含副作用操作。

domain 层不是“业务逻辑大杂烩”，而是纯粹的领域模型与核心规则。它不能依赖 infra、handler 或任何外部包，连 log、time 这类标准库之外的导入都要警惕。

常见错误是把数据库实体（如 UserModel）和领域对象（如 User）混在一起，或在 domain 里直接调用 redis.Client。正确做法是只定义接口（如 UserRepository），具体实现交给 infra 层。

handler 只做三件事：解析请求（c.Param / c.ShouldBindJSON）、调用 service、构造响应（c.JSON）。它不该有 if 判断业务分支，也不该拼接 SQL 或组装 DTO。

service 是协调者，负责编排 domain 对象、调用多个 repository、处理事务边界。它可返回 error，但绝不返回 http.StatusXxx —— 那是 handler 的责任。

handler 中不要出现 if user.Status == "inactive" 这类业务判断，应交由 service 返回明确 error（如 ErrUserInactive）
service 方法名建议用动词+名词，如 TransferMoney()、CancelOrder()，而非 DoSomething()
避免在 service 里 new repository 实例；通过构造函数注入，便于单元测试 mock

pkg 放可复用、无项目上下文的通用能力，比如 pkg/trace（OpenTelemetry 封装）、pkg/validator（自定义校验规则）。它必须能被其他项目 go get 直接引用。

internal 是项目私有层，包括 internal/handler、internal/service、internal/infra —— 它们互相引用没问题，但外部模块无法 import internal/xxx，这是 Go 编译器强制的隔离机制。

微服务通常只有一个 cmd/{service-name}/main.go，它负责初始化配置、注册 infra 组件、构建 service 实例、启动 HTTP/gRPC server。所有依赖注入都在这里完成。

go.mod 必须位于项目根目录，且 module 名不能带 /cmd 或 /internal 后缀（如 github.com/your/project），否则 go list -m all 会混乱，CI 构建时 vendor 或 go install 可能失败。

绝对禁止在 internal/service 里 import cmd/xxx —— 这会立刻触发循环引用编译错误
配置结构体（如 type Config struct { DB *DBConfig }）建议放在 internal/config，由 cmd 层解析后传入各组件
如果用了 Wire 生成依赖注入代码，wire.go 必须和 main.go 在同一目录，且 //go:build wireinject 注释不可少

最易被忽略的是测试时的包可见性：写集成测试想 moc

k infra/mysql，结果发现它被 internal/service 直接 new 出来 —— 这说明初始化逻辑没收口到 cmd 层，重构成本会陡增。