关于 domain-driven-design
domain-driven-design 用于评估复杂业务领域是否适合采用领域驱动设计，并指导团队制定战略产物、衔接实现模式及选择专门技能，同时避免在简单系统中过度使用。
主要功能
- 01采用前评估 DDD 可行性
- 02定义子域与限界上下文
- 03衔接战略设计与实现
- 04将任务转交专门技能
- 05明确阶段产物与待解风险
适用场景
- 01评估复杂业务是否适合 DDD
- 02规划跨团队的领域边界
- 03选择 CQRS 或事件溯源模式
- 04组织领域设计交付物
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/domain-driven-design确认已加载。
附带文件references/ddd-deliverables.md
详细介绍
领域驱动设计
何时使用此技能
- 你需要通过明确的边界对复杂业务领域进行建模。
- 你想判断完整的 DDD 是否值得增加额外的复杂度。
- 你需要将战略设计决策与实现模式衔接起来。
- 你正在根据领域需求规划 CQRS、事件溯源、saga 或投影。
何时不要使用此技能
- 问题只是业务复杂度较低的简单 CRUD。
- 你只需要进行局部缺陷修复。
- 无法获取领域知识，也没有代理产品专家。
说明
- 在投入完整 DDD 之前先进行可行性检查。
- 先产出战略工件：子域、限界上下文、语言词汇表。
- 根据当前任务路由到专门的技能。
- 为每个阶段定义成功标准和证据。
可行性检查
只有在以下条件中至少满足两项时，才使用完整 DDD：
- 业务规则复杂或变化迅速。
- 多个团队正在造成模型冲突。
- 集成契约不稳定。
- 可审计性和显式不变量至关重要。
路由映射
- 战略模型与边界：
@ddd-strategic-design - 跨上下文集成与转换：
@ddd-context-mapping - 战术代码建模：
@ddd-tactical-patterns - 读写分离：
@cqrs-implementation - 以事件历史作为事实来源：
@event-sourcing-architect和@event-store-design - 长时间运行的工作流：
@saga-orchestration - 读模型：
@projection-patterns - 决策日志：
@architecture-decision-records
如果需要模板，请打开 references/ddd-deliverables.md。
输出要求
始终返回：
- 范围与假设
- 当前阶段（战略、战术或事件化）
- 产出的显式工件
- 未解决的风险与下一步建议
示例
Use @domain-driven-design to assess if this billing platform should adopt full DDD.
Then route to the right next skill and list artifacts we must produce this week.
限制
- 此技能不能替代与领域专家直接开展的研讨。
- 它不提供特定框架的代码生成。
- 不应将其用作对简单系统进行过度设计的理由。
评论
支持 Markdown