设计视图、输出、通知与外部协作
本章目标：让数据在正确时间以正确方式到达正确的人，并为查询、导出、打印、提醒和外部数据交换定义清楚的业务规则。
1. 表单和视图解决不同问题
- 表单围绕一条业务记录，帮助用户填写、处理和查看详情；
- 视图围绕一批业务记录，帮助用户查找、比较、筛选和管理。
不要让用户每天逐张打开表单寻找待办，也不要把一张复杂详情表单压缩成几十列的万能列表。
视图具体配置参见视图设计器。
2. 从角色任务设计视图
每个视图定义：
- 谁使用；
- 要完成什么任务；
- 默认看到哪些记录；
- 最重要的列；
- 默认排序；
- 常用筛选；
- 能执行哪些操作；
- 是否允许导出。
我的申请
- 使用者：申请人；
- 任务：找到草稿、退回和进行中的申请；
- 默认范围：本人；
- 关键列：编号、用途、总金额、状态、提交时间；
- 默认排序：最近更新在前；
- 快捷筛选：草稿、已退回、审批中、已完成。
待采购
- 使用者：行政采购员；
- 任务：安排已经批准的采购；
- 默认范围：待采购和采购中；
- 关键列：批准时间、申请人、物品摘要、金额、负责人；
- 默认排序：批准时间从早到晚；
- 操作：打开并登记采购进度。
3. 列表列不是越多越好
列选择原则：
- 识别记录：编号、标题；
- 判断优先级：状态、紧急程度、等待时间；
- 支持当前任务：金额、负责人、关键日期；
- 其余详情打开记录查看。
如果一个视图需要横向滚动很久，通常说明它承载了多个不同任务。考虑拆成多个角色视图。
4. 设计筛选和排序
常见筛选：
- 状态；
- 时间范围；
- 部门；
- 申请人；
- 金额范围；
- 物品类别；
- 当前负责人。
默认筛选应贴合任务。例如“待采购”默认不显示已完成和已作废记录。
默认排序应暴露需要优先处理的事项：
- 最早批准的在前；
- 即将超时的在前；
- 紧急事项优先。
5. 导出设计
导出前确认：
- 使用者和业务目的；
- 导出当前筛选还是全部数据；
- 需要主信息还是明细；
- 金额和日期使用什么格式；
- 是否包含敏感字段和附件；
- 文件是否会交给外部人员；
- 谁有权限；
- 是否需要记录导出行为。
不要提供一个默认“全部字段、全部记录”的导出，然后把筛选责任留给用户。
6. 打印设计
打印通常服务于：
- 归档；
- 签字；
- 现场操作；
- 随货或对外提供；
- 标签。
设计前确定：
- 纸张和方向；
- 页眉、编号和日期；
- 明细跨页规则；
- 签字或盖章位置；
- 是否需要水印和多联；
- 哪些内部字段不应打印；
- 打印时使用申请数据还是最终采购结果。
7. 通知设计的五个问题
每条通知都回答：
- 什么业务事件触发？
- 发给谁？
- 为什么这个人需要知道？
- 消息中显示什么？
- 收到后下一步做什么？
采购案例：
| 事件 | 接收者 | 内容重点 | 下一步 |
|---|---|---|---|
| 提交成功 | 申请人 | 编号、状态 | 等待审批 |
| 产生审批任务 | 当前审批人 | 用途、金额、截止时间 | 打开处理 |
| 退回 | 申请人 | 退回意见 | 修改重提 |
| 全部批准 | 申请人、行政采购员 | 已批准、进入待采购 | 行政采购 |
| 采购完成 | 申请人 | 完成日期和结果 | 查看或确认 |
避免把完整敏感信息直接放进所有通知。
8. 通知不能代替待办和状态
消息可能被忽略、延迟或删除。必须处理的事项还需要：
- 明确当前责任人；
- 可持续查询的待办入口；
- 当前状态；
- 超时视图；
- 完成动作。
通知只是提醒，不是业务事实本身。
9. 定时任务与周期工作
适合定时处理：
- 每天提醒即将超时的审批；
- 每周向负责人汇总积压；
- 每月生成固定检查事项；
- 定期检查长期未完成记录。
设计时说明：
- 时间和时区；
- 节假日处理；
- 重复运行是否产生重复结果；
- 失败后是否重试；
- 谁能看到运行结果；
- 谁负责处理异常。
不要让定时任务在无人知晓时悄悄修改高风险业务结果。
10. 外部协作先定义业务契约
当数据来自或发送到其他系统时，业务开发者先回答：
- 交换什么业务对象；
- 哪一方负责创建，哪一方是主要维护者；
- 从哪边到哪边；
- 实时、定时还是人工触发；
- 用什么业务标识识别同一条记录；
- 哪些字段必须有；
- 外部记录不存在、重复或冲突时怎么办；
- 失败后谁能发现、怎样补救；
- 是否允许用户在 Kimpo 中修改外部维护的信息。
这是一份业务契约。具体连接方式可以由相应人员处理，但业务含义必须由应用设计先明确。
11. 防止重复和冲突
外部协作常见风险：
- 同一记录被重复导入；
- 两边同时修改同一字段；
- 外部类别在 Kimpo 中找不到对应值；
- 已停用人员仍被作为负责人；
- 发送成功但回执丢失，重试后重复创建；
- 一边删除，另一边仍在使用。
为每类冲突定义：
- 如何识别；
- 哪一边优先；
- 是否自动处理；
- 何时需要人工决定；
- 决定和修正是否保留记录。
12. 建立协作设计清单
| 编号 | 类型 | 触发 | 对象/范围 | 接收者或目标 | 失败处理 | 负责人 |
|---|---|---|---|---|---|---|
| N-01 | 通知 | 申请退回 | 当前申请 | 申请人 | 待修改视图仍可见 | 应用管理员 |
| S-01 | 定时提醒 | 每工作日 9:00 | 超时审批 | 当前审批人、负责人 | 下次重试并进入异常清单 | 业务负责人 |
| X-01 | 外部数据 | 人工同步物品目录 | 启用物品 | 采购应用 | 冲突进入待处理清单 | 行政管理员 |
13. 常见错误
- 一个万能视图显示所有字段和所有记录；
- 默认视图包含大量已完成数据，待办反而难找；
- 导出不受数据范围和敏感字段限制；
- 通知很多，但没有明确待办和负责人；
- 定时任务失败无人知道；
- 外部数据的维护责任不明确；
- 冲突时随意覆盖；
- 为未来可能的集成提前复杂化第一版。
14. 本章完成标准
- [ ] 每个主要角色都有完成任务所需的视图；
- [ ] 列、筛选和排序围绕明确业务目的；
- [ ] 导出和打印有用途、范围与权限；
- [ ] 每条通知都有事件、接收者和下一步；
- [ ] 必做事项不只依赖通知；
- [ ] 定时任务考虑时区、重复、失败和负责人；
- [ ] 外部协作明确数据责任、识别方式和冲突处理。
下一步
应用设计的各部分已经齐备，但还不能立刻开工。下一章将通过系统化评审检查蓝图是否完整、一致、可实现：开发前的应用蓝图评审。