CleanDDD 建模技能

根据用户需求，设计符合 CleanDDD 原则的业务模型，包括聚合、命令、事件、查询等，确保模型的清晰性和可维护性。

前置输入

• 已有 cleanddd-requirements-analysis 的结构化结果（干系人表、需求条目表、业务实体视图、触发/后续动作表、业务规则与依赖、假设与待确认清单）；缺失时先运行需求分析技能并完成确认。
• 需求条目/业务实体归类已与用户确认或标注了假设。

使用时机

• 当需要将结构化需求映射为 CleanDDD 的聚合/命令/查询/事件/Endpoint 与定时任务设计时。

输入映射关系

• 业务实体视图 → 聚合候选与职责/不变式
• 需求条目表 → 命令/查询及输入输出、幂等性
• 触发/后续动作表 → 领域事件（DomainEvent）与事件处理器
• 干系人表 → API 端点（Endpoints）的认证/鉴权范围与交互场景
• 业务规则与依赖 → 一致性/副作用说明与外部依赖标注
• 假设与待确认清单 → 建模中的“未决问题/假设”与追问清单

工作流

1. 输入校验：确认需求条目表、业务实体视图、触发/后续动作表齐备；缺口先追问或注明假设。
2. 聚合定义：依据职责和不变式，定义聚合根、实体/值对象、行为、触发的领域事件；保持聚合间无直接引用。
3. 命令与查询：为每个需求条目映射命令/查询，命名用 PascalCase；写明输入/输出、幂等性、涉及的聚合行为。
4. 领域事件与处理器：根据触发/后续动作表列出领域事件（DomainEvent）、订阅方、处理动作；避免跨聚合直接操作，使用领域事件驱动。
5. API 端点（Endpoints）：为外部交互补全 HTTP Method、鉴权、幂等性、绑定的命令/查询；标明默认排序/分页。
6. 定时任务：若有周期性需求，定义任务名称、频率、触发的命令/查询。
7. 命名与约束检查：聚合/命令/事件/查询用 PascalCase；确认无共享实体、仅共享值对象；事件命名用过去式。

输出格式（结构化 Markdown，便于代码生成）

• 聚合
  • 名称 | 职责摘要 | 关键不变式
  • 实体/值对象 | 属性（含默认值/可选值） | 行为 | 触发领域事件（DomainEvent）
• 命令（Commands）
  • 名称 | 作用聚合 | 输入 | 触发行为/事件 | 幂等性
• 查询（Queries）
  • 名称 | 作用聚合 | 过滤/排序/分页 | 输出 DTO 或 Response
• 事件处理器（DomainEventHandlers）
  • 领域事件（DomainEvent） | 订阅方 | 处理动作 | 副作用/外部依赖
• API 端点（Endpoints）
  • 路径/方法 | 命令/查询 | 认证/鉴权 | 幂等/一致性说明
• 定时任务（如有）
  • 名称 | 频率 | 触发的命令/查询 | 幂等/补偿

统一命名与放置约定

• 命名风格：聚合/命令/事件/查询/端点使用 PascalCase；事件名称采用过去式。
• 文档输出：采用上述“输出格式”章节的结构化 Markdown，以便后续自动代码生成与审阅。
• 术语统一：统一使用“API 端点（Endpoints）”“领域事件（DomainEvent）”“领域事件处理器（DomainEventHandlers）”等术语。
• 交付承接：本技能输出文件应作为 cleanddd-dotnet-coding 的输入依据；涉及文件命名与目录放置，参见该技能的“统一命名与放置约定”。

核心原则

• 边界明确：聚合之间不直接或间接相互引用。
• 实体共享限制：聚合不共享实体，允许共享值对象。
• 领域事件原则：领域事件由聚合行为产生；跨聚合影响通过领域事件实现最终一致性。
• 关键不变式：在聚合行为前置校验，任何状态变更不得破坏。
• 命名规范：聚合/命令/事件/查询使用 PascalCase，事件用过去式。
• API 端点鉴权（Endpoints）：依据干系人表与需求条目表明确认证范围与幂等性。

交付与确认

• 末尾附“参数汇总 + 是否执行”提示，确保用户确认后再进入 cleanddd-dotnet-coding。
• 列出未决问题或假设，避免后续编码阶段遗漏。