1. 项目结构概述：为什么需要良好的项目结构、常见Go项目结构模式与领域边界概念引入

1.1 为什么需要良好的项目结构

在Go语言工程实践中，项目结构不仅仅是文件和文件夹的摆放方式，它直接决定了团队的协作效率、代码的可维护性以及系统的演进能力。一个糟糕的结构会导致以下典型问题：

• 循环依赖：包之间相互引用，编译失败，重构成本极高。
• 职责模糊：业务逻辑散落在各处，新人难以理解核心流程。
• 测试困难：基础设施代码与业务代码耦合，无法快速编写单元测试。
• 扩展性差：新增一个功能需要修改多个模块，容易引入回归缺陷。

良好的项目结构应当遵循以下原则：

1.2 常见Go项目结构模式

Go社区经过多年实践，形成了三种主流的项目结构模式。理解它们的适用场景是选择正确架构的前提。

1.2.1 Flat模式（扁平结构）

所有Go文件直接放在项目根目录或单一包下，适合小型工具、CLI应用或原型验证。

myapp/
├── main.go
├── handler.go
├── service.go
├── store.go
└── go.mod

• 优点：启动快，文件少，无需思考分层。
• 缺点：项目超过5000行后，命名冲突、循环依赖、查找困难等问题急剧上升。
• 适用：个人项目、一次性脚本、少于3个文件的微服务。

1.2.2 分层模式（Layered Architecture）

按技术职责将代码分为表现层、业务层、数据层，是大多数企业级Go项目的起点。

myapp/
├── cmd/
│   └── server/
│       └── main.go
├── internal/
│   ├── handler/      # HTTP/gRPC处理器
│   ├── service/      # 业务逻辑
│   ├── repository/   # 数据访问
│   └── model/        # 数据模型
├── pkg/              # 可复用的公共库
└── go.mod

• 优点：职责清晰，新人容易上手，适合CRUD密集型应用。
• 缺点：业务逻辑容易泄漏到handler层，导致“贫血模型”；当业务复杂时，层间耦合依然存在。
• 适用：标准Web服务、REST API、初期产品。

1.2.3 DDD模式（领域驱动设计）

以业务领域为核心，将技术实现封装在领域边界之内。每个限界上下文（Bounded Context）拥有独立的目录结构。

myapp/
├── cmd/
│   └── server/
│       └── main.go
├── internal/
│   ├── order/                # 订单限界上下文
│   │   ├── domain/           # 领域模型、值对象、领域事件
│   │   ├── application/      # 应用服务、DTO
│   │   ├── infrastructure/   # 持久化、消息、外部接口
│   │   └── interfaces/       # API、事件订阅
│   ├── payment/              # 支付限界上下文
│   │   ├── domain/
│   │   ├── application/
│   │   ├── infrastructure/
│   │   └── interfaces/
│   └── shared/               # 共享内核（值对象、通用工具）
└── go.mod

• 优点：业务边界清晰，每个上下文可独立演进、独立部署；领域逻辑与基础设施完全解耦。
• 缺点：学习曲线陡峭，需要团队对业务有深刻理解；过度设计会带来不必要的复杂度。
• 适用：复杂业务系统、中大型微服务、需要长期演进的产品。

1.3 领域边界概念引入

领域边界（Domain Boundary）是DDD中最核心的战术设计概念。它回答了一个关键问题：一段代码到底属于哪个业务上下文？

在传统分层架构中，边界是按技术维度划分的（handler / service / repository）。而在DDD中，边界是按业务语义划分的。每个限界上下文（Bounded Context）就是一个自治的领域边界，内部包含完整的领域模型、应用逻辑和基础设施适配。

领域边界具有以下特征：

• 自治性：边界内部可以独立完成业务操作，不依赖外部上下文的具体实现。
• 显式通信：上下文之间通过事件、API或消息进行交互，不允许直接访问内部领域对象。
• 统一语言：边界内的术语、概念、规则与业务专家使用的语言完全一致。
• 封装变化：基础设施的变更（如数据库从MySQL换为PostgreSQL）不会影响边界内的领域逻辑。

下面这张图展示了从Flat模式到分层模式，再到DDD模式的演进路径，以及领域边界如何逐步清晰化：

1.4 本章小结

项目结构是软件架构的物理体现。从Flat到分层再到DDD，每一次演进都在强化代码的边界意识。在接下来的章节中，我们将深入DDD的战术设计工具——实体、值对象、聚合、领域服务、仓储等，并结合Go语言特性，一步步构建出真正具备领域边界的生产级项目结构。