返回技能市场
Domain Modeling
通过构建状态机、数据流图和服务依赖图来理清复杂的业务逻辑和系统边界。当需求文档复杂、涉及多个子系统交互、或者你搞不清楚数据在不同模块之间怎么流转的时候，应当使用此技能。领域建模不是为了画图而画图——它帮你发现那些"需求文档里没写的"隐式业务规则和系统边界。适用于复杂业务流程的测试范围可视化。
SKILL.md
⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills
领域建模
核心原则
不只是画流程图，而是画出状态机、数据流向、一致性约束点。
加载时机
| 什么时候读 | 读哪个 |
|---|---|
| 选定视图后，取对应画法与要素 | references/modeling-views.md |
三种建模视图的完整内容已下沉至references/modeling-views.md，避免每次触发都占用上下文。
建模输出格式
状态转换表
| 当前状态 | 触发事件 | 目标状态 | 守卫条件 | 执行动作 |
|---|---|---|---|---|
| 待支付 | 用户支付 | 已支付 | 金额正确 | 扣减库存 |
| 待支付 | 超时 | 已取消 | 超过30分钟 | 释放库存 |
数据流表
| 数据对象 | 源模块 | 目标模块 | 操作 | 一致性检查点 |
|---|---|---|---|---|
| 订单 | 订单服务 | 订单表 | 创建 | 订单创建后 |
| 库存 | 库存服务 | 库存表 | 扣减 | 扣减后验证 |
服务依赖表
| 服务 | 依赖服务 | 调用方式 | 故障影响 | 降级策略 |
|---|---|---|---|---|
| 订单服务 | 库存服务 | 同步 | 下单失败 | 返回库存不足 |
| 订单服务 | 通知服务 | 异步 | 通知延迟 | 重试+补偿 |
视图选择速查
| 业务特征 | 推荐视图 | 目的 | 产出物 |
|---|---|---|---|
| 有明确状态流转 | 状态转换图 | 跟踪关键对象状态变化 | 状态转换表 |
| 数据跨模块流转 | 数据流图 | 追踪CRUD和数据一致性 | 数据流表 |
| 多个服务协同 | 服务依赖图 | 识别故障影响和降级 | 服务依赖表 |
| 三者均有 | 三种视图全建 | 完整模型 | 三表联动 |
输出示例
场景：电商订单状态机建模 → 状态识别：待支付→已支付→已发货→已签收→已完成/已取消/已退款 → 转换分析：正向流转（支付→发货→签收→完成） → 异常转换：支付失败、发货失败、退款申请 → 输出：状态转换表 + 数据流图 + 服务依赖图
场景：用户注册流程 → 数据流建模：注册表单→用户服务→数据库→消息队列→邮件服务
检查清单
建模完成后检查：
- 是否识别了所有关键状态？
- 状态转换是否完整？
- 数据流是否清晰？
- 服务依赖是否明确？
- 故障影响是否分析？
- 降级方案是否设计？
常见建模误区
- 只画图不建表：画了漂亮的状态图但没输出状态转换表 → 图用于理解，表用于测试，缺一不可
- 状态遗漏：只画了主路径状态，忽略了中间态和异常态 → 逐一检查每个对象的"非法状态"分支
- 依赖单向：只画了A→B的调用，没画B→A的回调 → 同步调用必须标注返回路径
- 数据流断链：数据流出后没画终点 → 每条数据流必须标注终点（存储/消费/丢弃）
- 忽略降级：只标注了故障影响，没标注降级方案 → 所有同步依赖必须附带降级策略
评论与讨论
0/2000
还没有评论，分享你的体验吧。