加载中…
实验准备中…
实验准备中…
结合以下目标：Go 后端、AI 协作开发、代码可读性、长期可维护性、避免过度设计，推荐排名如下。
| 排名 | 架构设计 | 适用场景 | 推荐程度 |
|---|---|---|---|
| 🥇 1 | 轻量模块化单体（Lightweight Modular Monolith） | 大多数 Go 后端、中长期项目、AI 协作 | 最推荐 |
| 🥈 2 | 垂直切片架构（Vertical Slice Architecture） | CRUD 密集、功能迭代快、按功能独立开发 | 高度推荐 |
| 🥉 3 | 实用分层架构（Pragmatic Layered Architecture） | 小型 API、MVP、简单业务 | 推荐 |
| 4 | 六边形 / Clean Architecture | 复杂业务规则、多外部依赖、严格隔离 | 按需采用 |
| 5 | 微服务架构（Microservices Architecture） | 多团队、独立部署、独立扩缩容 | 有条件采用 |
最终首选
myapp/
├── cmd/api/main.go
├── internal/
│ ├── app/
│ ├── platform/
│ ├── user/
│ │ ├── handler.go
│ │ ├── service.go
│ │ └── repo.go
│ ├── order/
│ └── payment/
├── migrations/
├── AGENTS.md
└── go.mod核心特点：
适合： 绝大多数需要长期维护的 Go 后端项目。
快速迭代首选
internal/
└── order/
├── create/
│ ├── handler.go
│ └── service.go
├── cancel/
│ ├── handler.go
│ └── service.go
└── get/
└── handler.go核心特点：
适合： 功能较多、CRUD 密集、频繁迭代的 API 项目。
简单项目首选
internal/
├── handler/
├── service/
├── repository/
└── config/依赖方向：
Handler → Service → Repository核心特点：
适合： 小型 API、CLI、MVP。
长期业务模块增多后，可逐步演进为模块化单体。
复杂业务按需采用
internal/
└── order/
├── domain/
├── application/
├── adapters/
│ ├── http/
│ └── postgres/
└── module.go核心特点：
适合： 订单、支付、财务、复杂状态机等业务模块。
无需让整个项目都采用六边形。
大型系统按需采用
services/
├── user-service/
├── order-service/
├── payment-service/
└── inventory-service/核心特点：
适合： 具有实际独立部署需求的中大型系统。
不建议项目初期直接采用。
正式推荐
| 维度 | 方案 |
|---|---|
| 基础架构 | Lightweight Modular Monolith |
| 代码组织 | 按业务模块分包 |
| 内部职责 | Handler / Service / Repo |
| 复杂业务 | 按需引入 Hexagonal / Clean |
| AI 协作 | AGENTS.md + 最小修改原则 |
| 质量保障 | 测试 + 基础 CI |
| 未来演进 | 只有出现真实独立部署需求时才考虑微服务 |
一句话定案： 采用轻量模块化单体作为基础，吸收垂直切片的业务内聚思想，复杂模块再按需引入六边形架构。