2.1 业务能力地图
一句话
业务能力地图回答的是 “这家公司靠哪些本事赚钱”，不是 “有哪些系统”：能力是稳定的名词（订单受理、库存预占），系统是会变的实现；先把能力画出来，才知道哪些该自建、哪些该买、哪些该外包。
三个层次别混
| 层 | 回答什么 | 粒度 | 会变吗 |
|---|---|---|---|
| 能力（Capability） | 公司会做什么 | 粗（10–30 个） | 很少变 |
| 流程（Process） | 怎么把这些能力串起来 | 中（每个能力 1–3 条） | 常变 |
| 系统（System） | 用什么实现 | 细（几十到几百个服务） | 变得最快 |
常见错误：拿系统清单当能力地图。结果是 “能力” 写成 “订单服务、库存服务、支付服务”——这是实现，不是能力；一旦换技术栈，地图就作废。
能力的写法：名词 + 动词，不带技术
| ❌ 不是能力 | ✅ 是能力 |
|---|---|
| 订单服务 | 订单受理 |
| Redis 缓存 | 热点数据加速 |
| Kafka 消息队列 | 业务事件分发 |
| 微服务网关 | 统一接入与鉴权 |
判据：去掉技术名词后还说得通，才是能力。
实测：能力 → 边界映射检查（本机脚本）
一份 9 个能力的清单，映射到 6 个系统边界：
| 检查项 | 结果 |
|---|---|
| 能力总数 | 9 |
| 已映射 | 7 |
| 未映射 | 2（会员画像、客服工单） |
| 边界数 | 6 |
| 单边界承载最多 | 履约中心 2 个 |
判据：未映射 > 0 或单边界承载 > 40% 能力，说明边界划分有问题。本例 2 个能力无主（典型的 “谁都不管” 地带），要么补边界、要么明确 “暂不做”。
# 能力清单（可进仓库、可做检查）
capabilities:
订单受理: {boundary: 订单中心, owner: 交易组}
库存预占: {boundary: 库存中心, owner: 供应链组}
信用审核: {boundary: 风控中心, owner: 风控组}
拣货打包: {boundary: 履约中心, owner: 履约组}
开票: {boundary: 财务中心, owner: 财务组}
会员画像: {boundary: null, owner: null} # ← 未映射，检查会报出来
反模式
| 反模式 | 后果 |
|---|---|
| 用系统/服务清单当能力地图 | 换个技术栈地图作废，业务方看不懂 |
| 能力粒度太细（几百个） | 变成功能列表，失去 “看全局” 的意义 |
| 能力粒度太粗（3 个） | 无法判断 “该自建还是买” |
| 能力没有 owner | 出事没人认领，规划时互相推 |
| 只画 “现在有什么”，不画 “缺什么” | 无法支撑路线图 |
| 能力与组织一一对应 | 组织调整后地图失效（康威定律反噬） |
三条铁律
🔑 能力是名词，不带技术；带上技术就成了 “实现清单”。
🔑 每个能力必须有 owner 与边界；没有归属的能力 = 没人负责。
🔑 能力地图要能回答 “自建 / 买 / 外包”，否则只是张图。
自检
Q1 为什么 “订单服务” 不能算一个业务能力？
▸ 答案：因为它是实现，不是本事：能力应该是 “订单受理”（公司会接单并生成履约任务），“订单服务” 只是当前用微服务实现它。判据是 “换一种实现（单体、SaaS、外包）后，这个能力还在不在”——在，才是能力。
Q2 能力地图和 DDD 的限界上下文是什么关系？
▸ 答案：能力是业务视角（公司会做什么），限界上下文是模型视角（哪个模型负责这个词的语义）。一个能力通常对应一个上下文，但也可以一个能力拆多个上下文（如 “履约” 拆成仓储与配送）。两者要能对上，对不上就说明 “业务与模型脱节”。
Q3 能力粒度怎么定？
▸ 答案：按 “能否独立决策自建/买/外包” 定：能独立决策的，就是一个能力（订单受理、库存预占）；不能独立决策的（如 “点击按钮”）太细。经验值是 10–30 个能力覆盖一家中型公司。
Q4 实测里 2 个能力 “未映射”，该怎么处理？
▸ 答案：三选一：补边界（确实要做，但还没人负责）、明确不做（写进 “非目标”，避免以后扯皮）、并入已有边界（如 “客服工单” 并入 “履约中心” 的售后子域）。最糟的是留在 “未映射” 状态——它会在某天变成 “谁都在做、谁都做不好”。
Q5 为什么 “能力与组织一一对应” 是危险的？
▸ 答案：因为组织会调整（合并/拆分/换负责人），而能力相对稳定。一一对应会让 “组织一动，地图就废”，并且强化 “部门墙”——每个能力只服务自己的部门，跨能力的流程没人优化。正确做法是 “能力有 owner，但不绑定组织架构”。
Q6 能力地图怎么支撑 “自建 / 买 / 外包” 决策？
▸ 答案：按 “是否差异化 + 变更频率 + 合规要求” 三分：差异化强、变更快 → 自建；通用且成熟（HR、报销）→ 买 SaaS；非核心且可度量 → 外包。地图的作用是把这些能力列全，避免 “只对看得见的部分做决策”。
Q7 一张好的能力地图，读者能在 5 分钟内得到什么？
▸ 答案：三件事：公司靠什么赚钱（核心能力）、哪些能力是短板（未映射/无 owner/系统老旧）、下一步该投哪（路线图与能力的对应）。如果读者看完只记住 “有一堆方块”，说明地图画成了组织架构图或系统架构图。