.NET DDD 与架构

此 skill 用于在 C#/.NET 代码库中进行架构设计与实现，确保：

• 领域逻辑在领域层，应用层负责编排，基础设施层负责集成
• 聚合边界清晰，事务一致性可解释
• 模块化单体具备明确隔离（internal + 契约项目）

何时使用此 Skill

• 新建/重构 .NET 项目架构（分层、DDD、模块化单体）
• 引入聚合、值对象、领域事件、规格（Specification）
• 拆分业务模块并建立跨模块契约（Contracts）
• 设计应用服务与仓储接口、基础设施适配器

前置条件

• 参考并遵守仓库指令：
  • .github/instructions/dotnet-architecture-good-practices.instructions.md
  • .github/instructions/csharp.instructions.md

核心产出（建议）

• 领域层：聚合根、实体、值对象、领域事件、领域服务
• 应用层：应用服务、DTO、验证、用例编排、事务边界
• 基础设施层：Repository 实现、EF Core、外部服务适配器、事件发布
• 契约层（可选）：跨模块接口与 DTO（或 OpenAPI/AsyncAPI 等）

关键原则（Best Practices）

1. 通用语言：代码里的命名与业务术语一致；避免技术词污染领域模型。
2. 聚合边界：聚合内保证强一致性；跨聚合用应用层编排/领域事件实现最终一致。
3. 富领域模型：业务规则和不变量放到聚合中；不要把领域逻辑堆到 Controller/Service。
4. 模块隔离：模块间只通过“公共契约”交互；禁止跨模块直接查表。
5. 安全在领域：关键授权检查尽量在聚合/领域服务层体现（至少在应用层明确）。

常见反模式（Anti-patterns）

• 贫血模型：领域对象只有属性，规则在应用服务/控制器里。
• “万能 ApplicationService”：一个类负责所有 use case。
• 跨模块直接引用基础设施实现、跨模块直接 EF 查询其他模块表。
• 以异常做正常流程控制（尤其热路径）。

推荐工作流

• 先写：通用语言词表（业务术语）→ 事件流（关键业务事件）→ 聚合边界
• 再写：用例（应用服务）→ 领域模型 → 仓储接口 → 基础设施实现
• 最后补：测试（领域单测 + 应用/集成测试）

使用示例（提示语模板）

• “请按 DDD 建模【订单】聚合：列出不变量、命令、事件，并说明哪些在领域层/应用层/基础设施层。”
• “把【用户注册】流程拆成应用服务编排 + 领域规则，给出跨模块契约建议（同步/事件）。”