关于
规划和路由领域驱动设计工作，从战略建模到战术实现和事件架构模式。
name: domain-driven-design description: "规划和路由领域驱动设计工作，从战略建模到战术实现和事件驱动架构模式。" risk: safe source: self tags: "[ddd, domain, bounded-context, architecture]" date_added: "2026-02-27"
领域驱动设计
何时使用本技能
- 需要用明确的边界对复杂业务领域进行建模。
- 想要判断完整的 DDD 是否值得增加的复杂性。
- 需要将战略设计决策与实现模式连接起来。
- 正在从领域需求规划 CQRS、事件溯源、Saga 或投影。
不应使用本技能的场景
- 问题是简单的 CRUD，业务复杂度低。
- 只需要局部的 bug 修复。
- 无法获取领域知识且没有代理产品专家。
指导说明
- 在承诺使用完整 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.
局限性
- 本技能不能替代与领域专家的直接研讨会。
- 不提供特定框架的代码生成。
- 不应被用作过度工程化简单系统的理由。
兼容工具
Claude CodeCursor
标签
后端开发
