microwind 四色建模法 (Four-Color Modeling)
概述
四色建模法是一种强分析式的领域建模方法，由 Peter Coad 的彩色建模法 (Color Modeling) 演化而来，后由 Thoughtworks 中国区 CTO 徐昊在 2005 年前后结合事件建模完成当前形态。
核心思想：业务模式在企业生命周期内是相对稳定的，而业务模式主要通过收入流和成本结构体现。四色建模法正是从这两个稳定源头出发，推导出整个业务的凭证链（即领域事件流），进而得到领域模型。
与事件风暴的最大差异：
- 事件风暴：发散 - 收敛，依赖主持人经验
- 四色建模：强分析，沿着"现金 / KPI → 凭证 → 前序 / 后续凭证"链式推导
四种原型与颜色
四色建模的"四色"对应四种业务原型对象：
| 颜色 | 原型 | 含义 |
|---|---|---|
| 粉色 | Moment-Interval（时刻 - 时段 / 凭证） | 某个时刻或时段发生的重要业务事件，必须可留痕，如订单、支付单、佣金单 |
| 黄色 | Role（角色） | 参与凭证的抽象角色，如"买方"、"卖方"、"作者"、"读者" |
| 绿色 | Party / Place / Thing（参与方 / 地点 / 标的物） | 扮演角色的具体实体，如具体的用户、具体的专栏 |
| 蓝色 | Description（描述） | 对黄色/绿色的补充说明，如合同条款、专栏分类 |
[蓝 描述] [蓝 描述]
▲ ▲
│ │
[绿 参与方] ─扮演─▶ [黄 角色] ─参与─▶ [粉 凭证/时刻-时段]
│
└─关键数据项─▶ 下一个凭证
四色建模的核心三逻辑
寻找领域事件时依赖三个源自企业经营的稳定逻辑：
1. 现金收入 → 承担义务
▸ "拿钱办事"，需要凭证证明义务履约成功
▸ 收入端：报价 → 订单 → 支付 → 履约凭证
2. 现金支出 → 拥有权利
▸ "花钱消灾"，需要凭证检查对方履约
▸ 成本端：合同 → 应付单 → 支付 → 验收凭证
3. 无现金往来 → 目标 vs 实际对比
▸ 设立 KPI 目标 → 追踪执行实际 → 产生验收凭证
▸ 如：内容审核量目标 vs 实际审核量
凭证必须满足：
- 围绕现金往来或关键 KPI
- 之间通过关键数据项明确关联
- 不是"拍脑袋"的软约定
四色建模八步操作
Step 1 寻找关键现金往来，构造凭证，列关键数据项（时间、金额…）
Step 2 对每个关键数据项，追问来源：用户输入？前序凭证？算法计算？
Step 3 思考凭证对应的权利与责任，推导后续凭证
Step 4 所有凭证都必须罗列关键数据项，保证获取顺畅
Step 5 无现金往来的，改用 KPI 验收凭证，流程同上
Step 6 获得凭证链（事件流）后，围绕每个凭证寻找角色（Role）
Step 7 思考哪些参与方（Party）可以扮演这些角色，加入模型
Step 8 通过描述对象（Description）为模型补充说明
实战示例：RabbitAdvisors 专栏订阅
Step 1-4：围绕"读者购买专栏"推导凭证链
找到核心现金往来：Payment（读者付费）
[Payment 支付单]
关键数据项：
- 支付时间
- 金额 (amount) ← 不是读者输入的，从何而来？
向前追溯金额来源：
[ColumnQuote 专栏报价] ──订单引用──▶ [Order 订单] ──支付对应──▶ [Payment 支付单]
▲ 由编辑输入 ▲ ▲
- 报价金额 - 订单金额 = 报价金额 - 支付金额 = 订单金额
- 报价时间 - 下单时间 - 支付时间
向后推导权责履约凭证：读者付了钱，获得的权利是"阅读该专栏"，需要凭证证明：
[Payment 支付单] ──权利产生──▶ [Subscription 订阅凭证]
▲
- 开始时间 (start_time) ≥ 支付完成时间
- 订阅期
另一条链：作者分成（Commission Payment）
[ContributorContract 撰写合同]
- 分成比例 (percentage) ← 签约时约定
- 账期日 (payment days)
- 签约日
│
▼
[Commission 佣金单]
- 账期 (period)
- 分成金额 = Σ账期内 Payment 金额 × percentage
- 上次分成付款日 (last paid) ← 计算得出（之前 CommissionPayment 的最晚时间，或合同签约日）
│
▼
[CommissionPayment 佣金支付单]
- 分成支付时间
- 分成金额
至此，从作者签约 → 专栏定价 → 读者下单 → 读者付款 → 读者订阅 → 作者分成计算 → 作者分成支付，形成一条完全由关键数据项相连的凭证链——这就是业务的脊梁 (Backbone of the business)。
Step 6-8：补全角色、参与方、描述
[Reader 读者(Party)] ─扮演─▶ [Buyer 买家(Role)] ─参与─▶ [Payment (凭证)]
[Author 作者(Party)] ─扮演─▶ [Payee 收款方(Role)] ─参与─▶ [CommissionPayment]
[Editor 编辑(Party)] ─扮演─▶ [Quoter 定价方(Role)] ─参与─▶ [ColumnQuote]
[Column 专栏(Thing)] ←── 标的物
[Category 分类(Desc)] ←── 对 Column 的描述
验证业务脊梁
领域模型得出后，不要急着开始编码，而是：
1. 将所有凭证转化为真实的业务单据（纸质 / 低保真表单）
2. 邀请业务方参与"角色扮演游戏"，让业务方模拟真实经营
3. 重点模拟异常场景：
▸ 读者不满意要退款
▸ 作者对分成金额质疑，需要追溯
▸ 专栏定价修改了，已下单未支付怎么办
4. 确认业务脊梁捕捉的数据足以证明权责 → 如果不行，回到 Step 1 迭代
这是四色建模区别于其他方法的关键：它不仅为软件服务，更是支撑业务运营的工具，因此天然更容易被业务方采纳为统一语言。
适用场景与局限
适合：
- 有明确收入流 / KPI 的 B 端业务、SaaS、金融、电商平台
- 公司级、全业务域的顶层建模（CTO / 首席架构师视角）
- 业务相对稳定、有长期演进需求的系统
不适合：
- 无明显现金流且无清晰 KPI 的子域（如日志、工具类通用域）
- 纯 C 端内容消费、社交类产品的早期探索阶段
- 需要快速 MVP 验证的场景
实用建议：即使不完整应用四色建模，也可借鉴其**"权责追溯、关键数据项串联、从稳定处出发"**的思想指导日常建模。
与事件风暴的对比
| 维度 | 事件风暴 | 四色建模法 |
|---|---|---|
| 驱动方式 | 发散 - 收敛工作坊 | 强分析，链式推导 |
| 事件来源 | 头脑风暴 | 从现金流 / KPI 推导 |
| 人员 | 多角色集体 | 架构师主导，少量业务参与 |
| 产出稳定性 | 依赖主持人 | 逻辑严谨，可复现 |
| 学习曲线 | 低 | 较高，需理解业务经营 |
| 适用阶段 | 业务不明朗、需共识 | 业务稳定、需长期建模 |
最佳实践：二者可结合使用 —— 先用事件风暴达成业务共识，再用四色建模法做严谨收敛。
与其他 DDD 概念的关系
| 概念 | 关系 |
|---|---|
| 领域建模（即上位概念） | 四色建模是领域建模的一种落地方法 |
| 领域事件 | 凭证链直接对应领域事件流 |
| 聚合 | 凭证通常就是聚合根，关键数据项决定聚合边界 |
| 值对象 | 描述（蓝色）和关键数据项常以值对象形式存在 |
| 通用语言 | 凭证名、角色名、参与方名直接成为统一语言 |
总结
核心：从企业相对稳定的收入流 / KPI 出发，通过凭证链推导事件流，得到稳定的领域模型。
实践：找现金往来 → 列关键数据项 → 追溯前序凭证 → 推导后续履约凭证 → 补角色和参与方 → 业务角色扮演验证。
精髓：建模的是业务经营本身，而不仅是软件结构。这让业务方更容易接受模型作为统一语言。