1. 课程导论：什么是软件架构边界？为什么 Go Web 项目需要关注依赖注入与模块解耦？
1.1 软件架构边界的本质
软件架构边界（Architecture Boundary）是系统内部不同职责区域之间的显式分隔线。它定义了“什么属于这里”与“什么属于那里”，并通过接口、契约或抽象层来强制隔离变化。在 Go Web 项目中，边界通常表现为：
- 层边界：Handler → Service → Repository → DB
- 模块边界：用户模块、订单模块、支付模块之间的依赖方向
- 基础设施边界：业务逻辑与外部 SDK、缓存、消息队列之间的适配层
核心原则：边界内的代码只依赖抽象，不依赖具体实现。依赖方向必须指向高层策略，而非低层细节。
1.2 为什么 Go Web 项目需要关注依赖注入与模块解耦？
Go 语言以简洁、静态编译、高并发著称，但它的包管理机制和隐式接口特性也容易导致架构退化。常见问题包括：
| 问题 | 表现 | 后果 |
|---|---|---|
| 循环依赖 | 包 A 引用包 B，包 B 又引用包 A | 编译失败，重构困难 |
| 全局状态耦合 | 使用全局变量管理 DB 连接、配置 | 单元测试不可行，并发安全风险 |
| 隐式依赖 | Service 内部直接 new Repository | 无法替换实现，难以 mock |
| 模块间直接调用 | 订单模块直接调用用户模块的内部函数 | 模块边界模糊，变更扩散 |
依赖注入（Dependency Injection, DI） 是解决上述问题的核心手段。它将依赖的创建与使用分离，让模块只声明“我需要什么”，而不关心“谁给我”。模块解耦 则通过接口定义、适配层、事件驱动等方式，确保模块之间只通过稳定的契约通信。
Go 的独特优势：Go 的隐式接口（duck typing）天然适合定义边界契约。你不需要显式声明“implements”，只要结构体满足接口方法签名，即可自动适配。这大大降低了引入 DI 框架的心理负担。
1.3 架构边界失效的典型场景
以下场景在 Go Web 项目中极为常见，也是本课程要重点解决的痛点：
- Handler 直接操作数据库：业务逻辑散落在 HTTP 处理函数中，无法复用。
- Service 层依赖具体数据库驱动：更换数据库时需要修改所有调用点。
- 模块间通过结构体引用耦合：用户模块导出 UserService 结构体，订单模块直接调用其方法。
- 测试时无法注入 mock：因为依赖在构造函数内部硬编码创建。
- 启动时依赖顺序混乱：全局 init() 函数相互依赖，导致启动顺序不可控。
1.4 课程目标与学习路径
本课程的目标是让你掌握一套可落地、可维护、可测试的 Go Web 架构边界实践。具体包括：
| 阶段 | 核心内容 | 产出物 |
|---|---|---|
| 基础篇（第 1-5 章） | 边界理论、Go 接口设计、依赖注入模式 | 理解边界概念，能手动实现 DI |
| 工具篇（第 6-12 章） | wire 框架、dig 框架、自定义 DI 容器 | 熟练使用主流 DI 工具 |
| 实战篇（第 13-22 章） | 分层架构、模块化拆分、事件驱动、适配层 | 构建可解耦的 Web 项目 |
| 进阶篇（第 23-30 章） | 测试策略、性能优化、微服务边界、遗留系统重构 | 能独立设计大型项目的架构边界 |
前置要求：你需要熟悉 Go 语言基础语法、接口、结构体、函数类型；了解 HTTP 服务的基本编写方式；具备至少一个 Go Web 项目的开发经验。
1.5 架构边界核心概念图
下图展示了 Go Web 项目中典型的架构边界分层与依赖注入关系：
1.6 学习路径建议
为了最大化学习效果，建议你按照以下节奏推进：
- 每周 2-3 章：每章包含理论讲解 + 代码示例 + 课后练习，建议动手实现所有示例。
- 每章结束后：在个人项目中尝试应用本章学到的边界原则。
- 遇到困难时：优先回顾第 1-5 章的基础概念，再进入工具篇和实战篇。
- 最终项目：课程结束时，你将拥有一个经过完整架构重构的 Go Web 项目模板。
本课程的核心交付：不是让你背诵理论，而是让你在 Go 项目中亲手画出边界线，并让依赖注入成为你的肌肉记忆。