一、DDD 与微服务：领域驱动设计核心概念、限界上下文、微服务架构与 DDD 的关系
1.1 领域驱动设计的核心概念
领域驱动设计（Domain-Driven Design，DDD）是一种以业务领域为核心驱动力的软件设计方法论。它强调软件模型必须与业务专家的心智模型保持一致，从而在复杂业务场景中构建高内聚、低耦合的系统。DDD 的核心不在于技术实现，而在于通过统一语言（Ubiquitous Language）在团队内部建立对业务领域的共同理解。
核心要素： 统一语言、领域模型、限界上下文、实体、值对象、聚合、领域事件、仓储、工厂。
DDD 将软件系统划分为两个主要层次：战略设计与战术设计。战略设计关注宏观的领域划分与边界定义，战术设计则关注微观的模型实现模式。
| 层次 | 关注点 | 关键元素 |
|---|---|---|
| 战略设计 | 领域划分、边界定义、上下文映射 | 限界上下文、上下文映射图、核心域/支撑域/通用域 |
| 战术设计 | 模型实现、对象生命周期、业务规则 | 实体、值对象、聚合、领域事件、仓储、工厂 |
1.2 限界上下文：DDD 的战略基石
限界上下文（Bounded Context）是 DDD 战略设计中最重要的概念。它定义了领域模型的应用边界，在这个边界内部，统一语言、领域模型和业务规则保持严格一致。不同的限界上下文之间通过明确的契约进行通信，从而避免模型污染和语义冲突。
限界上下文的核心特征包括：
- 模型自治：每个上下文拥有独立的领域模型，模型只在该上下文中有效。
- 边界清晰：上下文之间通过接口、事件或消息进行交互，不共享内部实现。
- 团队对齐：一个限界上下文通常对应一个团队，团队对该上下文的模型和代码拥有完全所有权。
实践建议： 在微服务拆分过程中，限界上下文是确定服务边界的首要依据。一个限界上下文通常映射为一个微服务，但并非绝对——当上下文内部逻辑过于复杂时，可进一步拆分为多个服务。
1.3 微服务架构与 DDD 的关系
微服务架构是一种将单一应用程序划分为一组小型、自治服务的架构风格。每个服务围绕特定业务能力构建，独立部署、独立扩展、独立演进。DDD 与微服务架构之间存在天然的互补关系：DDD 提供业务建模与边界划分的方法论，微服务提供技术实现与部署运行的架构模式。
两者的核心对应关系如下：
| DDD 概念 | 微服务映射 | 说明 |
|---|---|---|
| 限界上下文 | 微服务边界 | 一个限界上下文通常对应一个或多个微服务 |
| 统一语言 | 服务接口契约 | gRPC/Protobuf 定义服务间通信的语义契约 |
| 聚合 | 服务内部事务边界 | 聚合保证服务内部的数据一致性 |
| 领域事件 | 异步消息/事件驱动 | 服务间通过事件进行最终一致性通信 |
| 仓储 | 数据访问层 | 每个服务拥有独立的数据库或数据存储 |
常见误区： 不要将微服务拆分等同于 DDD 的限界上下文划分。微服务拆分还需要考虑团队规模、部署频率、数据一致性要求、调用延迟等非功能因素。DDD 提供的是业务视角的边界，微服务拆分是技术视角的决策。
1.4 从限界上下文到微服务：战略映射
将 DDD 的限界上下文映射为微服务，需要遵循以下步骤：
- 事件风暴（Event Storming）：与业务专家一起识别领域事件、命令、聚合和限界上下文。
- 上下文映射（Context Mapping）：绘制上下文之间的关系，识别合作、共享内核、客户-供应商等模式。
- 服务粒度评估：评估每个限界上下文的复杂度、变更频率和团队能力，决定是否进一步拆分。
- 契约定义：使用 gRPC/Protobuf 定义服务间通信接口，确保契约与统一语言一致。
- 独立部署单元：每个微服务独立构建、测试、部署，拥有自己的数据存储。
1.5 本章小结
- DDD 核心：以业务领域为中心，通过统一语言和限界上下文建立与业务专家一致的模型。
- 限界上下文：是 DDD 战略设计的核心，定义了模型的有效边界，是微服务拆分的主要依据。
- 微服务与 DDD 的关系：DDD 提供业务建模方法论，微服务提供技术实现架构，两者互补而非替代。
- 战略映射：从事件风暴到限界上下文识别，再到服务粒度评估和契约定义，形成完整的从业务到技术的映射链路。