Loading…
Warming up the lab…
Warming up the lab…
选型结论：采用四层 Clean Architecture，先按职责分层（Layer First），层内按业务功能组织（Feature Second）。适用于需要长期维护的 Go API 服务。
myservice/
├── cmd/
│ └── api/
│ └── main.go # 程序入口
├── internal/
│ ├── domain/ # 领域实体与业务规则
│ │ ├── user/
│ │ │ ├── user.go
│ │ │ └── user_test.go
│ │ ├── order/
│ │ │ ├── order.go
│ │ │ └── status.go
│ │ └── product/
│ │ └── product.go
│ ├── usecase/ # 应用用例与所需接口
│ │ ├── user/
│ │ │ ├── create.go
│ │ │ ├── get.go
│ │ │ ├── repository.go # Repository 接口
│ │ │ └── create_test.go
│ │ ├── order/
│ │ │ ├── create.go
│ │ │ ├── cancel.go
│ │ │ └── repository.go
│ │ └── product/
│ │ └── list.go
│ ├── delivery/ # 外部请求接入及 DTO 转换
│ │ ├── user/
│ │ │ ├── handler.go
│ │ │ ├── request.go
│ │ │ ├── response.go
│ │ │ └── routes.go
│ │ ├── order/
│ │ │ └── handler.go
│ │ └── product/
│ │ └── handler.go
│ ├── repository/ # 持久化接口的具体实现
│ │ ├── user/
│ │ │ └── postgres.go
│ │ ├── order/
│ │ │ └── postgres.go
│ │ └── product/
│ │ └── postgres.go
│ ├── platform/ # 技术设施（按需增加）
│ │ └── postgres/
│ │ └── connect.go
│ ├── config/
│ │ └── config.go
│ └── bootstrap/
│ └── bootstrap.go # 显式依赖注入与程序组装
├── migrations/ # 数据库迁移
├── go.mod
└── go.sum目录树是目标结构示例，不要求初始化项目时创建所有目录。业务、层或实现不存在时，就不创建对应包。
| 目录 | 职责 | 依赖约束 |
|---|---|---|
domain/ | 业务实体、规则、不变量 | 不依赖外层、HTTP 框架或数据库驱动 |
usecase/ | 编排业务流程，定义自己需要的接口 | 可依赖 domain；不依赖具体 repository 实现 |
delivery/ | HTTP/gRPC 等入口、请求校验和 DTO 转换 | 调用 usecase；不直接访问数据库实现 |
repository/ | PostgreSQL 等持久化实现 | 实现内层定义的接口，可使用数据库驱动 |
platform/ | 数据库连接池等技术组件 | 仅承载技术细节 |
bootstrap/ | 创建并组装依赖 | 唯一允许集中引用多层具体实现的组装位置 |
典型请求流：delivery → usecase → Repository 接口，实际实现由 bootstrap 注入 repository。调用可以向外，源码依赖必须按约束指向内层抽象。
domain、usecase、delivery、repository、user、order。userService、user_service；文件名允许下划线，例如 user_test.go。user 而非 users，repository 而非 repositories。common/、util/、helper/、misc/；按真实职责命名包。cmd/api/main.go 声明 package main；业务实现优先放在 internal/，不为普通服务预设 pkg/、src/。interfaces/。单一实现且没有测试替身需求时，可暂不抽象。user）是合法的；集中组装时按需使用 import alias。若遇到 user.User 等名称重复，可审视导出类型命名，或将简单领域类型按文件收拢到 internal/domain 包。delivery/user/ 中增加适配代码；协议代码过多时，再细分 delivery/user/http/ 与 delivery/user/grpc/。repository/user/ 增加实现文件；如果技术依赖明显不同，再拆成子包。domain，把应用流程留在 usecase；不要让 Handler 或 SQL 层承担业务规则。说明：上述目录命名是综合 Go 官方规范与成熟实践的工程建议，不是 Go 官方发布的唯一标准目录模板。