1. 课程导论：什么是服务边界？为什么需要领域建模？DDD在微服务架构中的核心价值
微服务架构的落地实践中，最常被问及的问题是：“服务应该拆多细？” 以及 “如何避免服务间混乱的网状调用？” 这两个问题的答案，都指向同一个核心概念——服务边界。而领域驱动设计（DDD）正是定义服务边界、指导领域建模的最有效方法论。
1.1 什么是服务边界？
服务边界是一个逻辑与物理的划分单元，它定义了某个微服务“该做什么”和“不该做什么”。边界内部是高度内聚的业务逻辑，边界之间通过明确的接口（API/事件）进行通信。没有清晰边界的服务，会退化为“分布式单体”，丧失微服务应有的独立性与可演化性。
| 维度 | 有清晰边界的服务 | 边界模糊的服务 |
|---|---|---|
| 内聚性 | 一个服务只解决一个业务子域的问题 | 一个服务包含多个不相关的业务逻辑 |
| 耦合度 | 服务间通过轻量级契约通信，依赖少 | 服务间直接共享数据库或频繁RPC调用 |
| 变更影响 | 修改一个服务，不影响其他服务 | 修改一处，需要联动修改多个服务 |
| 团队自治 | 每个团队独立拥有并演进自己的服务 | 多个团队需要协调才能完成一次发布 |
关键认知： 服务边界不是技术选型决定的（如数据库类型、框架版本），而是由业务领域决定的。技术只是边界的实现载体。
1.2 为什么需要领域建模？
领域建模是将复杂的业务知识转化为可维护软件模型的过程。没有领域建模，开发团队容易陷入以下困境：
- 语言混乱： 业务方说“订单已审核”，开发方理解成“订单状态字段更新为2”，导致需求理解偏差。
- 模型贫血： 对象只有getter/setter，业务逻辑散落在Service层，难以测试和复用。
- 边界错位： 按数据表或技术分层拆分服务，而非按业务能力拆分，导致服务职责重叠。
领域建模通过统一语言（Ubiquitous Language）、限界上下文（Bounded Context）、实体（Entity）与值对象（Value Object）等战术模式，将业务专家的心智模型直接映射到代码中，从而确保软件模型与业务需求始终保持一致。
1.3 DDD在微服务架构中的核心价值
DDD 为微服务架构提供了从战略到战术的完整指导，其核心价值体现在以下三个层面：
- 战略设计：划定服务边界 —— 通过限界上下文识别出每个微服务的职责范围，避免服务粒度过粗或过细。
- 战术设计：指导内部实现 —— 使用聚合（Aggregate）、领域事件（Domain Event）等模式，保证服务内部的高内聚与数据一致性。
- 持续演进：应对业务变化 —— 当业务规则变化时，DDD 的模型可以局部重构，而不至于引发全局震荡。
实践建议： 在微服务拆分初期，优先使用 DDD 的事件风暴（Event Storming）工作坊，与业务专家一起识别领域事件和聚合，这是快速发现服务边界的高效方法。
1.4 服务边界与领域建模的关系图
下图展示了从业务问题空间到微服务实现空间的完整映射路径，其中限界上下文是连接领域模型与服务边界的桥梁。
1.5 常见误区与避坑指南
| 误区 | 表现 | 正确做法 |
|---|---|---|
| 按数据表拆分 | 每个数据库表对应一个微服务 | 按业务能力聚合多个表为一个服务 |
| 过度追求“完美模型” | 建模阶段花费数月，迟迟不写代码 | 先识别核心限界上下文，快速迭代验证 |
| 忽略统一语言 | 代码中的术语与业务术语不一致 | 强制团队使用业务词汇命名类、方法、变量 |
| 服务间共享数据库 | 多个服务直接读写同一张表 | 每个服务拥有自己的数据存储，通过API交互 |
注意： DDD 不是银弹。对于业务逻辑简单的 CRUD 系统，过度使用 DDD 会增加不必要的复杂度。建议在核心域（业务最复杂、最具竞争力的部分）优先应用 DDD，支撑域和通用域可适当简化。
1.6 本章小结
- 服务边界是微服务架构的基石，由业务领域而非技术决定。
- 领域建模通过限界上下文和统一语言，确保软件模型与业务模型对齐。
- DDD 的核心价值在于为微服务提供从战略到战术的完整设计指导，帮助团队实现高内聚、低耦合、可演进的系统。
在接下来的课程中，我们将深入事件风暴工作坊、聚合设计、领域事件建模等实战技术，逐步掌握从业务需求到微服务代码的完整映射路径。