沉淀自超兔一体云 2B 复杂服务合约管理模块的开发现场。前半套是系统分析方法——把一团业务叙述，映射成一份层级分明的数据结构；后半套是单源分片渲染——一份全量数据，多模块按需分片，前端只做渲染不存业务逻辑。

1. 背景：一份 2B 服务合约有多复杂

• 前一半是系统分析：怎么把一团业务叙述，映射成一份讲得清楚、层级分明的数据结构；

• 后一半是渲染模式：怎么让这一份 JSON 数据，驱动整页 15 个区块，区块之间互不打架。

2. 系统分析方法：业务 → 数据的四步映射

面对复杂业务，常犯的错是拿到需求就开始建表、写接口。这套方法的第一步恰恰相反： 先做分拣，再做设计。整个过程四步：捞名词 → 分主线辅线 → 切原子派生 → 区块对分片。这四步合起来，就是一套从业务到数据的映射方案——不止服务合约能用，任何复杂 2B 业务对象都能套。下面逐步拆开。

2.1 第一步：盘点业务对象，把名词全部捞出来

2.2 第二步：分拣主线与辅线——"删掉它，交付断吗？"

• 断的，是主线对象：合约 → 服务产品 → 期次 → WBS 任务 → 执行记录。这五层串起来就是"客户买的服务怎么一步步交付出去"，抽掉任何一层，交付就讲不清。
• 不断的，是辅线对象：应收/回款/费用描述这场交付的 钱，激励描述 人，里程碑/日历描述 时间。它们不从属于交付链条，而是从钱、人、时间三个维度观察同一场交付。

5 层模型不是设计出来的，是分拣出来的。

2.3 第三步：切分原子数据与派生数据——"存"还是"算"

• 回款单是一笔真实发生的钱 → 原子数据，存储；
• 回款率 = 回款 ÷ 合约金额，是两个事实的比值 → 派生数据，用时计算。

凡是能从既有事实算出来的数字，一律不存。存下来的派生值等于制造第二份真相，两份真相早晚打架。

2.4 第四步：界面区块 ↔ 数据分片，一一映射

2.5 方法小结：四步一张表，带走就能用

• 单一真相：全页只认一份单源数据，区块不私拉接口；
• 派生不落库：能从既有事实算出来的，一律不存——存下来的派生值就是第二份真相，两份真相早晚打架；
• 分片互不引用：分片之间不传数据，要联动就各自回单源重算。

3. 核心思想

一份全量数据，多模块按需分片，前端只做渲染不存业务逻辑。

┌─────────────────┐  GET /api/contract/:id/full
│   后端接口       │ ─────────────────────────────────┐
│ (聚合 5 层模型)  │                                  ▼
└─────────────────┘  ┌──────────────────────────────────────┐
                    │  contract.full.json  (单源数据全集)  │
                    └──────────────────────────────────────┘
                              │         │         │
                  ┌───────────┘         │         └───────────┐
                  ▼                     ▼                     ▼
         ┌───────────────┐    ┌────────────────┐    ┌────────────────┐
         │  Slices (分片) │    │  Slices        │    │  Slices        │
         │  hero / info  │    │  products[]    │    │  calendar[]    │
         │  kpi / action │    │  wbs[]         │    │  ar / rc[]     │
         └───────────────┘    │  periods[]     │    │  incentive[]   │
                              └────────────────┘    └────────────────┘
                                       │                     │
                                       ▼                     ▼
                              ┌─────────────────────────────────────┐
                              │     DOM (按分片渲染 / 局部刷新)     │
                              └─────────────────────────────────────┘

4. 数据层

4.1 主结构（5 层模型）

{
  "contract": { /* 第 1 层：合约主体 */
    "id": "C-2026-001",
    "title": "上海×××公司 2026 服务合约",
    "customer": { "name": "...", "industry": "..." },
    "period": { "start": "2026-01-01", "end": "2026-12-31" },
    "amount": 48000,
    "status": "active"
  },
  "products": [ /* 第 2 层：服务产品 */
    { "id": "p1", "name": "月度代账服务", "periods": 12, ... }
  ],
  "periods": [ /* 第 3 层：期次 */
    { "id": "p1-1", "productId": "p1", "seq": 1, "status": "done", ... }
  ],
  "wbsTasks": [ /* 第 4 层：WBS 任务 */
    { "id": "w1", "periodId": "p1-1", "name": "收集票 据", "status": "done", ... }
  ],
  "execRecords": [ /* 第 5 层：执行记录 */
    { "id": "e1", "wbsId": "w1", "date": "2026-01-03", "content": "..." }
  ],
  "receivables": [ /* 应收 */ ],
  "collections": [ /* 回款 */ ],
  "expenses": [ /* 执行费用 */ ],
  "incentives": [ /* 激励 */ ],
  "milestones": [ /* 关键里程碑 */ ],
  "calendarEvents": [ /* 日历事件 */ ]
}

4.2 分片映射（slice map）

4.3 派生（derived）数据

• kpi：合约总额、回款率、未回款金额、活跃期次等
• action：Top3 待办（按优先级+截止日期排序）
• matrix：每期交付/回款配对（关联 receivables + periods）
• team-bar：按人员聚合 incentives
• calendar.summary：本月计划/交付/应收/实收

后端只提供"原子数据 + 业务规则"，前端只做"分片 + 派生 + 渲染"。

5. 渲染层

5.1 模板占位

<!-- 容器标记 -->
<div class="hero-card" data-slice="header">
  <div class="contract-title" data-bind="contract.title"></div>
  <div class="contract-id" data-bind="contract.id"></div>
</div>
<!-- 列表标记（使用 template 元素） -->
<template data-slice="products" data-list="products">
  <div class="product-card">
    <div class="product-name" data-bind="name"></div>
    <div class="product-amount" data-bind="amountText"></div>
  </div>
</template>

5.2 绑定语法

5.3 派生计算器

const derived = {
  kpi: (data) => ({
    totalAmount: data.contract.amount,
    collectedRate: data.collections.reduce(...) / data.contract.amount
  }),
  matrix: (data) => periods.map(p => ({
    period: p.seq,
    delivery: ...,
    collection: ...
  }))
};

6. 加载流程

7. 与传统方式的对比

8. 落地步骤

1. 盘点业务对象 — 捞名词、分主线辅线（见第 2 节）
2. 设计主结构 — 按 5 层模型 + 辅线集合组织单源 JSON
3. 切分原子与派生 — 有事实来源的落库，算得出的写进 derived.js
4. 标注 DOM — 在 HTML 中加 data-slice / data-bind
5. 实现渲染器 — 编写 render.js（约 100-200 行）
6. 配置降级 — apiUrl 与 demoUrl 切换
7. 验证 — 保证 JSON 切换后页面 1:1 还原

9. 复用价值与结语

• 新增产品/合约：复制 JSON 模板，替换数据，DOM 0 改动
• 改业务字段：JSON 加字段 + DOM 加 data-bind 即可
• 跨页面复用：相同 JSON 喂给"列表页/详情页/时间线页"
• 跨业务复用：四步映射法换个业务对象照走一遍——项目详情、工单详情、采购单详情，路数一样
• 离线 Demo：纯前端可演示完整业务流程