# 四色建模法

> Skill

- Skill: `microwind/skill-100` (Agent Skill)
- Install (CLI): `npx skillmds@latest add microwind/skill-100`
- Raw SKILL.md: https://api.skillmd.com/api/skills/microwind/skill-100/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: microwind (https://skillmd.com/u/microwind)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/microwind/skill-100

---


# 四色建模法 (Four-Color Modeling)

## 概述

四色建模法是一种**强分析式的领域建模方法**，由 Peter Coad 的彩色建模法 (Color Modeling) 演化而来，后由 Thoughtworks 中国区 CTO 徐昊在 2005 年前后结合事件建模完成当前形态。

**核心思想**：业务模式在企业生命周期内是**相对稳定**的，而业务模式主要通过**收入流**和**成本结构**体现。四色建模法正是从这两个稳定源头出发，推导出整个业务的凭证链（即领域事件流），进而得到领域模型。

**与[事件风暴](../event-storming/)的最大差异**：

- 事件风暴：发散 - 收敛，依赖主持人经验
- 四色建模：强分析，沿着"现金 / 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 验证的场景

**实用建议**：即使不完整应用四色建模，也可借鉴其**"权责追溯、关键数据项串联、从稳定处出发"**的思想指导日常建模。

## 与[事件风暴](../event-storming/)的对比

| 维度 | 事件风暴 | 四色建模法 |
|------|----------|-----------|
| 驱动方式 | 发散 - 收敛工作坊 | 强分析，链式推导 |
| 事件来源 | 头脑风暴 | 从现金流 / KPI 推导 |
| 人员 | 多角色集体 | 架构师主导，少量业务参与 |
| 产出稳定性 | 依赖主持人 | 逻辑严谨，可复现 |
| 学习曲线 | 低 | 较高，需理解业务经营 |
| 适用阶段 | 业务不明朗、需共识 | 业务稳定、需长期建模 |

**最佳实践**：二者可结合使用 —— 先用事件风暴达成业务共识，再用四色建模法做严谨收敛。

## 与其他 DDD 概念的关系

| 概念 | 关系 |
|------|------|
| [领域建模](../domain-modeling/)（即上位概念） | 四色建模是领域建模的一种落地方法 |
| [领域事件](../domain-events/) | 凭证链直接对应领域事件流 |
| [聚合](../aggregate/) | 凭证通常就是聚合根，关键数据项决定聚合边界 |
| [值对象](../value-object/) | 描述（蓝色）和关键数据项常以值对象形式存在 |
| [通用语言](../ubiquitous-language/) | 凭证名、角色名、参与方名直接成为统一语言 |

## 总结

**核心**：从企业相对稳定的收入流 / KPI 出发，通过凭证链推导事件流，得到稳定的领域模型。

**实践**：找现金往来 → 列关键数据项 → 追溯前序凭证 → 推导后续履约凭证 → 补角色和参与方 → 业务角色扮演验证。

**精髓**：**建模的是业务经营本身**，而不仅是软件结构。这让业务方更容易接受模型作为统一语言。