domain-driven-design
应用领域驱动设计与 AI 指导
复杂的软件项目需要结构化的领域建模，但了解何时以及如何应用 DDD 具有挑战性。此技能帮助您评估 DDD 的可行性，规划战略架构，并路由到专门的实现技能。
下载技能 ZIP
在 Claude 中上传
前往 设置 → 功能 → 技能 → 上传技能
开启并开始使用
测试它
正在使用“domain-driven-design”。 使用 @domain-driven-design 来评估我们的电子商务平台是否应该采用完整的 DDD
预期结果:
可行性检查结果：您的电子商务平台可能符合多个标准，因为存在复杂的业务规则（定价、库存）、多个团队以及集成合同。建议：首先采用战略 DDD，为订单、库存、支付和配送建立限界上下文。
正在使用“domain-driven-design”。 帮助我们规划医疗领域的战略工件
预期结果:
医疗领域的战略交付物：（1）识别核心子域（如患者管理、调度、计费）的子域图；（2）具有 HIPAA 合规边界的限界上下文图；（3）医学术语的通用语言术语表；（4）关键决策的架构决策记录（ADRs）。
安全审计
安全Static analysis flagged 19 potential issues including external_commands and weak cryptographic algorithms. Manual review confirms these are false positives: the @ mentions in skill references were mistaken for backtick execution, and the word 'design' was incorrectly flagged as cryptographic. This is a documentation-only skill containing no executable code, network requests, or file system operations. All findings dismissed as false positives.
质量评分
你能构建什么
架构规划会议
在新项目开始时使用，以确定 DDD 是否合适并规划限界上下文的边界。
重构决策指南
评估现有单体应用以识别子域边界并规划渐进式 DDD 采用。
团队协调工具
在多个团队之间建立共享的通用语言和清晰的所有权边界。
试试这些提示
使用 @domain-driven-design 来评估我们是否应该为 [项目描述] 采用完整的 DDD。运行可行性检查并解释哪些标准已满足。
应用 @domain-driven-design 帮助我们识别 [业务领域] 的子域和限界上下文。列出我们首先应该生成的战略工件。
我们已决定为 [特定限界上下文] 采用 DDD。使用 @domain-driven-design 将我们路由到我们需要的下一步技能，并列出本周的战术交付物。
我们的领域需要可审计性和事件历史。使用 @domain-driven-design 帮助我们决定事件溯源是否合适，以及使用哪些技能来实现。
最佳实践
- 在深入战术实现细节之前先进行战略 DDD
- 使用可行性检查以避免对简单系统过度设计
- 在每个阶段生成明确的工件以确保可衡量的进展
- 路由到专门技能而不是试图用一个提示处理所有事情
避免
- 对没有复杂业务规则的简单 CRUD 应用应用完整的 DDD
- 跳过战略建模直接进入实体设计
- 基于技术层而非业务能力创建限界上下文
- 在没有明确的领域复杂性的情况下使用 DDD 作为过度设计的理由