规划应用结构与业务蓝图

本章目标：把业务分析结果组织成一张完整应用蓝图，明确应用中需要哪些模板、视图、流程、角色和自动化能力。

1. 先设计蓝图，再进入配置

业务分析回答“业务怎样运行”，应用蓝图回答“Kimpo 应用怎样承载它”。

蓝图不是界面截图，也不是字段清单。它应能让参与者看懂：

• 应用服务哪一段业务；
• 用户从哪里进入；
• 需要管理哪些业务对象；
• 每类角色使用哪些功能；
• 数据、规则、流程和权限如何配合；
• 第一版和后续版本的边界。

没有蓝图就直接开发，最常见的结果是资源随需求出现而不断增加，最终目录、命名、权限和流程彼此脱节。

2. 认识 Kimpo 中业务开发者会用到的构建对象

构建对象	业务意义	采购案例
应用	一项相对独立业务的治理和使用边界	办公采购管理
目录	按用户工作方式组织入口	采购申请、采购执行、统计
模板	一类业务记录的填写和查看载体	采购申请
视图	按某种业务目的查看一批记录	我的申请、待采购
动作	在特定时机自动计算、校验或处理	计算总额、检查明细
流程	需要多人依次作出决定的协作路线	采购审批
角色与权限	决定谁能使用什么、看到什么	申请人、主管、行政
输出	面向归档、外部传递或现场使用	采购申请打印件

具体操作分别参见现有的应用管理、模板设计、动作设计、流程设计和权限教程。

3. 判断应用边界

不是每个业务对象都需要独立应用，也不应把整个企业所有业务塞进一个应用。

可以从五个方面判断：

3.1 使用人群

参与者是否大体相同？办公采购和生产采购可能有完全不同的人员与制度。

3.2 业务目标

是否服务同一组目标？采购申请与客户售后没有共同的业务闭环。

3.3 数据和流程关联

对象是否频繁共同使用、互相引用？采购申请和采购明细天然属于一起。

3.4 权限和治理

是否由同一团队维护，使用相近权限规则？高度敏感、独立治理的业务可能适合分开。

3.5 发布节奏

是否经常一起变化？如果两个模块由不同团队维护、发布时间完全不同，过度捆绑会增加影响。

采购案例第一版只覆盖“办公用品申请到采购完成”，不包含生产物料、合同、付款和库存，因此一个小型独立应用即可。

4. 从业务对象决定模板

每个独立管理、需要创建和查询的核心业务对象，通常对应一个主要模板。

采购第一版：

业务对象	是否独立模板	原因
采购申请	是	独立创建、审批、查询、统计
采购明细	否，作为申请内的多行明细	永远从属于某项申请
物品目录	第一版否	暂时没有独立维护和统一编码要求
审批任务	不作为业务模板	由流程协作呈现

不要按照角色创建重复模板，例如“员工采购申请”“主管采购申请”“行政采购申请”。它们是同一类业务记录在不同角色和阶段下的使用方式，通常应通过权限、状态和视图区分。

5. 按用户任务组织目录

目录结构应该帮助用户找到要做的工作，而不是展示系统内部分类。

采购案例可以设计为：

办公采购管理
├─ 采购申请
│  ├─ 新建采购申请
│  └─ 我的申请
├─ 采购执行
│  ├─ 待采购
│  └─ 全部采购申请
├─ 数据分析
│  └─ 采购统计
└─ 应用管理
   ├─ 模板设计
   ├─ 流程设计
   └─ 角色与权限

普通用户只看到与自己职责有关的入口；管理和设计入口只对相应角色显示。

命名原则

• 使用业务人员日常使用的词；
• 入口名称尽量表达动作或目的；
• 不使用“表 1”“新页面”“测试流程”等临时名称；
• 同一词在模板、流程、视图中保持一致；
• 状态和动作不要同名造成混淆。

6. 设计角色的使用旅程

对每个角色写一条“进入应用后怎样完成工作”的路线。

申请人

进入应用 → 新建采购申请 → 保存或提交 → 在“我的申请”查看状态 → 处理退回 → 查看最终结果。

直属主管

从任务入口看到待审批 → 打开申请并查看用途、明细、金额 → 同意或退回 → 在部门视图查看进度。

行政采购员

从“待采购”查看已批准申请 → 登记采购过程和结果 → 标记完成 → 处理缺货或作废情况。

如果一个角色的旅程需要跨越许多不相关入口，或者不知道下一步去哪里，应用结构还需要调整。

7. 建立能力落点表

把需求追踪到应用设计：

需求编号	业务需求	设计落点	还需确认
R-01	员工提交采购申请	采购申请模板	无
R-02	自动计算总额	明细计算与汇总动作	小数规则
R-03	高金额增加审批	采购审批流程分支	金额边界
R-04	申请人查看进度	我的申请视图	显示当前处理人否
R-05	主管查看部门数据	部门申请视图和数据权限	部门范围口径

每个必须需求都应有明确设计落点。没有落点就是遗漏；一个需求出现多个互相冲突的落点则需要决策。

8. 记录依赖和能力差距

蓝图设计不能假设所有想法都已经可用。

对每项关键设计确认：

• 当前 Kimpo 功能是否支持；
• 是否需要实例管理者先准备人员、组织或服务；
• 是否依赖其他应用或基础资料；
• 如果暂时不能实现，业务上如何替代；
• 替代方案是否会改变权限、数据质量或验收标准。

不要悄悄把“人员选择”退化成自由填写姓名，也不要把“严格唯一”退化成提醒文案。能力不足必须显式记录并由业务负责人决定是否接受。

9. 第一版应用蓝图

采购案例蓝图摘要：

区域	第一版设计
应用	办公采购管理
核心模板	采购申请
主信息	编号、申请日期、用途、总金额、状态
多行明细	物品、规格、数量、预计单价、行金额
自动动作	行金额、总额、提交前检查
流程	主管审批；大于 5000 元增加负责人审批
角色	申请人、直属主管、行政采购员、行政负责人、应用管理员
视图	我的申请、部门申请、待采购、采购统计
通知	提交、退回、批准、采购完成
暂不做	供应商、合同、付款、库存

10. 蓝图应保留的设计记录

不要只保存最后结果，还应保留：

• 为什么把对象合并或拆分；
• 为什么选择某条流程；
• 哪些需求暂不做；
• 哪些业务规则仍待确认；
• 哪些设计依赖当前能力；
• 谁在什么时候确认了关键决定。

这些记录能避免数周后反复讨论已经作出的决定。

11. 常见错误

• 一个角色建一套重复模板；
• 按功能组件组织目录，而不是按用户任务；
• 模板、视图和流程使用不同业务词；
• 蓝图只列页面，不列规则、权限和异常；
• 把未来所有想法放进第一版；
• 对能力差距采用无声降级；
• 没有把需求编号追踪到设计落点。

12. 本章完成标准

• [ ] 应用边界和第一版范围清楚；
• [ ] 每个核心业务对象都有合理承载方式；
• [ ] 目录按用户工作任务组织；
• [ ] 每个主要角色都有完整使用旅程；
• [ ] 所有必须需求都有设计落点；
• [ ] 能力差距和外部依赖已记录；
• [ ] 蓝图包含数据、表单、动作、流程、权限、视图和输出。

下一步

蓝图确定整体结构后，开始详细设计应用中的业务信息。下一章学习设计数据模型与数据字典。