SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场skill-spec-ddd

skill-spec-ddd

编程与开发

查看项目

更新于 10-16 09:21

技能介绍

用途

skill-spec-ddd 是一个由领域驱动设计（DDD）模式驱动的规格驱动开发（SDD）框架，定位为企业级系统开发，通过可执行规格（executable specifications）引导开发过程。框架将需求获取、分析与用户故事生成组织为结构化阶段，并强制实施 Git 命名规范以保证需求到代码的完整可追溯性。其角色设定为具备 FANG 级别经验的高级技术栈工程师，目标是构建可处理百万级请求、可水平扩展、可长期维护的系统。

主要能力

第一阶段：需求获取（Discovery）

要求在任何分析或解决方案之前，从以下三个类别各收集至少 3 项信息，通过澄清性问题持续追问直至满足数量：

  • Scope（范围）：系统主要目标、显式包含的功能、显式排除的功能、地理/市场边界、所需外部集成。
  • Technical Scope（技术范围）：预期用户/交易量、延迟/SLA 要求、强制技术栈约束、可用性（uptime %）要求、合规要求（GDPR、HIPAA、PCI）、基础设施预算。
  • Pain Points（痛点）：当前关键业务问题、手动耗时/资源环节、影响运营或收入的重复错误、无法随增长扩展的流程、用户/客户高频投诉、竞品优势。

同时进行利益相关者映射，包括主要用户、次要用户、决策者、阻碍/风险方（法务、合规、安全）、集成方（外部系统、合作方）。

用户故事自动生成

需求收集完成后立即创建用户故事规格，文件命名约定为 spec-ddd/ 目录下的顺序编号 YAML 文件：

  • feat-001-discovery.yml：发现阶段汇总
  • feat-002-scope-[name].yml：每个范围项（至少 3 个）
  • feat-003-tech-[name].yml：每个技术范围项（至少 3 个）
  • feat-004-pain-[name].yml：每个痛点（至少 3 个）
  • feat-005-aggregate-[name].yml：每个识别出的聚合

规则：顺序编号（feat-001、feat-002…）、kebab-case 命名、文件名最长 50 字符。

Git 命名规范

所有用户故事必须包含 Git 分支、提交和 PR 命名规范以保证可追溯性。

  • 分支命名：格式 <type>/feat-<XXX>-<short-description>，类型包括 feat/、fix/、refactor/、test/、docs/。规则：必须包含 feature ID、描述 50 字符以内、kebab-case、不使用下划线或 camelCase。
  • 提交信息：格式 <type>(feat-XXX): <description>，类型包括 feat、fix、refactor、test、docs、chore。规则：必须含 feature ID 括号、祈使语气、首字母小写、结尾无句号、主题行最长 72 字符。
  • PR 命名：格式 <type>(feat-XXX): <Short Description>，PR 描述模板包含关联用户故事（Closes spec-ddd/feat-XXX.yml）、变更列表、已验证的验收标准清单、测试说明。
  • 框架提供 Git 工作流命令示例和命名验证清单。

用户故事 YAML Schema

每个 .yml 文件必须遵循包含以下字段的结构：

  • story：id（顺序 ID）、type（discovery|scope|technical|pain|aggregate|use-case）、status（draft|refined|ready|done）。
  • 用户故事陈述：as_a（角色）、i_want（目标/动作）、so_that（收益/价值）。
  • description：双语（es/en）。
  • domain（DDD 上下文）：bounded_context、aggregate、entities、value_objects、domain_events。
  • acceptance_criteria：含 id、given/when/then 及其西班牙语版本 dado/cuando/entonces。
  • technical：complexity（low|medium|high|critical）、effort_hours、impact、risks（含 mitigation）。
  • business：priority（P0|P1|P2|P3）、kpis_impacted、revenue_impact、cost_savings。
  • dependencies：stories、systems、teams。
  • notes：附加上下文。
  • git：branch_name、commit_prefix、pr_title、related_commits。
  • metadata：created_at、updated_at、author、source。

文档提供 Discovery 汇总、Scope 项、Pain Point 三类示例 YAML 文件。

第二阶段：双语言分析（Es/En）

角色为高级系统架构师，针对每个范围项以双语产出分析矩阵，包含：对领域的影响（影响哪些限界上下文）、技术复杂度、已识别风险、关键假设、成功指标。

可追溯性

框架设计从代码提交 → PR → 用户故事 YAML → 领域上下文的完整可追溯链路，通过 feature ID 在分支名、提交信息、PR 标题与 YAML 文件之间建立关联。

适用场景

适用于需要结构化需求获取、DDD 领域建模、需求到代码可追溯性的企业级系统开发项目，尤其是对合规、可维护性和可扩展性有较高要求的场景。

限制

关于具体安装命令、收费模式、价格、支持的平台、实际运行效果等信息，所提供资料中暂未说明。