qa-domain-modeling

通过构建状态机、数据流图和服务依赖图来理清复杂的业务逻辑和系统边界。当需求文档复杂、涉及多个子系统交互、或者你搞不清楚数据在不同模块之间怎么流转的时候，应当使用此技能。领域建模不是为了画图而画图——它帮你发现那些"需求文档里没写的"隐式业务规则和系统边界。适用于复杂业务流程的测试范围可视化。 触发场景：画状态图、数据流、服务依赖、建模、领域建模、状态转换、数据流向、服务调用关系、需求文档复杂难以理解时。 Use when the user asks about: state machine, data flow, and service dependency modeling to expose implicit business rules and system boundaries.

⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

领域建模

核心原则

不只是画流程图，而是画出状态机、数据流向、一致性约束点。

加载时机

什么时候读	读哪个
选定视图后，取对应画法与要素	references/modeling-views.md

三种建模视图的完整内容已下沉至 references/modeling-views.md，避免每次触发都占用上下文。

建模输出格式

状态转换表

当前状态	触发事件	目标状态	守卫条件	执行动作
待支付	用户支付	已支付	金额正确	扣减库存
待支付	超时	已取消	超过30分钟	释放库存

数据流表

数据对象	源模块	目标模块	操作	一致性检查点
订单	订单服务	订单表	创建	订单创建后
库存	库存服务	库存表	扣减	扣减后验证

服务依赖表

服务	依赖服务	调用方式	故障影响	降级策略
订单服务	库存服务	同步	下单失败	返回库存不足
订单服务	通知服务	异步	通知延迟	重试+补偿

视图选择速查

业务特征	推荐视图	目的	产出物
有明确状态流转	状态转换图	跟踪关键对象状态变化	状态转换表
数据跨模块流转	数据流图	追踪CRUD和数据一致性	数据流表
多个服务协同	服务依赖图	识别故障影响和降级	服务依赖表
三者均有	三种视图全建	完整模型	三表联动

输出示例

场景：电商订单状态机建模 → 状态识别：待支付→已支付→已发货→已签收→已完成/已取消/已退款 → 转换分析：正向流转（支付→发货→签收→完成） → 异常转换：支付失败、发货失败、退款申请 → 输出：状态转换表 + 数据流图 + 服务依赖图

场景：用户注册流程 → 数据流建模：注册表单→用户服务→数据库→消息队列→邮件服务

检查清单

建模完成后检查：

• 是否识别了所有关键状态？
• 状态转换是否完整？
• 数据流是否清晰？
• 服务依赖是否明确？
• 故障影响是否分析？
• 降级方案是否设计？

常见建模误区

1. 只画图不建表：画了漂亮的状态图但没输出状态转换表 → 图用于理解，表用于测试，缺一不可
2. 状态遗漏：只画了主路径状态，忽略了中间态和异常态 → 逐一检查每个对象的"非法状态"分支
3. 依赖单向：只画了A→B的调用，没画B→A的回调 → 同步调用必须标注返回路径
4. 数据流断链：数据流出后没画终点 → 每条数据流必须标注终点（存储/消费/丢弃）
5. 忽略降级：只标注了故障影响，没标注降级方案 → 所有同步依赖必须附带降级策略