14-有界上下文-DDD领域驱动设计

title: "14 有界上下文（Bounded Context）"

学习目标

理解有界上下文（Bounded Context）的定义：一个显式的边界，在这个边界内，领域模型的所有术语和概念都有明确的含义
能识别 BC 边界：通过"术语冲突/模型差异/团队边界"来识别
能用 BC Canvas 工具来设计并文档化一个 BC

核心概念

有界上下文是什么

有界上下文是 DDD 战略设计的核心概念，它定义了一个显式的边界，在这个边界内：

通用语言统一：所有术语和概念都有明确的含义
领域模型一致：模型表达的业务含义一致
团队协作清晰：一个 BC 通常由一个团队负责

为什么需要 BC

如果没有 BC 边界，会发生：

术语冲突：同一个词在不同地方含义不同（例如"客户"在销售域 vs 财务域）
模型混乱：试图用一个"万能模型"表达所有业务，导致模型臃肿且难以理解
团队协作困难：不同团队对同一概念的理解不一致

BC 与子域的关系

课堂要明确区分：

子域（Subdomain）：业务关注点（问题空间）
有界上下文（Bounded Context）：解决方案空间，一个子域可能对应多个 BC

例如：

订单子域：业务关注点是"订单处理流程"
订单 BC：可能是"订单创建与支付上下文"
订单 BC（另一个）：可能是"订单履约与物流上下文"（如果业务复杂，可能拆成多个 BC）

课堂讲授：如何识别 BC 边界

识别信号

术语冲突：
- 同一个词在不同地方含义不同
- 例如"订单"在销售域 vs 财务域 vs 物流域
模型差异：
- 同一个业务概念在不同地方需要不同的属性/行为
- 例如"客户"在 CRM 域 vs 订单域
团队边界：
- 不同团队负责不同的业务关注点
- 团队边界往往是 BC 边界的候选
技术边界：
- 不同的技术栈/部署单元
- 例如微服务边界（但 BC 不等同于微服务）

BC 设计原则

一个 BC 一个模型：不要在 BC 之间共享领域模型
BC 之间通过接口协作：例如 API、事件、共享内核（谨慎使用）
BC 内部保持一致性：通用语言、模型、团队协作统一

BC Canvas：设计工具

BC Canvas 是 DDD-Crew 提供的协作工具，用于设计并文档化一个 BC。主要包含：

名称与职责：BC 的名称、核心职责、业务价值
领域模型：核心实体/聚合、值对象、领域事件
公共接口：对外暴露的 API、事件、命令
依赖：依赖的其他 BC、外部系统、基础设施
团队与指标：负责团队、成功指标、监控点

参考：DDD-Crew Bounded Context Canvas（见 references.md）

伪代码示例：BC 边界识别（电商场景）

text 复制代码

// BC 1：订单上下文（Order Context）
BoundedContext OrderContext {
  responsibility: "订单创建、支付、状态管理"
  coreAggregates: [Order, Payment]
  publicAPI: [CreateOrder, PayOrder, CancelOrder]
  domainEvents: [OrderCreated, OrderPaid, OrderCancelled]
  dependencies: [CustomerContext, ProductContext]
  team: "订单团队"
}

// BC 2：物流上下文（Logistics Context）
BoundedContext LogisticsContext {
  responsibility: "订单发货、物流跟踪、配送管理"
  coreAggregates: [Shipment, Delivery]
  publicAPI: [CreateShipment, TrackDelivery]
  domainEvents: [ShipmentCreated, DeliveryCompleted]
  dependencies: [OrderContext]
  team: "物流团队"
}

// 注意：OrderContext 与 LogisticsContext 的"订单"概念不同
// OrderContext: 订单 = 订单创建、支付、状态
// LogisticsContext: 订单 = 发货单、物流信息

Mermaid 图：BC 边界与集成（示例）

渲染错误: Mermaid 渲染失败: Parse error on line 14: ...OCPub -->|sync call (API)| LCCmd OCEvt -----------------------^ Expecting 'SQE', 'DOUBLECIRCLEEND', 'PE', '-)', 'STADIUMEND', 'SUBROUTINEEND', 'PIPE', 'CYLINDEREND', 'DIAMOND_STOP', 'TAGEND', 'TRAPEND', 'INVTRAPEND', 'UNICODE_TEXT', 'TEXT', 'TAGSTART', got 'PS'

常见误区

误区 1：BC = 微服务：BC 是逻辑边界，微服务是部署边界；一个微服务可以包含多个 BC，一个 BC 也可以拆成多个微服务
误区 2：BC 之间共享领域模型：应该通过接口/事件协作，而不是共享模型
误区 3：BC 划分过细：导致协作成本上升；应该根据业务复杂度与团队规模合理划分
误区 4：忽略 BC Canvas：BC Canvas 是很好的协作工具，应该用它来设计并文档化 BC

课堂练习

以"在线教育平台"为例，请识别 2-3 个 BC，并说明它们的边界与职责。
观察你所在的项目：请识别一个"术语冲突"的例子（同一个词在不同地方含义不同），并说明如何用 BC 边界来解决。
使用 BC Canvas 的格式（文字描述即可），设计一个"订单 BC"的 Canvas，包含：名称、职责、核心聚合、公共接口、依赖。

自测题

有界上下文与子域的区别是什么？
如何识别 BC 边界？
BC Canvas 的作用是什么？