qa-domain-modeling

该技能依据场景树（可选需求解构表）识别关键状态、数据流向和服务调用关系，输出带MODEL-XXXX与场景ID追溯的状态转换表、数据流表和服务依赖表。它强调发现隐式业务规则与系统边界，并包含覆盖率标注、故障影响和降级方案检查，不执行测试或生成代码。

kokxi

热度 59.31

最近更新 2026-09-29 12:28:10

分类：开发依赖：读写文件应用场景：工作流 / 数据处理 / 模板 / 概念解释

安装技能

复制下面的话术发给你的 Agent，它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill： npx secure-skills-cli add qa-domain-modeling

Metadata

displayName: 测试领域建模
name: qa-domain-modeling
description: 通过构建状态机、数据流图和服务依赖图来理清复杂的业务逻辑和系统边界。当需求文档复杂、涉及多个子系统交互、或者你搞不清楚数据在不同模块之间怎么流转的时候，应当使用此技能。领域建模不是为了画图而画图——它帮你发现那些"需求文档里没写的"隐式业务规则和系统边界。适用于复杂业务流程的测试范围可视化。触发场景：画状态图、数据流、服务依赖、建模、领域建模、状态转换、数据流向、服务调用关系、需求文档复杂难以理解时。 Use when the user asks about: state machine, data flow, and service dependency modeling to expose implicit business rules and system boundaries.
license: MIT
allowed-tools: Read Grep Glob
metadata: {"slug":"qa-domain-modeling","display-name":"测试领域建模","version":"1.8.0","when-to-use":"用户说\"画状态图\"、\"数据流\"、\"服务依赖\"、\"建模\"、\"领域建模\"、\"状态转换\"、\"数据流向\"、\"服务调用关系\"、需要理解复杂业务流程、需求文档复杂难以理解时","related-skills":"{\"upstream\":[\"qa-scenario-tree\"],\"downstream\":[\"qa-ai-context-engineering\"]}","references":"[\"references/modeling-views.md\"]","input-format":"{\"required\":[{\"name\":\"场景树\",\"type\":\"object\",\"description\":\"来自qa-scenario-tree的输出，包含主路径/分支/异常场景\"}],\"optional\":[{\"name\":\"需求解构表\",\"type\":\"object\",\"description\":\"来自qa-req-deconstruction，包含业务规则\"}]}","output-format":"{\"structure\":[\"覆盖率：标注口径（基于现有需求/输入文档），禁止\\\"全覆盖/100%\\\"绝对化表述；缺失模块标注\\\"未覆盖+原因\\\"\",{\"model_id\":\"MODEL-XXXX\"},{\"scenario_ids\":[\"SC-XXXX\"]},{\"state_machine\":\"状态转换图\"},{\"data_flow\":\"数据流图\"},{\"service_dependency\":\"服务依赖图\"}],\"traceability\":[\"每个模型带唯一ID（MODEL-XXXX）\",\"关联场景ID：SC-{场景模块缩写}-{序号}\"]}","error-recovery-guidance":"{\"on_failure\":\"领域模型遗漏子系统时回退到场景树补充\",\"retry_behavior\":\"补全场景后重新建模\"}","categories":"[\"Development\",\"Requirements\"]","depth-requirement":"{\"reference_value\":\"根据业务复杂度调整建模深度：简单×1/中等×2/复杂×3\",\"minimum\":\"至少构建1个领域模型图\"}"}

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

领域建模

核心原则

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

加载时机

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

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

建模输出格式

状态转换表

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

数据流表

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

服务依赖表

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

视图选择速查

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

输出示例

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

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

检查清单

建模完成后检查：

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

常见建模误区

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