2. 限界上下文(Bounded Context)核心思想：为什么需要限界上下文，以及它与微服务的关系
2.1 从“通用语言”到“上下文边界”
领域驱动设计强调团队内部使用统一的通用语言(Ubiquitous Language)来沟通业务概念。然而，同一个术语在不同的业务场景下往往具有截然不同的含义。例如，“用户”在“订单上下文”中是一个包含地址和支付信息的实体，而在“营销上下文”中则是一个包含偏好和积分的目标对象。
如果没有明确的边界，这些歧义会渗透到代码中，导致模型混乱、职责不清、团队协作效率低下。限界上下文(Bounded Context)正是为了解决这一问题而生的核心战术模式——它为通用语言划定了一个显式的、逻辑上的边界，确保每个业务概念在其边界内具有唯一、无歧义的含义。
核心定义： 限界上下文是领域模型中概念边界的显式表达。每个限界上下文内部维护一套独立的通用语言、领域模型和实现逻辑，上下文之间通过预定义的接口进行集成。
2.2 为什么需要限界上下文？—— 四大驱动力
| 驱动力 | 问题描述 | 限界上下文如何解决 |
|---|---|---|
| 语义歧义 | 同一术语在不同业务场景下含义不同，导致模型混乱 | 每个上下文内术语唯一，模型自洽 |
| 团队协作冲突 | 多个团队修改同一代码库，频繁冲突，交付效率低 | 每个上下文对应一个团队，拥有独立代码库和发布节奏 |
| 技术债务积累 | 单体应用中模块耦合严重，修改一处影响全局 | 上下文之间通过防腐层隔离，变更影响范围可控 |
| 扩展性瓶颈 | 业务增长后，单一模型无法满足不同场景的性能需求 | 每个上下文可选择独立的数据存储和架构风格 |
实践建议： 在 Go 项目中，限界上下文通常对应一个独立的
internal/ 目录或独立的 Go Module。例如：internal/order、internal/payment、internal/shipping。每个模块拥有自己的实体、值对象、仓储接口和领域服务。
2.3 限界上下文与微服务的关系
限界上下文是逻辑边界，微服务是物理边界。两者之间存在紧密但非一一对应的映射关系。理解这一关系是架构决策的关键。
- 理想映射： 一个限界上下文对应一个微服务。这是最推荐的做法，每个微服务拥有完整的领域模型自治权。
- 合并映射： 多个内聚性强的限界上下文合并为一个微服务。适用于初期团队规模小、业务复杂度低的场景。
- 拆分映射： 一个大型限界上下文拆分为多个微服务。当上下文内部出现明显的性能差异或团队分工需求时采用。
常见误区： 不要将数据库表结构作为划分微服务的依据。限界上下文应基于业务能力和通用语言划分，而非技术存储。先识别上下文，再决定微服务边界。
2.4 上下文映射：团队协作的蓝图
当多个限界上下文共存时，需要定义它们之间的协作关系。DDD 提供了几种标准的上下文映射模式，帮助团队明确集成策略：
- 合作关系(Partnership)： 两个上下文紧密协作，一方变更需双方协调。
- 共享内核(Shared Kernel)： 共享部分领域模型，通常用于高度耦合的模块。
- 客户-供应商(Customer-Supplier)： 上游(供应商)决定模型，下游(客户)适配。
- 防腐层(Anticorruption Layer)： 下游上下文通过适配器隔离上游模型的变更影响。
- 开放主机服务(Open Host Service)： 上下文对外暴露标准协议(如 REST/gRPC)。
- 发布语言(Published Language)： 使用标准数据格式(如 JSON Schema/Protobuf)进行通信。
Go 实现提示： 在 Go 中，防腐层通常通过接口定义在
internal/xxx/repository 或 internal/xxx/infrastructure 层。例如，订单上下文通过 PaymentService interface 调用支付上下文，具体实现在基础设施层完成。
2.5 在 Go 项目中识别限界上下文
识别限界上下文是 DDD 实践的第一步。以下是常用的识别方法：
- 事件风暴(Event Storming)： 与业务专家一起，用不同颜色的便签贴出领域事件、命令、聚合，自然形成上下文边界。
- 名词/动词分析： 提取业务语言中的核心名词(实体)和动词(操作)，将强相关的归为一组。
- 业务能力分解： 按业务部门或核心流程划分，如订单、支付、库存、物流。
- 变化频率分析： 将变化频率和原因不同的模块分离到不同上下文。
Go 项目结构示例：
myapp/
├── cmd/ # 应用入口
├── internal/
│ ├── order/ # 订单限界上下文
│ │ ├── domain/ # 领域模型
│ │ ├── application/ # 应用服务
│ │ └── infrastructure/ # 基础设施
│ ├── payment/ # 支付限界上下文
│ │ ├── domain/
│ │ ├── application/
│ │ └── infrastructure/
│ └── shipping/ # 物流限界上下文
│ ├── domain/
│ ├── application/
│ └── infrastructure/
└── pkg/ # 共享工具库2.6 小结
限界上下文是 DDD 从战略设计走向战术实现的桥梁。它通过划定语义边界，解决了大型系统中模型混乱、团队冲突和扩展性瓶颈三大核心问题。在微服务架构中，限界上下文是服务划分的首要依据——先有清晰的上下文边界，再有合理的微服务粒度。在接下来的章节中，我们将深入探讨如何在 Go 中为每个限界上下文构建领域模型。