Bounded Context Canvas（限界上下文画布）

解决什么问题：识别 BC 后，每个 BC 的核心要素需要结构化记录——战略目标、关键场景、通用语言、关键指标——Bounded Context Canvas 提供一页式结构，让 BC 团队对齐"我们这个 BC 到底是什么"。

它是什么

Bounded Context Canvas（由 Nick Tune 提出）是一页式文档模板，用于结构化定义单个 BC：

战略（为什么存在）：BC 的目的、核心价值、关键差异化
业务（做什么）：核心场景、领域事件、关键用户旅程
机会（怎么做）：核心子域、关键差异化能力、战略分类（Core / Supporting / Generic）
战术（内部结构）：聚合、关键不变量、技术决策
协作（与谁互动）：上下游 BC、ACL / OHS / Published Language

一张 A3 纸或一个 Markdown 文档，每个 BC 一份，团队共识 + 持续更新。

Nick Tune： "The Bounded Context Canvas is a shared tool to design and document a Bounded Context strategically."

V2 视角（B1 + B3 + B4 + B6 合一）：Canvas 是单 BC 的"宪法"——B1（它是什么）+ B3（怎么分解）+ B4（怎么抽象）+ B6（怎么权衡）在一页内对齐。

关键属性

属性	值/含义
范围	单个 BC
形式	一页式（一张 A3 纸或一个 Markdown）
参与者	BC 团队全员（业务 + 开发 + 测试 + 产品）
更新频率	BC 演化时更新（不是一次性）
反模式	写成 30 页设计文档
核心约束	必须能在 30 分钟内向新人解释清楚本 BC
存储	Git 仓库 + Markdown（版本化）

怎么用

场景 1：从 Event Storming 产出画 Canvas

前置：Event Storming 已识别出 BC 边界。

步骤：

选一个 BC——核心域优先
填写战略部分——业务专家说"这个 BC 为什么存在"
填写业务部分——把 Event Storming 中的事件归类
填写机会部分——评估子域分类（Core / Supporting / Generic）
填写战术部分——开发团队填聚合、不变量、技术选型
填写协作部分——标注 Context Map 关系

场景 2：Canvas 模板（标准 9 段）

┌──────────────────────────────────────────────────────────┐
│ BC 名称：OrderContext                                      │
│ 分类：Core Domain（核心域）                                 │
│ 战略目标：电商订单核心业务，差异化竞争力                    │
├──────────────────────────────────────────────────────────┤
│ 1. 目标       │ 2. 业务驱动力                               │
│ - 提供下单能力 │ - 转化率提升                                 │
│ - 订单履约协调 │ - 履约时效                                   │
├────────────────┼──────────────────────────────────────────┤
│ 3. 核心场景   │ 4. 用户旅程                                 │
│ - 用户下单     │ - 客户下单 → 支付 → 发货 → 完成              │
│ - 商家接单     │                                              │
├────────────────┼──────────────────────────────────────────┤
│ 5. 关键事件   │ 6. 关键指标                                  │
│ - OrderCreated │ - 订单成功率                                 │
│ - OrderPaid    │ - 平均履约时间                               │
│ - OrderShipped │ - 客单价                                     │
├────────────────┼──────────────────────────────────────────┤
│ 7. 通用语言   │ 8. 子域分类                                 │
│ - 订单 = ...   │ - Core：下单逻辑                             │
│ - 商品 = ...   │ - Supporting：评价                           │
│                │ - Generic：地址簿                            │
├────────────────┴──────────────────────────────────────────┤
│ 9. 上下文映射关系                                            │
│ OrderContext [U] → PaymentContext (Customer-Supplier)      │
│ OrderContext [U] → ShippingContext (Customer-Supplier)     │
│ OrderContext [D] ← InventoryContext (Shared Kernel)         │
│ OrderContext [U] ← Legacy CRM (ACL)                         │
└──────────────────────────────────────────────────────────┘

场景 3：评估 BC 战略价值

子域分类三问：

差异化？——这是公司竞争力的核心吗？是 → Core Domain
必需但不差异化？——需要做但不构成竞争力 → Supporting Subdomain
外包更便宜？——能用 SaaS 替代 → Generic Subdomain

分类	投资	自研/外包	团队
Core	重金	必须自研	最强团队
Supporting	适中	自研	普通团队
Generic	最小	外包 / SaaS	兼职维护

场景 4：审查现有 BC（治理场景）

步骤：

列出所有 BC 的 Canvas（5-10 份）
检查重复——多个 BC 有相似 Canvas = 合并候选
检查空白——Canvas 模糊不清 = 边界不清
检查漂移——Canvas 与实际代码不符 = 暗债
检查战略对齐——所有 BC 的"战略目标"是否对齐公司战略

常见误区

"Canvas = 设计文档"——错。Canvas 是对齐工具，不是实施细节。详细的代码设计另写
"一次画完就行"——错。BC 演化时 Canvas 必须更新（V2 B7）。每年审查一次
"30 分钟画完"——错。首次画需要 1-2 天（业务专家参与）。后续更新 1 小时
"Canvas 越详细越好"——错。一页式是约束。超过一页 = 信息过载
"Canvas 是开发的事"——错。业务专家必须参与——否则战略目标描述失真
"所有人共用一份 Canvas"——错。每个 BC 一份 Canvas（独立的）

关键洞察

Bounded Context Canvas = BC 的"一页式宪法"——战略 + 业务 + 战术 + 协作在一页内对齐。
价值：
新成员入职：30 分钟理解本 BC
跨团队协作：快速理解对方 BC 的能力与边界
架构治理：定期审查所有 Canvas，识别漂移与重复
这是 V2.7 B1（认识对象）+ B6（权衡）+ B7（演化）的工程化——一页画 BC = 一页对齐团队。
判断 Canvas 是否生效 = 新成员看 Canvas 30 分钟能独立上手 BC 内的故事。 判断失败 = 看 Canvas 仍需要 1-2 周才能上手。

Bounded Context Canvas（限界上下文画布） ​

它是什么 ​

关键属性 ​

怎么用 ​

场景 1：从 Event Storming 产出画 Canvas ​

场景 2：Canvas 模板（标准 9 段） ​

场景 3：评估 BC 战略价值 ​

场景 4：审查现有 BC（治理场景） ​

常见误区 ​

关键洞察 ​

相关链接 ​