Run any Skill in Manus
with one click
with one click
Run any Skill in Manus with one click
Get Started$pwd:
$ git log --oneline --stat
stars:10
forks:1
updated:May 12, 2026 at 03:09
File Explorer
SKILL.md
识别业务能力并分类子域(Core/Supporting/Generic),产出核心域声明与所有权建议。
从不变量出发设计聚合边界:聚合根、实体、值对象、事务边界与跨聚合一致性策略。
映射限界上下文间的关系与集成策略:模式选择、契约所有权、失败模式与版本策略。
设计限界上下文及其通用语言:边界、职责、词汇表、团队所有权与边界 ADR。
协作式领域发现:通过事件风暴或领域故事讲述,产出事件流、命令/事件候选、热点与歧义清单。
设计构造块间的协作机制:领域事件、领域服务、仓储接口与工厂。
| name | ddd-openspec-bridge |
| description | 将 DDD 战术建模工件映射为 OpenSpec 结构化规范,实现从领域建模到工程实现的平滑衔接。 |
| risk | safe |
| source | self |
| tags | [ddd, implementation, openspec, sdd] |
| date_added | 2026-05-11 |
🌐 English version: English
ddd-scope)ddd-subdomains)ddd-contexts)ddd-context-map)ddd-aggregates)ddd-domain-interactions)ddd-discover)ddd-model-review)openspec/changes/<change-id>/ 下创建目录,生成本次变更的 .openspec.yaml。注意:这与全局 openspec/config.yaml 不同——后者由 ddd-contexts 阶段一次性维护,用于声明领域-限界上下文映射与架构约束。proposal.md):
ddd-scope 的问题陈述映射至 Why。ddd-subdomains 的分类组织优先级:Core 子域须全量 Scenario 化,Generic 子域可引用已有规范或外部组件。ddd-contexts 的上下文目录,在 specs/<bounded-context>/<capability>/spec.md 下建立每个能力的规范文件。禁止使用扁平的 specs/domain-model/ 目录——它会破坏限界上下文与领域目录的战略对齐。ddd-domain-interactions 中的命令与领域服务;一个 Requirement 对应一条可独立验证的业务能力,Scenario 数 ≤ 5 且不跨聚合根。ddd-aggregates 中的聚合行为与不变量,以 Given/When/Then 描述;P0 级不变量必须有对应 Scenario。ddd-contexts 的词汇表,确保 proposal.md 与所有 spec.md 中的术语均落在词汇表内;未收录术语必须先回写词汇表或改用同义词。design.md):整合 ddd-context-map 的集成模式与 ddd-domain-interactions 的协作机制;描述分层架构映射、跨上下文翻译(ACL)、事件发布/消费范式(Outbox 模式、幂等键、一次事务仅修改一个聚合——见 ddd-openspec-mapping.md 附录 A)。tasks.md):按 Spec 依赖顺序(Domain Model → Repository → Application Service → API/集成)拆解任务,每个任务关联对应的 Requirement 或 Scenario 作为验收标准。| 工件 | 结构要求 |
|---|---|
proposal.md | 包含 Why, What Changes, Impact(Capabilities / 聚合变更), Goals。 |
design.md | 包含架构设计、数据模型映射、核心数据流、接口协议定义。 |
specs/ 目录 | 按能力组织的子文件夹,包含 spec.md(Requirement + Scenario 格式)。 |
tasks.md | 包含任务标题、任务描述、关联 Spec 路径、验收标准。 |
specs/ 按限界上下文分目录,未出现扁平的 domain-model/。ddd-aggregates 的 P0 不变量均已转化为 Scenario。proposal.md 与所有 spec.md 中的术语均可在 ddd-contexts 词汇表中查到;proposal.md 中的 Capabilities 与 ddd-contexts 保持一致。design.md 中明确遵循 Outbox 模式、幂等键与“一次事务仅修改一个聚合”约束。tasks.md 中的任务具备可执行性,且每个任务都有明确的 Requirement / Scenario 引用作为验收标准。ddd-aggregates 或 ddd-domain-interactions。ddd-context-map。ddd-aggregates 重新界定聚合行为。ddd-domain-interactions 拆分命令与领域服务。ddd-contexts 词汇表 → 回溯至 ddd-contexts 补录或统一术语。@ddd-openspec-bridge
根据已完成的"会议室预订系统"建模产出,生成 OpenSpec 变更集规范:
- 聚合:Booking, RoomSchedule
- 关键流程:预订申请、冲突检测、签到、取消
- 上下文:Booking Context, Room Catalog Context
请输出 proposal.md, design.md 以及 specs/booking-context/booking/spec.md 的核心 Requirement 与 Scenario 片段。
完整的 Requirement / Scenario 写法示范见 ddd-openspec-mapping.md §5(以“用户注册”为例的端到端最小可行示例)。