4. 限界上下文详解：定义、识别方法与上下文映射图
限界上下文（Bounded Context）是领域驱动设计的核心战术模式，也是 GoBFF 架构中划分服务边界、团队边界和数据边界的直接依据。本节将深入讲解限界上下文的定义、识别方法以及上下文映射图（Context Map）的绘制与解读。
4.1 限界上下文的定义
限界上下文是一个显式的边界，领域模型在这个边界内具有特定的含义和一致性。在边界内部，所有术语、规则和概念都是统一且无歧义的；超出边界，相同的词汇可能代表完全不同的含义。
| 维度 | 说明 | GoBFF 中的体现 |
|---|---|---|
| 语义边界 | 同一术语在不同上下文中含义不同 | “用户”在“订单上下文”中是买家，在“客服上下文”中是服务对象 |
| 模型边界 | 实体、值对象、聚合只在本上下文中完整 | 每个 BFF 服务拥有独立的领域模型，不共享数据库表 |
| 技术边界 | 独立部署、独立数据库、独立团队 | 每个 GoBFF 服务是一个独立的 Go module，拥有独立存储 |
| 一致性边界 | 事务一致性只保证在边界内 | 跨上下文使用最终一致性，通过事件或 RPC 同步 |
关键原则：限界上下文是“语言”的边界，而不是“功能”的边界。当两个团队对同一个词（如“订单”）有不同的理解时，就应该拆分为两个限界上下文。
4.2 限界上下文的识别方法
识别限界上下文是领域建模中最具挑战性的步骤之一。以下是四种经过验证的识别方法，建议组合使用。
4.2.1 方法一：基于通用语言（Ubiquitous Language）
- 收集术语表：与业务专家一起列出所有核心业务术语。
- 标记歧义词：找出那些在不同业务场景下含义不同的词汇。
- 分组聚类：将含义一致的术语归为一组，每组对应一个候选上下文。
- 验证边界：检查同一组内的术语是否在所有场景下都保持语义一致。
4.2.2 方法二：基于业务能力（Business Capability）
| 业务能力 | 典型上下文 | GoBFF 服务示例 |
|---|---|---|
| 商品管理 | 商品上下文 | product-bff |
| 订单处理 | 订单上下文 | order-bff |
| 支付结算 | 支付上下文 | payment-bff |
| 库存管理 | 库存上下文 | inventory-bff |
| 用户认证 | 身份上下文 | auth-bff |
4.2.3 方法三：基于子域（Subdomain）
将业务域划分为核心子域、支撑子域和通用子域，每个子域通常对应一个限界上下文。
- 核心子域：业务竞争优势所在，需要最精细的模型和最独立的上下文。
- 支撑子域：业务必需但非核心，可以简化模型或使用外部服务。
- 通用子域：行业通用能力（如认证、通知），可直接采用现成方案。
4.2.4 方法四：基于变更频率（Change Rate）
实践技巧：如果两个功能模块的变更频率差异超过 3 倍，或者经常因为一个模块的修改导致另一个模块需要回归测试，就应该考虑拆分为不同的限界上下文。
4.3 上下文映射图（Context Map）
上下文映射图是描述限界上下文之间关系的可视化工具。它不关注内部实现，只关注上下文之间的集成方式、团队协作模式和模型转换策略。
4.4 上下文映射图的核心关系类型
| 关系类型 | 方向性 | 耦合度 | 适用场景 | GoBFF 实现建议 |
|---|---|---|---|---|
| 合作关系 | 双向 | 高 | 两个上下文必须同时演进 | 使用 gRPC 双向流或共享事件总线 |
| 客户-供应商 | 单向 | 中 | 下游依赖上游接口 | 上游提供 HTTP/gRPC API，下游调用 |
| 防腐层 | 单向 | 低 | 防止外部模型污染内部模型 | 在 BFF 层实现适配器模式，转换 DTO |
| 开放主机服务 | 单向 | 低 | 对外提供标准化接口 | 定义 Protobuf 契约，生成客户端 SDK |
| 发布语言 | 单向 | 低 | 通过事件广播状态变更 | 使用 Kafka/RabbitMQ 发布领域事件 |
| 共享内核 | 双向 | 极高 | 两个上下文共享核心模型 | 提取公共模块，严格版本控制 |
| 分离方式 | 无 | 无 | 两个上下文完全独立 | 各自独立部署，无直接通信 |
常见误区：不要试图在上下文映射图中画出所有内部细节。映射图只关注“边界”和“边界之间的关系”，不关注边界内部的实体、聚合或仓储。过度细节会破坏映射图的可读性和战略价值。
4.5 识别限界上下文的实战步骤
- 事件风暴（Event Storming）：与业务专家一起，用便签纸贴出所有领域事件、命令、聚合和外部系统。
- 标记边界：在事件风暴结果上，用不同颜色的笔圈出语义一致的聚合组，形成候选上下文。
- 验证一致性：对每个候选上下文，检查内部术语是否无歧义，事务边界是否合理。
- 绘制映射图：确定上下文之间的关系类型，绘制上下文映射图。
- 映射到 GoBFF 服务：每个限界上下文对应一个或多个 GoBFF 服务，服务间通过 API 或事件通信。
GoBFF 实践建议：在 GoBFF 架构中，限界上下文通常直接映射为独立的 BFF 服务。每个 BFF 服务拥有自己的
internal/domain 目录，包含独立的实体、值对象和领域服务。跨上下文的数据交换通过 pkg/client 中的客户端 SDK 或事件总线完成。
4.6 限界上下文与 GoBFF 服务拆分对照
| 限界上下文 | GoBFF 服务 | 数据库 | 通信方式 | 团队 |
|---|---|---|---|---|
| 订单上下文 | order-bff |
order_db |
gRPC + 事件 | 订单团队 |
| 支付上下文 | payment-bff |
payment_db |
gRPC | 支付团队 |
| 库存上下文 | inventory-bff |
inventory_db |
事件 | 库存团队 |
| 用户上下文 | user-bff |
user_db |
HTTP | 用户团队 |
通过以上定义、识别方法和上下文映射图，你可以系统性地将复杂业务域拆分为高内聚、低耦合的限界上下文，为 GoBFF 架构中的服务划分提供坚实的理论基础。