domain-driven-design

# 领域驱动设计 (DDD) ## 何时使用此技能 - 你需要用明确的边界来建模复杂的业务领域。 - 你想决定完整的 DDD 是否值得投入额外的复杂性成本。 - 你需要将战略设计决策与实现模式联系起来。 - 你正在根据领域需求规划 CQRS、事件溯源、Saga 或投影。 ## 何时不使用此技能 - 问题仅是简单的 CRUD，且业务复杂度低。 - 你只需要局部的 Bug 修复。 - 无法获取领域知识，且没有代理产品专家。 ## 指令 1. 在决定采用完整 DDD 之前，先进行可行性检查。 2. 首先产出战略工件：子域、限界上下文、通用语言词汇表。 3. 根据当前任务路由到专业技能。 4. 为每个阶段定义成功标准和证据。 ### 可行性检查 仅在以下至少两项为真时使用完整 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`。 ## 输出要求 始终返回： - 范围和假设 - 当前阶段（战略、战术或事件驱动） - 产出的明确工件 - 遗留风险和下一步建议 ## 示例 text 使用 @domain-driven-design 来评估此计费平台是否应采用完整的 DDD。 然后路由到正确的下一步技能，并列出我们本周必须产出的工件。 ## 局限性 - 此技能不能替代与领域专家的直接研讨会。 - 它不提供特定框架的代码生成。 - 不应将其作为过度设计简单系统的理由。