删除功能用例设计应选用extension point还是Specialization方案？

用例设计方案建议 #

结合你描述的业务场景和Alistair Cockburn的用例编写原则，优先推荐使用**泛化（Specialization）**的父子用例结构，不建议使用扩展点用例，具体逻辑如下：

为什么不选扩展点用例 #

扩展点的核心定位是描述主用例中可选、临时插入的分支逻辑，属于主用例核心流程的补充项。你的三类删除操作是平级的、完整的独立业务场景，并非某个主删除流程的附加分支，用扩展点实现会导致逻辑层级混乱，可读性差。

泛化结构的适配逻辑 #

泛化结构可以完美匹配当前的共性+差异的逻辑特征：

• 父用例Delete提炼所有删除操作的公共流程：

  1. 从全局删除菜单选择待删除的对象类型
  2. 在弹出的对应对话框中输入对象的唯一标识（用户名/项目名/Post标识）
  3. 点击「Delete」按钮提交操作完成删除

• 子用例Delete User、Delete Project、Delete Post只需要补充各自的差异化逻辑即可（比如删除User的前置权限校验、删除Project后同步归档关联Post的后置逻辑等），既大幅减少冗余内容，也能清晰区分公共逻辑和差异逻辑。

结合Cockburn原则的优化方案 #

如果当前三类删除操作除了对象类型不同之外，没有特殊的权限规则、校验逻辑、后置联动处理，甚至不需要拆分父子用例，直接编写单条Delete Resource用例即可，在步骤中说明“根据选择的对象类型输入对应唯一标识”，进一步降低冗余度。如果后续某类对象的删除逻辑出现特殊调整（比如删除User需要二次身份校验、删除Post支持右键快捷操作无需走全局删除菜单），再拆分独立用例即可。

内容的提问来源于stack exchange，提问作者Krellex