1. 课程导论：API Design 与事务边界治理的关系、课程目标与前置知识、NestJS 在微服务中的角色
1.1 为什么 API Design 是事务边界治理的第一道防线
在分布式微服务架构中，事务边界不再局限于单个数据库连接，而是跨越多个服务、多个数据源甚至多个消息队列。传统数据库 ACID 事务在跨服务场景下几乎无法直接使用，开发者被迫转向 Saga、TCC、Outbox 等补偿或最终一致性模式。然而，一个被严重低估的事实是：API 的接口契约设计直接决定了事务边界的粒度与复杂度。
核心观点：API Design 不是事务治理的下游产物，而是上游约束。一个设计良好的 API 接口，天然将事务边界控制在单个资源或聚合根内；一个设计粗糙的 API，则迫使事务跨越多个服务节点，引入分布式协调开销与数据不一致风险。
下表对比了不同 API 设计风格对事务边界的影响：
| API 设计风格 | 典型事务边界 | 分布式协调复杂度 | 数据一致性保障 |
|---|---|---|---|
| RESTful 资源导向 | 单个聚合根（如 Order） | 低（本地事务为主） | 强一致（本地 ACID） |
| RPC 动作导向 | 跨多个实体或服务 | 高（需 Saga 编排） | 最终一致 |
| GraphQL 查询合并 | 按 resolver 拆分 | 中（需 DataLoader 批处理） | 视 resolver 实现而定 |
| 事件驱动（异步 API） | 消息边界 | 中（需 Outbox 模式） | 最终一致 |
实践建议：在微服务架构中，优先将 API 设计为“资源导向”的 RESTful 接口，每个接口对应一个明确的业务聚合根。这能天然地将事务边界限制在单个服务内部，避免跨服务分布式事务的引入。
1.2 课程目标与前置知识
本课程旨在帮助后端开发者建立从 API 设计到事务边界治理的完整认知链路，并掌握在 NestJS 框架下的具体落地方法。
课程目标
- 认知层：理解 API Design 如何影响事务边界的划分，掌握事务边界治理的核心原则。
- 设计层：学会使用 RESTful、GraphQL、gRPC 等 API 风格来约束事务范围，避免分布式事务陷阱。
- 实现层：在 NestJS 中配置 TypeORM、Mongoose、Prisma 等 ORM 的事务管理，结合拦截器、过滤器、管道实现声明式事务边界。
- 治理层：掌握 Saga、Outbox、TCC 等分布式事务模式在 NestJS 中的实现，以及如何通过 API 网关统一事务监控。
前置知识要求
| 知识领域 | 要求 | 说明 |
|---|---|---|
| Node.js / TypeScript | 熟练 | 能编写异步代码、装饰器、泛型 |
| NestJS 基础 | 掌握 | 模块、控制器、提供者、依赖注入 |
| 数据库基础 | 了解 | ACID、事务隔离级别、SQL 基础 |
| 微服务概念 | 了解 | 服务拆分、服务发现、消息队列 |
注意：本课程不从头教授 NestJS 基础语法。如果你对 @Module、@Injectable、@Controller 等装饰器不熟悉，建议先完成 NestJS 官方入门教程。
1.3 NestJS 在微服务中的角色：事务治理的枢纽
NestJS 并非一个简单的 HTTP 框架，它提供了完整的微服务基础设施支持。在事务边界治理中，NestJS 扮演了三个关键角色：
- API 网关层：统一接收外部请求，进行认证、限流、路由分发，是事务边界的入口控制点。
- 业务服务层：通过模块化设计，每个业务模块拥有独立的数据源和事务管理器，是事务边界的执行单元。
- 事件总线层：通过
@nestjs/cqrs或@nestjs/microservices实现事件驱动，是跨服务事务协调的通信基础设施。
下图展示了 NestJS 在微服务事务治理中的整体架构：
NestJS 优势：相比 Express 或 Fastify，NestJS 提供了 @nestjs/typeorm、@nestjs/mongoose、@nestjs/microservices 等官方集成包，使得事务管理、消息驱动、依赖注入可以无缝协作，极大降低了事务边界治理的代码侵入性。
1.4 事务边界治理的核心挑战
在微服务架构中，事务边界治理面临以下核心挑战：
| 挑战 | 描述 | API Design 应对策略 |
|---|---|---|
| 跨服务数据一致性 | 一个业务操作涉及多个服务的数据变更 | 设计聚合根 API，减少跨服务调用 |
| 分布式事务协调 | 需要 Saga 或 TCC 模式保证最终一致性 | API 接口幂等性设计 + 补偿接口 |
| 事务隔离级别 | 不同服务使用不同数据库，隔离级别不一致 | API 层定义业务隔离语义，而非依赖数据库 |
| 超时与重试 | 网络延迟或服务故障导致事务悬挂 | API 超时配置 + 重试策略 + 幂等令牌 |
| 事务监控与审计 | 难以追踪跨服务的事务执行链路 | API 请求 ID + 事务日志 + 分布式追踪 |
下图进一步展示了 API Design 如何从源头影响事务边界的划分：
常见误区：很多团队在微服务架构中直接使用分布式事务框架（如 Seata、DTM）来解决所有问题，却忽略了 API 设计本身对事务边界的决定性影响。一个设计良好的 API 可以减少 80% 的分布式事务需求，让系统回归简单可靠的本地事务。
1.5 课程路线图
本课程共 30 章，分为五个阶段：
| 阶段 | 章节范围 | 核心内容 |
|---|---|---|
| 基础篇 | 1-6 | API Design 与事务边界理论、NestJS 环境配置、ORM 事务管理 |
| 设计篇 | 7-14 | RESTful / GraphQL / gRPC 接口设计、聚合根与事务边界映射 |
| 实现篇 | 15-22 | 声明式事务、拦截器事务管理、Saga 编排、Outbox 模式 |
| 治理篇 | 23-27 | 事务监控、分布式追踪、幂等性设计、补偿策略 |
| 实战篇 | 28-30 | 电商订单系统完整案例、性能调优、生产部署 |