3. 限界上下文：什么是限界上下文？如何识别和划分业务边界

在 DDD 中，限界上下文（Bounded Context） 是划分业务模块边界的核心单元。它定义了一个显式的边界，在该边界内，领域模型、术语、规则和通用语言（Ubiquitous Language）具有唯一且一致的语义。简单来说，限界上下文就是“一个概念在某个上下文中才有确定含义”的物理或逻辑边界。

3.1 为什么需要限界上下文？

没有限界上下文，领域模型会退化为“大泥球”（Big Ball of Mud）。不同业务模块对同一实体的理解冲突，导致代码耦合、术语混乱、团队协作困难。限界上下文提供了以下关键价值：

3.2 如何识别限界上下文？

识别限界上下文需要从业务领域出发，结合组织结构和系统交互。以下是经过实践验证的识别步骤：

1. 梳理业务事件流： 与领域专家一起，列出核心业务事件（如“订单已提交”、“支付已确认”、“库存已扣减”）。每个事件通常属于一个明确的上下文。
2. 寻找术语歧义点： 当同一个术语在不同业务场景下含义不同时，就是划分边界的最佳信号。例如，“客户”在“销售上下文”中指购买方，在“售后上下文”中指服务对象。
3. 分析业务能力域： 将业务拆分为高内聚的能力组，如“商品管理”、“订单处理”、“支付结算”、“物流配送”。每个能力域往往对应一个限界上下文。
4. 映射组织架构（康威定律）： 团队结构会反向影响系统边界。通常一个团队负责一个或多个限界上下文，减少跨团队沟通成本。
5. 验证数据所有权： 每个上下文拥有自己的数据存储，不直接访问其他上下文的数据库。数据归属的独立性是边界的强信号。

3.3 限界上下文与业务模块的映射关系

在 Go 项目中，一个限界上下文通常对应一个独立的 Go Module 或 顶级包。这种映射关系保证了代码结构与业务边界的一致性。

3.4 限界上下文划分的常见模式

在实际划分中，存在几种经典的模式，可以帮助你快速决策：

• 按业务核心域划分： 将核心域（Core Domain）、支撑域（Supporting Domain）、通用域（Generic Domain）分别作为独立的上下文。核心域投入最多资源，通用域可引入现成解决方案。
• 按业务生命周期划分： 一个业务实体从创建到完成，不同阶段可能属于不同上下文。例如“订单”在“购物车上下文”中只是临时数据，在“订单上下文”中才是正式订单。
• 按组织边界划分： 如果两个团队负责不同的业务功能，即使业务逻辑紧密，也建议拆分为两个上下文，通过防腐层（Anti-Corruption Layer）隔离。

3.5 限界上下文关系图

下图展示了电商系统中四个典型限界上下文之间的协作关系。每个上下文拥有独立的领域模型，通过事件或 API 进行通信。

3.6 限界上下文与 Go 代码结构

在 Go 项目中，限界上下文通常映射为独立的顶级包。每个包内部遵循 DDD 的分层结构（如 domain、application、infrastructure、interfaces）。包之间通过接口依赖，不直接引用内部实现。

// 项目根目录
ecommerce/
├── product/                # Product Context
│   ├── domain/             # 领域模型、聚合、值对象
│   │   ├── product.go
│   │   └── category.go
│   ├── application/        # 应用服务、用例
│   │   └── product_service.go
│   ├── infrastructure/     # 持久化、外部服务
│   │   └── product_repo.go
│   └── interfaces/         # API、事件处理器
│       └── product_handler.go
├── order/                  # Order Context
│   ├── domain/
│   ├── application/
│   ├── infrastructure/
│   └── interfaces/
├── payment/                # Payment Context
│   ├── domain/
│   ├── application/
│   ├── infrastructure/
│   └── interfaces/
└── shipping/               # Shipping Context
    ├── domain/
    ├── application/
    ├── infrastructure/
    └── interfaces/

3.7 限界上下文划分的评估标准

完成初步划分后，可以使用以下标准评估边界是否合理：

3.8 限界上下文与通用语言的协同

每个限界上下文都拥有自己的通用语言（Ubiquitous Language）。这意味着同一个业务概念在不同上下文中可以有不同名称。例如：

• 在 Product Context 中，“商品”包含“SPU（Standard Product Unit）”和“SKU（Stock Keeping Unit）”两个概念。
• 在 Order Context 中，“商品”简化为“订单项（Order Item）”，只关心数量、价格和快照。
• 在 Shipping Context 中，“商品”进一步简化为“包裹内容（Parcel Content）”，只关心重量、体积和易碎属性。

这种术语的差异化是健康的，它反映了不同业务视角对同一实体的不同关注点。限界上下文保护了这种差异，避免了模型膨胀。