spec产物如何生成

[heucoder]

1. spec产物是如何按照DDD的设计模式生成的，即如何让一个spec.md表示一个领域，如何提示AI，还是由人工来维护呢

[grissomsh]

spec 产物按照 DDD 设计模式生成，核心是 DDD 的限界上下文对应 OpenSpec 的 specs/ 子目录，一个领域 = 一个 capability 文件夹 = 一个 spec.md。

映射关系

与仓库 README 中 DDD 到 OpenSpec 映射 章节一致：

OpenSpec 规范结构	对应的 DDD 产出物	说明
领域 — specs/<name>/spec.md	限界上下文	一个能力目录对应一个限界上下文
需求 — ### Requirement:	领域服务 / 命令	描述一个核心业务操作
场景 — #### Scenario: (Given/When/Then)	聚合行为	精确描述聚合的行为契约
技术设计 — design.md	应用服务	协调多领域服务，管理事务与安全
实施任务 — tasks.md	战术设计待办	实体、值对象、仓储接口的实现任务化

仓库中 openspec/specs/ 的 7 个领域均遵循此结构。

谁来维护？

角色	职责
人	定义限界上下文边界、核心场景、优先级（P0/P1/P2），评审 AI 产出的 spec
AI	将自然语言需求转化为标准 BDD 格式、补全边缘场景、生成 tasks.md

本项目的完整实践流程：/opsx:explore → /opsx:propose → 人评审 spec → /opsx:apply → /opsx:archive

如何让 AI 按 DDD 生成 spec？

关键在 openspec/config.yaml。仓库当前的配置（见 openspec/config.yaml）已将项目上下文和 rules 注入每次 AI 请求：

# 仓库实际 config.yaml 结构
context: |
  Project: ecommerce-mini ...
  Architecture: Layered (HTTP -> Service -> Domain -> Repository) ...
  Code paths: examples/ecommerce-mini/ (Node.js), examples/ecommerce-mini-python/ (Python).

rules:
  specs:
    - Use Given/When/Then (Gherkin) format for all Scenarios
    - Every Requirement must include Priority (P0/P1/P2) and Rationale
    - Use SHALL or MUST for normative requirement language

如果需要让 AI 更进一步按 DDD 限界上下文组织 spec，可以在 context 中补充领域映射声明（如 README 中 战略对齐与目录映射 章节的示例），AI 执行 /opsx:propose 时会自动参考这些约束。

最小化参考

openspec/changes/archive/2026-07-08-add-product-get-by-id/ 是用 v1.5.0 工作流新增的 "按 ID 查询单个商品" 功能，包含完整的 proposal → spec → design → tasks 四个文档，对应的代码改动在 examples/ecommerce-mini/src/http/server.js 和 examples/ecommerce-mini-python/src/api/server.py，可作为端到端参考。

[chejdj]

DDD生成的spec 本质上是对业务代码的翻译(因为实际没有所谓的业务专家，都是基于代码进行业务梳理的)，很容易用着用着 spec文件内容和代码对不齐，工程量大之后，人也维护不动spec文件。实操中，spec做成业务索引/边界比较好，逻辑轻，用的时候在去检索对应的代码会比较好一些