bm-8x-flow

Imported from yufenghui/claude-code-skills (packages/business-modeling/skills/bm-8x-flow/SKILL.md). Install upstream with npx skills add yufenghui/claude-code-skills --skill bm-8x-flow. Copyright stays with the author.

8X Flow 引导

本 skill 引导你为业务系统（与盈利相关的系统）建模：以合同为最小业务上下文、权责履约为最小业务交互，产出合同上下文图、履约项、违约流转、变化点与弹性边界，用于划清服务边界、预判变化点。其视角源自财务 / 合同审计——不了解领域，也能凭权责与合同系统理解业务逻辑；核心是合同履约（凭证追溯由四色建模承担，见 bm-four-color）。

底层逻辑原则：结构化（MECE）

业务建模的底层思维是结构化——把业务拆成相互独立、完全穷尽（MECE）的结构。它不是产出后的一道自检，而是建模进行时的思维底座：

• 互斥（Mutually Exclusive）= 结构不重叠：业务先切成互不交叉的段落（8X Flow 的「总-分-总」三段、每个合同上下文互不交叉）。HTML 报告左侧的分组目录就是这层结构的可视化——分组是固定容器，不是 UI 装饰。
• 穷尽（Collectively Exhaustive）= 每段填满：各 section 随建模推进动态填充到所属分组，直到穷尽判据满足（五维度：上下文 / 履约项 / 违约 / 变化点 / 边界，判据见 ../../reference/output-format.md「穷尽纪律」）。报告末尾的 MECE 自检让"穷尽"看得见。

一句话：分组是结构（互斥），动态填充是穷尽——目录分组是 MECE 在 HTML 产出层的载体。

运行方式：增量引导 + 实时可视化

按 ../../reference/live-session.md 运行——参照 superpowers brainstorming：

• just-in-time 启动 live server（需要看图时才提议，不默认开），浏览器实时显示报告。
• 一次一问，按章节序列（见 live-session §4）增量推进，每章产出后浏览器自动刷新、用户确认再继续。
• 每章产出：详细只写 HTML（图/表/判别写进 report.html，浏览器实时显示），终端只给一两句摘要（做了什么 + 关键判别 + 要确认的问题），不重复完整方案，省 token。

8X Flow 的产出按「总-分-总」三段式组织（章节序列见下文「产出」）：第一段·总＝业务全局总览（合同上下文清单 + 业务全生命周期四阶段 + 无合同闸门）；第二段·分＝对每个合同上下文逐一走五步法（合同图 + 主要履约项表 + 凭证追溯图 + 违约流转图，每个上下文一组卡片）；第三段·总＝全局整合（变化点 + 弹性边界 + 业务模型全景图 + 走查）。五步法本身是单个合同上下文的建模单元，外层包一层"先找全上下文 → 逐个建模 → 整合"。

何时使用

适用：

• 建模业务系统（与盈利相关）
• 设计微服务 / 服务边界（合同上下文天然映射服务边界）
• 构造业务平台 / 中台（需识别可复用模式与变化点；中台建模见末尾「中台化」延伸章节，不在主体三段式建模展开）
• 需从业务结构预判变化点与弹性边界

不适用 / 改用（判断依据见 ../../reference/methods.md）：

• 领域系统（运营无关，如搜索引擎 / CMS）→ 对象建模 / 知识消化 / 四色
• 只需找领域事件 / 凭证链（不涉及合同履约）→ bm-four-color

前置：先判别领域系统 vs 业务系统

• 换运营方式（如加企业版）会变的功能 = 业务逻辑 → 用 8X Flow
• 换内容 / 载体（红薯→土豆、网文→网剧）仍成立的赚钱逻辑 = 业务逻辑
• 运营无关、描述某个问题域的 = 领域逻辑 → 用对象建模

不确定时默认：与盈利相关就用 8X Flow。

元模型（核心概念，详见 ../../reference/concepts.md）

• 合同上下文：最小业务上下文，只在两方之间（多方 = 多份双方合同），含两个角色
• 履约请求：一个时间段，由权利方发起，要求义务方在规定时限内完成
• 履约确认：一个时间点
• 凭证：履约请求 = 发起依据，履约确认 = 履约证明；在权责范围内按四色建模寻找
• 标的物：凭证涉及的对象（如商品），来自领域上下文（领域系统）

Request-Confirmation 是异步结构——这是业务的真实状态，不是技术选择。履约失败触发新的履约项，而非自动修正。

四类天然边界　8X Flow 把业务切成四类上下文，是系统天然的边界（详见 ../../reference/concepts.md 的"四类天然边界"）：合同上下文（最小业务上下文，聚合履约凭证）、履约上下文（合同内按履约项划分，= 弹性边界）、领域上下文（标的物所在，= 弹性边界）、渠道上下文（合同签约前，独立成界 + 第二大变化点）。本 skill 第二段对每个合同上下文建模，第三段收敛出履约 / 领域 / 渠道边界（合同上下文是服务边界但非弹性边界）。

建模工作流：总-分-总（增量推进，每段对应 report.html 章节）

启动 live server（见 ../../reference/live-session.md）后，按「总-分-总」三段逐章增量产出——每步问关键问题 → 更新 report.html → 浏览器自动刷新 → 用户确认 → 下一步。五步法是单个合同上下文的建模单元（第二段·分对每个上下文重复一组卡片）；外层先找全上下文（第一段·总）、最后整合（第三段·总）。

8X Flow 进度（三段式，增量追加进 report.html）：
第一段 · 业务全局总览（总，摘要级）
- [ ] 1. 领域 vs 业务判别 + 经营形态 + 业务全生命周期四阶段 → §1 业务定位与经营形态
- [ ] 2. 找全合同上下文 + 无合同四场景闸门 → §2 合同上下文清单
第二段 · 逐合同上下文详细建模（分，对每个上下文重复一组卡片）
- [ ] 3.N 上下文 N 走五步法：
        ① 找合同上下文，明确参与方 → 合同上下文图
        ② 找主要履约项（穷尽对价两侧），按四色找凭证 → 主要履约项表 + 凭证追溯图
        ③ 找违约情况（逐项），设新履约项 → 违约流转图
        ④ 重复 ③，直到不得不打官司 → 违约流转图（补全）
        ⑤ 标的物归领域上下文（凭证引用形态）
第三段 · 全局整合（总，骨架全景）
- [ ] 4. 变化点（穷尽两类）→ §4 变化点图
- [ ] 5. 弹性边界（穷尽三类）→ §5 弹性边界 / 服务图
- [ ] 6. 整合所有上下文 + 凭证跨上下文串联 + 领域上下文 → §6 业务模型全景图（8X Flow 骨架全景，按上下文数量选纵向/网格布局）
- [ ] 7. 正常 + ≥1 违约场景 → §7 端到端走查
设计延伸（默认产出，建模完成后）
- [ ] 8. 业务模型 → 领域 / 业务组件 → §8 业务组件设计
- [ ] 9. 组件 → 微服务架构图（§8 组件架构 + 服务边界）+ RESTful 超媒体（补充）→ §9 微服务设计
- [ ] 10. 跨前台复用业务模式 → 从合同上下文提取宏流程 → §10 中台化设计
- [ ] 11. 云化 / SaaS 交付 → 围绕"选项"分档 + 开放式服务 → §11 SaaS 化设计

第一段 · 总：业务全局总览

先建立全局视角，再逐个深入。

找全合同上下文（MECE 闸门）　合同只在两方之间，多方拆成多份双方合同。先列出系统所有合同上下文（§2 清单）：识别每个盈利流的实际收款方 / 付款方——他们就是结算合同的对手方；只撮合不直接收付的是支撑方，不进核心合同（见 ../../reference/concepts.md 的"枢纽参与方 / 平台型业务"）。跑「无合同四场景」前置闸门（见 ../../reference/concepts.md）：逐项确认是真合同、挖出隐藏合同，直到穷尽。

业务全生命周期四阶段　RFP（邀请投标）→ 投标 → 签约（分水岭）→ 履约。确认业务起点：若在签约之前（招标 / 磋商 / 比价），需把渠道上下文纳入总览——它是合同前段，与履约上下文弹性诉求差距大、必须分离（详见 ../../reference/concepts.md）。

第二段 · 分：单上下文五步法（对每个上下文重复一组卡片）

以下五步是单个合同上下文的建模单元，对清单里每个上下文各走一遍，每组产出一张卡片（合同图 + 履约项表 + 凭证图 + 违约图）。

① 找合同上下文，明确参与方　明确该上下文的两个角色，标出对手方结算关系（粗线）/ 仅撮合关系。

② 找主要履约项，按四色找凭证　先按"围绕该合同核心对价 / 收入流的履约项即主要履约项"筛选，穷尽对价两侧（收入流侧 + 成本结构 / KPI 侧，见 ../../reference/concepts.md 的"主要履约项 vs 违约履约项"）。对每项权责明确权利方 / 义务方；履约请求 = 时间段，履约确认 = 时间点。找凭证的最小子步骤（四色法核心）：① 围绕该履约项找现金 / KPI 凭证；② 列关键数据项（时间点 + 金额）；③ 追溯每个关键数据项的来源（前序凭证数值 / 人工输入 / 规则计算，见 ../../reference/concepts.md 的"关键数据项的三类来源"），产出凭证追溯图（凭证链图 + 凭证表，复用 bm-four-color 画法：实线 = 数值 / 时标来源，虚线 = 规则来源）。追溯范围限定主要履约项的核心凭证链；违约履约项凭证在 ③ 的违约流转图节点上标注，不入此图。若需完整全量凭证链，调用 bm-four-color。

③ 找违约情况，设新履约项　对每个主要履约项逐项寻找违约场景（非挑几个）。判别处理方式（见 ../../reference/concepts.md 的"独立履约项 vs 自动作废"）：违约需对方主动作为（退钱、赔付）→ 设独立履约项，可继续递归；违约只是状态翻转（如订单关闭）且无需对方确认 → 自动作废，到此终止。违约责任也需合同预先覆盖。按四色找凭证，违约履约项的凭证在违约流转图节点上标注（不单独追溯，见 ② 边界）。

④ 重复 ③，直到不得不打官司　违约的承担继续违约 → 再触发新履约项 → 最终诉诸法律（终极履约）即为终止条件。

⑤ 标的物归领域上下文　标的物来自领域上下文（领域系统），通过凭证引用参与业务（业务上下文不拥有其生命周期，见 ../../reference/concepts.md 的"标的物的引用形态"）。

示例（专栏订阅合同，参与方：读者 ↔ 极客时间）：主要履约项 = 支付订阅费（权利方极客时间）+ 访问付费内容（权利方读者）。违约：未限时支付 → 合同自动作废（无需独立权责项）；断更 → 退钱 + 重上架免费，若拒不退钱 → 只能打官司（终止）。

第三段 · 总：变化点与弹性边界

全局整合阶段，把所有上下文的凭证引用关系收敛为系统的变化点与弹性边界。

变化点（穷尽两类来源，MECE）　系统的变化点只有两类，识别时两类都查、缺一不可（见 ../../reference/concepts.md 的"系统变化点的两个来源"）。

• 来源①：角色化的履约确认　跨合同上下文的凭证引用 = 上下文间的依赖关系。核心合同依赖支撑合同（如专栏订阅依赖各种支付合同）是坏味道——让核心逻辑依赖支撑逻辑。解法：反转依赖——让履约确认角色化（能力供应商模式），让其他合同中的凭证来扮演它，在核心合同中引入变化点。

  示例：把"专栏付款确认"角色化，由移动支付合同 / 预充值合同等不同合同的凭证来扮演 → 一处变化点支持多种支付方式，核心合同不再逐个依赖新支付合同。

• 来源②：渠道上下文（合同如何生成）　合同经由哪些不同途径生成（招标、直签、拼团、比价磋商…）本身就是变化点——系统第二大变化点。承认它是变化点（而非强制归纳为一种模式），从架构上极大简化系统，也是构造中台的常用技巧（见 ../../reference/concepts.md 的"渠道上下文"）。

弹性边界（按四类天然边界切分）　合同上下文是业务 / 服务边界但 ≠ 弹性边界；弹性边界落在其余三类（四类定义见 ../../reference/concepts.md 的"四类天然边界"）：

• 履约上下文 = 弹性边界（同一合同不同履约项弹性诉求不同，如访问内容比支付容量诉求大）；
• 领域上下文也是弹性边界（领域与业务分离后，各自独立弹性）；
• 渠道上下文与履约上下文弹性诉求差距大，必须作为独立边界分离。

依此切分领域与业务边界，即可应对云时代建模的四挑战（反映弹性边界、切分后维护一致性、异步解读业务、异步异常维护一致性）。映射到服务的启发式：按履约项的容量 / 频次聚类成服务（如高频大容量的"配送履约"独立，低频批处理的"结算履约"独立），而非按合同整体切。

产出（HTML 报告为主，终端摘要）

按 ../../reference/output-format.md（含视角纪律 + MECE 穷尽纪律）+ ../../reference/live-session.md：HTML 报告含完整方案（图/表/判别，live server 实时预览），终端每章只给一两句摘要（不重复完整方案，省 token）。报告按「总-分-总」三段式组织（章节标号 CSS counter 自动；骨架全景层 vs 详细局部层见 ../../reference/output-format.md「报告结构层级」）：

第一段 · 业务全局总览（总 · 摘要级）

1. 业务定位与经营形态：领域系统 vs 业务系统判别 + 经营形态（自营 / 平台枢纽型，枢纽方在哪些合同作对手方）+ 业务全生命周期四阶段（渠道上下文 → 签约 → 履约上下文）。
2. 合同上下文清单：系统所有合同上下文 / 双方参与方 / 对手方结算合同（粗线）/ 仅撮合合同；附「无合同四场景」闸门判别（确认每项是真合同、无隐藏合同遗漏）。

第二段 · 逐合同上下文详细建模（分 · 每个上下文一组卡片）

3. 上下文 N：<名称>（对每个上下文重复一组）：
   • 合同上下文图：两方 + 角色，标出对手方结算合同（粗线）/ 仅撮合。
   • 主要履约项表：每项权利方 / 义务方 + 履约请求（时间段）/ 履约确认（时间点）+ 凭证；穷尽核心对价两侧。
   • 凭证追溯图：该上下文主要履约项的核心凭证链（实线 = 数值 / 时标来源，虚线 = 规则来源）+ 凭证表（计算逻辑 / 时标顺序逻辑）。复用 bm-four-color 画法；完整全量凭证链调 bm-four-color。
   • 违约流转图：对每个主要履约项的违约 → 独立履约项 vs 自动作废判别路径，终止于打官司；违约履约项凭证在节点上标注。

第三段 · 全局整合（总 · 骨架全景）

4. 变化点：穷尽两类——① 角色化履约确认图（哪些履约确认被角色化、由哪些合同凭证扮演）+ 关键变化点表；② 渠道上下文（合同生成的不同途径）。
5. 弹性边界 / 服务图：按四类天然边界切分（合同上下文为服务边界；弹性边界 = 履约上下文 + 领域上下文 + 渠道上下文）→ 服务映射。
6. 业务模型全景图：8X Flow 骨架全景——每个合同上下文画出履约请求(时段)→履约确认(时点) + 权利方/义务方、凭证节点（请求=发起依据、确认=履约证明）、标的物归领域上下文（经凭证引用参与业务）、变化点（角色化履约确认 ◆ + 由哪些合同凭证扮演）、四类边界分区（合同上下文=服务边界；履约/领域/渠道上下文=弹性边界）。凭证关键字段 / 凭证追溯链 / 违约分叉仍在第二段详细层（全景不重复）。按上下文数量选布局：单上下文→纵向型、≥2→网格型。画法（必含元素 + 模板 + 变体）见 ../../reference/html-report.md「业务模型全景图画法」；SVG 合法性纪律见 ../../reference/svg-layout.md「SVG 语法合法性纪律」。落实 ../../reference/output-format.md「骨架全景层」。
7. 端到端走查：正常流程 + 至少 1 个违约场景，验证模型自洽。
8. 业务组件设计：把业务模型过渡到技术设计的结构（领域组件 vs 业务组件），见下文「业务组件设计」。
9. 微服务设计：承接 §8，微服务架构图（§8 组件架构 + 服务边界）为首要产出 + RESTful 分布式超媒体（补充），通过服务实现组件化，见下文「微服务设计」。
10. 中台化设计：从合同上下文提取可跨前台复用的宏流程，成型中台业务模型，见下文「中台化设计」。
11. SaaS 化设计：围绕"选项 = 能力 + 服务质量"分档（魔球三类客户）+ 开放式服务（沙箱），见下文「SaaS 化设计」。

多合同上下文系统：第二段按"每个上下文一组卡片"组织（非按维度横向铺开），保持每个上下文完整可读。章节结构是默认推荐、可按业务增删 / 重排（标号 CSS counter 自动）；看完整效果用 live server 实时生成（见 ../../reference/live-session.md）。

MECE 穷尽自检（产出前必过）

承接开头「底层逻辑原则：结构化（MECE）」——前者是思维底座（互斥 + 穷尽两半），本节是产出前对穷尽这一半的五维度逐项自检（用户未声明忽略的维度不得跳过；纪律详见 ../../reference/output-format.md「穷尽纪律」，判据详见 ../../reference/concepts.md）：

单合同上下文系统也走三段式——第一段清单只列一个上下文、第二段一组卡片、第三段全景图即该合同完整模型（纵向型布局，见 ../../reference/html-report.md「业务模型全景图画法」）；MECE 自检同样必过。

业务组件设计（五步法的延伸产出）

五步法产出合同上下文 / 主要履约项 / 违约流转 / 变化点 / 弹性边界后，进一步把系统划分为「领域组件」与「业务组件」，作为后续技术设计的结构。本节为 8X Flow 的默认产出（建模完成后的设计延伸）；深度按业务需要——简单系统浅作，需过渡到设计 / 实现时深作。

两类组件（呼应「领域逻辑 vs 业务逻辑」）

• 领域组件：运营无关的领域逻辑 / 模型——标的物、领域状态机、主数据。换运营方式也不变。
• 业务组件：运营特定的履约逻辑——履约流程、编排。随运营而变。
• 关键关系：业务组件通过引用领域组件的标的物参与业务；业务组件编排领域组件（领域组件提供“是什么”，业务组件编排“怎么做”）。

划分步骤

1. 识别领域组件：从凭证的标的物、领域状态、主数据中，提取运营无关的领域模型（聚合根、状态机、目录）。
2. 识别业务组件：从主要履约项 / 履约流程，提取业务能力单元。
3. 明确编排关系：每个业务组件编排哪些领域组件、与哪些业务组件协作。
4. 环节独立性判别（见下）：不独立的环节融入相关业务组件。

关键判别：环节独立性（业务语义连续性约束）

并非所有环节都能独立成组件。判别测试：

若某环节独立成组件后，会丢失其业务语义（无法确定业务含义 / 方向），则它必须融入相关业务组件，不能独立。

典型：具有「方向性」或「上下文绑定」的环节。例如追溯场景的「扫码采集」——入库采集与出库采集的码状态翻转方向相反，若把采集抽成独立共享组件，“码被采集”将无从判断是入库还是出库，方向语义丢失。故采集必须融入出入库追溯，不独立成组件。

这是「业务语义优先于物理复用」：两个环节物理相似但业务语义不同，应分属各自业务组件，而非为复用抽象成共享组件。

产出（写入报告「业务组件设计」章节）

1. 领域组件清单（表）：组件 / 领域职责 / 核心领域模型（聚合根、状态机）/ 关键状态与规则。
2. 业务组件清单（表）：组件 / 业务职责（履约流程）/ 编排的领域组件 / 协作的业务组件。
3. 组件架构图（结构关系为主，架构是核心；非流程协作）：
   • 分层结构：业务组件层 + 领域组件层，实线 = 业务组件编排领域组件（依赖 / 结构关系），标注标的物引用与基准引用。
   • 协作有限标注：业务组件间的关键协作用虚线标注（不展开完整时序、不喧宾夺主）；时序图仅在需展示动态调用时按需补，非主体。
   • 产出的是组件的架构 / 结构（划分 + 编排关系），供 §9 微服务架构图（= §8 + 服务边界）与后续技术设计承接。画法见 ../../reference/html-report.md「组件架构图画法」（报告轨）/ ../../reference/terminal-diagrams.md（终端轨）。
4. 组件边界如何帮助设计：领域组件 → 领域模型设计（聚合根、状态机、领域规则）；业务组件 → 履约流程设计（步骤、编排、权责）；一个组件 = 一个设计 / 实现单元。

与五步法的关系

• 弹性边界 ≈ 组件边界候选
• 标的物（来自领域系统）→ 领域组件
• 主要履约项 / 履约流程 → 业务组件
• 变化点 → 可在组件边界引入（业务组件定义端口契约，适配器实现）——但这是技术设计，不在本节展开

原则

• 去技术化：业务组件设计是业务 / 领域设计，不含技术实现（端口 / 接口 / 部署 / 事件机制等留给后续技术设计）。它是技术设计的输入，不是技术设计本身。
• 业务语义优先：组件划分服从业务语义（如方向性约束），不为物理复用破坏语义。
• 组件图遵循 ../../reference/svg-layout.md 布局原则（分区 / 流向 / 走通道 / 先线后点）。

示例（追溯码系统）

• 领域组件：追溯码领域（码状态机：入库核注 / 出库核销、包装层级）、主数据领域（货主 / 商品 / 参与方）。
• 业务组件：入库追溯（含入库采集 + 收货确认）、出库追溯（含出库采集 + 复核确认）、监管合规上报、质量异常管控。
• 环节独立性：采集因方向性约束，融入入库 / 出库追溯，不独立。

微服务设计

业务组件设计产出领域 / 业务组件（业务能力的组件化划分）后，进一步通过服务实现组件化——按业务能力把组件映射为微服务，并用 RESTful 分布式超媒体描述服务生态。本节为 8X Flow 的默认产出（建模完成后的设计延伸）；深度按业务需要。源自第 19 讲"如何将模型实现为微服务？"。

微服务的本质比映射更重要（原文 5000 字仅 500 字讲映射）：先辨清真伪微服务，映射水到渠成。概念提炼见 ../../reference/concepts.md §六。

微服务九特质与三关键点

微服务是架构风格（Lewis & Fowler《微服务》），九特质：通过服务实现组件化、按业务能力划分组织、以产品而非项目研发、逻辑集中编排简单、每服务自主决策（技术栈 / 语言）、自主管理数据、基础设施自动化、将服务失败当常态、演进式设计。

其中三点最关键，理解偏差即落入伪微服务：

另有 分布式单体（Distributed Monolith）：分布的但逻辑仍是单体——改一个服务牵连很多、无法水平扩展；判别：用 RPC 还是 RESTful 设计 API。

微服务核心：把业务能力封装成独立松耦合的服务，构建企业内能力生态系统。万能判别问句："微服务 / 分布式服务 / 分布式单体会怎么做？"三者比较即知。

RESTful + 分布式超媒体（微服务 API 最佳方式）

• Be the web, not behind the web：把企业能力构造成一个 web，用超链接表示服务间关系，而非仅把 web 当对外接口。
• URI 即编排：RESTful 资源 URI 可看作函数调用（GET /users/1/subscriptions ≈ getSubscriptions(getUsers(1))），不同求值策略 = 不同编排策略；URI 从模型而来故稳定（RPC 风格不具备）。
• RESTful 也能异步：HTTP 202 + header URI / 返回结构（破除"RESTful 都同步"误解）。

原文洞见：API 设计合理，微服务只是实现层弹性；API 不合理，微服务玩出花也没用。更应关注"用分布式超媒体表示服务生态"，而非微服务本身。

将 8X Flow 模型映射为微服务

• 以合同上下文 / 领域上下文为 URI 根，模型映射为 RESTful API + 构造分布式超媒体。
• 拆分顺序：先以合同上下文为服务边界；再按需把履约项拆成独立服务（仅当需独立弹性边界时，不必每项都拆）；领域上下文建议一个服务（面向对象设计中弹性边界不易切）。
• 无论怎么拆，只要 RESTful，接口始终稳定。

与业务组件设计的关系

九特质第一条"通过服务实现组件化"：业务组件设计产出领域 / 业务组件（业务能力的逻辑组件化），微服务以业务能力为粒度——业务组件正是微服务划分的输入。两者是"组件化"主题的连续：业务组件设计（逻辑组件）→ 微服务设计（通过服务实现组件化）。

产出（写入报告「微服务设计」章节）

1. 微服务架构图（首要）：把"通过服务实现组件化"可视化成架构——区分两类服务：业务服务（来自合同上下文，承载业务组件 / 履约逻辑）+ 领域服务（来自领域上下文，承载领域组件 / 标的物，独立成一个服务）；业务服务编排领域服务（按业务逻辑，延续 §8"业务组件编排领域组件"的编排语义，非技术调用），领域服务被多个业务服务共享编排。服务节点标真伪微服务色标（真微服务 vs 四种伪模式），业务服务间协作虚线有限标注。承接 §8 组件架构图——§8 业务组件编排领域组件，§9 把它们映射成业务服务 / 领域服务（合成"模型→组件→服务"主线）。画法见 ../../reference/html-report.md「微服务架构图画法」（报告轨）/ ../../reference/terminal-diagrams.md（终端轨）。
2. 服务划分表：服务 / 组件来源（业务组件）/ API（RESTful 资源 URI）/ 伪微服务自检——逐服务明细。与图互补：图给服务架构（结构性），表给逐服务字段（分类）。
3. 真伪微服务自检：三关键点是否满足、是否落入四种伪模式。
4. RESTful / 超媒体（补充·可选）：API 风格 RESTful + 分布式超媒体（URI 编排、异步）。本节聚焦组件化（通过服务实现组件化）；RESTful 超媒体为补充视角，深度按业务需要。

示例（追溯码系统）

承接 §8 业务组件设计的追溯码示例，体现"一脉相承"：

• §8 组件架构：业务组件（入库追溯、出库追溯、监管合规上报、质量异常管控）编排领域组件（追溯码领域、主数据领域）。
• §9 微服务架构（组件映射成两类服务）：
  • 业务服务（合同上下文 / 业务组件）：入库追溯 + 出库追溯 + 监管合规上报 → 追溯服务（/trace）；质量异常管控 → 质量服务（/quality）。
  • 领域服务（领域上下文 / 领域组件，独立）：追溯码领域服务（/trace-code，标的物：码状态机）、主数据领域服务（/master，货主 / 商品 / 参与方）。
  • 编排：追溯服务、质量服务都编排追溯码领域服务 + 主数据领域服务（业务逻辑编排，延续 §8）。
• 真伪自检：按业务能力划分、产品化、逻辑集中 → 真微服务。
• 与 §8 衔接：§8 业务组件编排领域组件，§9 把它们映射成业务服务 / 领域服务，编排关系延续到服务层。

原则

• 去技术化：本节聚焦服务划分原则与 API 风格；基础设施自动化、容器 / K8s、服务网格等实现留给技术设计。
• 定义问题优先：先辨清真微服务（多数问题源于没定义清），映射自然简单。

中台化设计

五步法产出完整业务模型后，若存在可跨前台复用的业务模式，进一步从合同上下文提取宏流程，成型中台业务模型。本节为 8X Flow 的默认产出（建模完成后的设计延伸）；深度按业务需要——单业务系统浅作（识别可复用模式即可），多前台 / 中台目标深作。源自 17 / 18 讲"如何使用 8X Flow 建模中台系统"。

先建立概念（详见 ../../reference/concepts.md §六）：中台是支撑多个小而灵活的前台团队的软件平台——"前台"指团队（按城市 / 品类划分的独立运营单元），不是软件。

中台的定位：在"业务模式"上平衡效能与自主

中台区别于普通平台 / 中间件的关键，在于它把软件平台"效能下限 vs 创新上限"的平衡点放在特定场景的业务模式上：

• 平台能力（效能下限）vs 应用自主度（创新上限）：平台能力越丰富，前台开发成本越低，但会限制前台实现方式、压缩自主度与创新。操作系统 / 中间件走高自主度；数据库 / 搜索引擎 / 低代码 SaaS 走高效能。中台取中——用"模式复用"提效，又不锁死流程、保留前台自主。
• 中台 ≈ BaaS（后端即服务）：只有后端部分，不新增前端入口（新前台团队不产生新 App，而是在主 App 增功能）。中台是"产生 SaaS 的 SaaS"——不直接服务租户，而是产出针对某业态的后台 SaaS；宏流程实例化即 SaaS 化。

宏流程 = 可复用的业务模式

• 业务上 = 宏观流程：把多个类似业务模式的前台抽象后，提炼出的共有底层"核心业务模式"（如交易中台的交易模型、出行中台的"撮合 + 履约"模型）。
• 技术上 = 业务流程的模板：不能被前台直接使用，靠配置点 + 扩展点在不同前台实例化成具体业务流程。
• 业务模式 = 一组决策模式的集合：抽象要恰如其分——泛化不够则退化为具体功能，过度则丧失对业务决策的指导意义（如把出行抽象成泛泛撮合，就无法支撑"哪辆车更匹配"的决策）。故宏流程从已存在的业务模型提取，而非直接建模（直接建模极易过度抽象；抽取 / 重构这类后置行为几乎总是更优）。

设计步骤：从合同上下文提取并配置（18 讲）

1. 从已产出的 8X Flow 业务模型出发（不直接建模）。
2. 确定要跨场景复用的业务模式，定位承载它的合同上下文——合同流程是业务流程的模板（合同流程是因、业务流程是果），故合同上下文是宏流程的最佳候选（同一履约项可映射不同业务流程，如支付：先坐后付 vs 一口价预付）。
3. 将履约确认项角色化，引入变化点——只可角色化履约确认，不可角色化履约请求（后者破坏权责语义，18 讲思考题）。
4. 变化点的扮演可来自其他合同上下文，也可来自领域系统：把运力、撮合算法等建模为领域系统，去扮演合同中的角色（如承运人、撮合引擎）。
5. 不同前台场景扩展 / 替换变化点：同一合同流程 + 不同领域系统配置 = 不同业务流程（出行合同 + 网约车 / 出租车 / 共享单车领域系统）→ 模式复用 → 中台雏形。
6. 各上下文继续 8X Flow 建模，直到能解释清楚不同前台如何扩展宏流程 → 得到中台业务模型。

领域系统 vs 业务系统（何时分离）

希望复用业务模式 → 把业务部分与领域部分分离、对业务部分做合同建模；暂时不关心复用 → 当作领域系统（功能角度）。可随时从领域系统中分析并分离其背后的运营模式——问题只是有没有必要。

产出（写入报告「中台化设计」章节）

1. 中台定位：服务哪些前台团队、效能 / 自主的平衡点为何落在"业务模式"。
2. 宏流程图：提取的合同上下文 + 角色化变化点 + 领域系统扮演 + 多前台场景的实例化（同一宏流程展开成不同业务流程）。
3. 中台业务模型：宏流程 + 各变化点的配置点 / 扩展点实例化方式。
4. 判定依据：为何选该合同上下文作宏流程、哪些履约确认项被角色化、领域系统扮演关系、为何不能角色化履约请求项。

原则

• 后置：先有完整业务模型，再提取宏流程；不在五步法中途扯中台。
• 防过度抽象：从已存在模型提取是主要手段；模型要保有对业务决策的指导意义。
• 去技术化：本节是业务 / 领域设计，配置点 / 扩展点的技术落地（微服务、SaaS 化架构）留给后续技术设计。
• 图遵循 ../../reference/svg-layout.md。

与业务组件设计的区别

• 业务组件设计：把一个业务系统拆成领域 / 业务组件（单系统内部结构）。
• 中台化设计：把多个业务的共性模式提取成可复用宏流程（跨业务 / 跨团队复用）。
• 两者并列：内部结构 → 业务组件设计；跨前台复用 → 中台化设计。

SaaS 化设计

业务模型（及中台宏流程）成型后，若目标是云化交付 / SaaS 化服务，进一步围绕"选项"设计服务分档与开放式交付。本节为 8X Flow 的默认产出（建模完成后的设计延伸）；深度按业务需要——纯业务建模只识别"是否需要 SaaS 化"+ 一句结论，云化 / SaaS 交付目标才深作。源自第 20 讲"SaaS 化与魔球建模法"。

先建立概念（详见 ../../reference/concepts.md §六、../../reference/methods.md §8）：微服务、云化殊途同归，下一站都是 SaaS 化——它成为云时代默认的运营与架构风格。原文自承 SaaS 化与业务建模"勉强沾边"，故本节是建模后的下游设计延伸，其"建模"成分即魔球选项建模。

为什么 SaaS 化：从开放式服务到沙箱

微服务要兑现"编排已有服务即可创新"的承诺，前提是做成开放式服务——面向生态中所有可能的客户端（不止当前应用）、所有环境（不止生产，还支持围绕它试验创新而不影响生产）。

• 完全开放式服务：生态中唯一开放实例，适合只读 / 无业务痕迹的服务（产品目录、员工信息）。
• SaaS 化开放式服务：适合会留业务痕迹的业务系统——试验流量不能污染生产。SaaS 化的是沙箱环境（Sandbox）：非生产请求获得独立、与生产隔离的专有环境，用于实验、上线前验证（比契约打桩更接近生产）。
• 冷 SaaS：服务团队不提供沙箱基础设施，只给镜像和脚本，由使用方自建（IaC）。

围绕"选项"而非"服务"设计

简单云化（弹性边界 + 按流量加实例）假设所有用户服务质量需求相同 = 昂贵的云化（只有超大杯、只有次日达）。不同用户对服务质量（可用性只是其一）诉求不同：

• 选项（Offering）= 能力（Capabilities）+ 服务质量（SLA / NFR）。相同镜像 + 不同组网 = 不同选项（能力同、服务质量异），按消费者诉求分派流量降成本。
• 例：快递能力相同（A→B），按服务质量分当日达 / 次日达 / 标快 / 特惠，对应不同运力（成本）与组网。
• 关键：SaaS 化成败在于正确设计选项（在不同组网放什么镜像、实现哪些服务质量），而非组网 / 镜像技术本身。

魔球 SaaS 选项建模法：三类客户 / 选项

任意 SaaS 化服务需三类选项应对三类客户（灵感来自篮球魔球——三分价值高、上篮把握大、中距离尴尬，尽量出手转化为三分或上篮、避免中距离）：

存量系统变革：把现有系统 + 现有服务质量建模成**遗留选项（Legacy Offering）**放尴尬 Tier 2 → 暂时 100% 用户皆尴尬 → 分化出高价值 / 现金奶牛，用新选项覆盖。

产出（写入报告「SaaS 化设计」章节）

1. 选项分档表：选项名 / 能力 / 服务质量（SLA/NFR）/ 组网策略（dedicated vs shared）/ 目标客户群。
2. 客户分类：三类客户划分依据与占比（或存量变革下的遗留选项定位）。
3. 开放式服务策略：完全开放 vs SaaS 化沙箱（是否需沙箱 / 冷 SaaS）。
4. 判定依据：为何如此分档、哪些差异化诉求驱动了选项划分。

原则

• 去技术化：本节聚焦选项设计（能力 + 服务质量分档）；组网、镜像、K8s 实现留给技术设计。
• 后置：先有业务模型 / 服务，再 SaaS 化。
• 与其他设计延伸的关系：业务组件（单系统内部结构）→ 微服务（按业务能力划分服务）→ 中台化（跨前台复用模式，宏流程实例化即 SaaS 化）→ SaaS 化设计（服务交付的选项分档 + 开放式服务）。SaaS 化是中台化的下游运营形态，也可独立用于任意云化 / 微服务。

参考资料

• 运行方式（增量引导 + live server）：../../reference/live-session.md
• 产出规范（双轨）：../../reference/output-format.md
• SVG 图布局（分区 / 走通道 / 先线后点 / 连线公式 / 复杂度预算 / 自检清单）：../../reference/svg-layout.md
• SVG 校验闸门（写完 / 改完报告必跑，退出码 0 才算通过）：python <插件目录>/scripts/check-svg.py 报告.html --strict
• 概念定义（合同 / 权责履约 / 履约请求 / 履约确认 / 凭证 / 标的物 / 变化点 / 弹性边界 / 渠道上下文）：../../reference/concepts.md
• 方法选择（8X Flow vs 四色 vs 魔球 SaaS 等）：../../reference/methods.md
• 原文：
  • 第 14 讲（领域 vs 业务）：../../source/04-新约：云时代的业务建模(2讲)/14丨8XFlow（上）：何为业务？何为领域？.md
  • 第 15 讲（五步法 + 变化点）：../../source/04-新约：云时代的业务建模(2讲)/15｜8XFlow（中）：如何通过模型发现业务系统的变化点？.md
  • 第 16 讲（渠道上下文 + 无合同场景）：../../source/04-新约：云时代的业务建模(2讲)/16丨8XFlow（下）：多于一个例子.md