技能使用指南

NET领域驱动设计实现Skill 用法详解

NET领域驱动设计实现Skilldotnet-ddd
10 个章节 约 12 分钟阅读 AI 智能生成

NET领域驱动设计实现Skill：让 C# 项目一键落地战术领域驱动设计

  • 它是什么：一个面向 C#/.NET 的架构类 AI 技能，专门把领域驱动设计（DDD）的战术模式落到代码层面，输出实体、值对象、聚合根、强类型 ID、领域事件、仓库接口等可编译的现代 C# 代码。
  • 框架无关：不绑定 EF Core、不绑定 Web 框架，专注纯领域建模，领域层可以保持"干净"。
  • 带约束清单：技能内置"必须做/禁止做"规则，能主动阻止贫血模型、上帝聚合、暴露 setter 等常见反模式。
  • 有明确边界：只负责战术 DDD（构建块），战略层面的有界上下文与子域分析交给配套的领域分析技能，避免越界乱答。
  • 适合谁用：.NET 架构师、后端开发者，以及正在把 CRUD 系统改造成富领域模型的团队。

该技能叫什么？如何下载安装 AI 技能提升开发效率？

技能中文名：NET领域驱动设计实现Skill 技能英文名：dotnet-ddd 技能ID：12916 版本与许可：详情标注为 1.0.0 版本，MIT 许可，领域为"架构"，角色定位为"架构师"，输出格式为"代码"。

它解决什么问题

在 .NET 项目里做 DDD，难点往往不是"知不知道概念"，而是知道概念却写不对代码：实体和值对象分不清，聚合边界划得过大，业务逻辑散落在应用服务里，聚合之间直接用对象引用而不是 ID，领域事件随手乱发，仓库接口和 EF 实现搅在一起。团队每个人写出来一套风格，最后领域层退化成"数据袋 + 服务"的贫血模型。

这个技能的价值在于：当你描述业务规则时，它直接按战术 DDD 的规范产出对应的 C# 构建块代码，并把约束一起交给你，省掉"查文档 + 对风格"的大量来回。

一键安装的思路与步骤

AI 技能的安装通常遵循"找到技能 → 装入技能目录 → 在新会话中生效"的通用路径。由于技能详情中未给出具体命令与链接，以下步骤为通用描述，具体命令、入口与目录路径请以官方说明为准：

  1. 确认前提：你的 AI 客户端支持"技能（Skill）"机制，且具备代码读写能力；项目为 C#/.NET 工程，本地已安装 .NET SDK。
  2. 获取技能：在技能市场或技能库中按技能名 dotnet-ddd 或技能ID 12916 检索；也可以从技能仓库下载技能包后放入本地技能目录（以官方说明为准）。
  3. 启用技能：在客户端的技能管理界面开启该技能，确认其状态为"已启用"。若技能包内含 SKILL.md 与 references/ 目录，请保持目录结构完整，避免参考文件丢失。
  4. 验证是否生效：新开一次对话，输入类似"帮我在 C# 里设计一个订单聚合根，包含订单行、提交校验和领域事件"的请求。若返回内容包含 Entity<TId> 基类、record 值对象、工厂方法 Create、IDomainEvent 与仓库接口，并且主动提到"仅通过 ID 引用其他聚合""一个事务一个聚合"等约束，说明技能已生效。
  5. 长期使用建议：把技能与项目规范一起写进对话前置说明（如命名空间、项目分层目录），后续生成代码可直接贴进解决方案。

该技能的主要功能和特点

  • 八大构建块全覆盖：实体、值对象、聚合、聚合根、领域事件、仓库、领域服务、规约，每类都有对应的概念说明与 C# 实现方式。
  • 开箱即用的基类模板：提供 Entity<TId> 抽象基类，含身份相等、DomainEvents 集合、RaiseDomainEvent/ClearDomainEvents，并保留供 ORM 使用的受保护无参构造函数。
  • 现代 C# 语法优先：值对象用 record 实现结构相等（如 Money、Address、DateRange），强类型 ID 用 readonly record struct（如 OrderId、CustomerId），减少原始类型满天飞的"字符串/ Guid 灾难"。
  • 聚合不变量内聚：示范由聚合根守护规则，比如"只有草稿订单才能加行"“空订单不能提交”，状态通过行为方法变更，不暴露 setter。
  • 结果模式内置：对"预期内的失败"提供 Result<T> 与 Error，用 Match 做分支处理，避免用异常做流程控制。
  • 约束清单双保险：明确"必须做"（领域层无 EF/HTTP/日志依赖、聚合内部强制不变量、工厂方法创建聚合、异步仓库带 CancellationToken）与"禁止做"（暴露 setter、聚合依赖仓库、上帝聚合、聚合内用领域事件通信、贫血模型）。
  • 按需加载参考资料：building-blocks.md、domain-events.md、patterns.md、project-structure.md 四份参考文件按任务加载，而不是一次性灌入上下文，保证回答聚焦。
  • 与普通工具的区别：普通代码补全只会补全你写的那行，通用大模型容易给出"教学风格"的玩具示例；这个技能产出的是带约束、带边界说明、可直接进项目的战术 DDD 骨架。

如何使用该技能？

  1. 触发技能：在对话中使用触发词让技能被识别，如"DDD"“领域驱动设计”“聚合根”“值对象”“领域事件”“仓库模式”"丰富领域模型"等。
  2. 交代业务背景：说明实体是什么、有哪些状态、有哪些必须立即一致的不变量。示例输入：

    用 DDD 战术模式建模一个订单聚合：订单有客户 ID、订单行列表、状态（草稿/已提交）。只有草稿状态能加行，数量必须大于 0，提交时订单行不能为空，提交成功后要发领域事件。

  3. 拿到结构代码：技能会输出 OrderId 强类型 ID、Order : Entity<OrderId> 聚合根、OrderLine 子实体、OrderCreatedEvent/OrderSubmittedEvent 领域事件，以及 IOrderRepository 接口。
  4. 指定失败处理方式：如果某些失败属于业务预期内，可追加一句"提交失败用结果模式返回，不要抛异常"，技能会改用 Result<Order> 与 OrderErrors.EmptyOrder 的写法。
  5. 继续深挖细节：需要事件分发策略、发件箱模式、集成事件、规约或项目分层时，明确说"参考领域事件/项目结构部分"，技能会按需加载对应参考文件。
  6. 落地到工程：把领域层代码放入独立项目，仓库实现放到基础设施层，应用服务只做编排、不写业务规则；最后用技能生成的约束清单做一次代码评审对照。

输出说明：默认输出为 C# 代码片段，附少量解释。代码中的中文注释用于说明意图，实际落地时可按团队规范调整命名空间与目录。

同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
dotnet-ddd（本技能） 专注 .NET 战术 DDD 的 AI 技能 生成实体、值对象、聚合、领域事件、仓库、强类型 ID、结果模式，附约束清单 需支持技能机制的 AI 客户端，自然语言即可调用 从零搭领域层、改造贫血模型、统一团队 DDD 写法 优势：框架无关、约束明确、按需加载参考；不足：不覆盖战略 DDD，需配合领域分析技能
通用大模型直接提问 通用问答 可按要求写 C# 代码 无安装成本 快速获取示例代码 优势：随手可用；不足：容易产出玩具示例，缺乏一致约束，聚合边界与不变量常被忽略
官方 DDD 指南与示例项目 官方文档与参考实现 完整的微服务 DDD/CQRS 示例、分层说明 需自行阅读与裁剪 学习体系化架构、团队培训 优势：权威、成体系；不足：不是"生成器"，落地仍需自己按业务改写
ORM 脚手架 / 代码生成器 数据模型驱动生成 由数据库表反向生成实体与仓储 需配置数据源与模板 已有数据库、以 CRUD 为主的系统 优势：上手快、量大；不足：天然产出贫血模型，业务规则无处安放

该技能的典型应用场景与实际体验情况

场景一：电商订单聚合建模。 后端开发者手里有一个"订单"业务，规则多、状态多。痛点是订单状态校验散落在各个服务方法里。使用方式：把状态流转规则一次性描述清楚，让技能产出聚合根与行为方法。实际体验：输出的 AddLine、Submit 天然带前置校验，且会主动提示"仅通过 ID 引用其他聚合"，边界感明显强于通用回答。注意点：业务规则要尽量说全，规则越具体，生成的校验越贴合。

场景二：贫血模型改造。 架构师接手一个业务逻辑全在应用服务里的老项目，想逐步把逻辑搬回领域层。使用方式：先用技能把一个服务类里的规则"翻译"成聚合方法，再对照"禁止做"清单排期改造。实际体验：约束清单本身就可以当评审清单用，能快速指出"这里暴露了 setter"“这里聚合依赖了仓库”。注意点：改造是渐进过程，不要一次把大聚合拆完。

场景三：强类型 ID 与值对象统一治理。 团队里到处是 Guid customerId、string email、decimal amount，参数顺序写反也不会报错。使用方式：要求技能生成一组 readonly record struct 强类型 ID 与 Money、Address 等值对象。实际体验：类型系统直接挡住一类低级错误，Money 的跨币种相加会抛异常，比散落的判断更可靠。注意点：与 ORM 映射时需要配置转换器，属于基础设施层工作。

场景四：领域事件与集成解耦。 需要在下单、提交等节点触发后续动作（发通知、写日志、同步下游）。使用方式：让技能定义 IDomainEvent 与具体事件记录，再追问分发与发件箱策略。实际体验：技能会明确"不要用领域事件做聚合内通信"，并指向领域事件参考文件，避免把事件当成万能消息总线。注意点：跨聚合一致性要接受最终一致，事务边界不要硬凑。

该技能能为用户带来的价值

  • 效率提升：把"查概念 + 对写法 + 改代码"的循环压缩成一次对话，领域层骨架从半天缩短到几分钟量级，重复的基类、ID、事件、仓库接口不再手写。
  • 门槛降低：不熟悉 DDD 的开发者也能拿到规范样例，并在约束清单的引导下避开典型反模式；资深开发者则省去大量样板输出。
  • 质量与一致性：团队成员用同一个技能生成代码，命名、分层、异常与结果模式的处理风格趋于统一，代码评审争议显著减少。
  • 长期可维护性：领域层不依赖基础设施，聚合小、边界清、不变量内聚，后续更换持久化方案或拆分服务时改动面更小。
  • 知识沉淀：技能内置的四份参考文件与"必须做/禁止做"清单，本身就是一份可执行的团队建模规范。

常见问题 FAQ

Q1：这个技能怎么安装？需要付费吗？ A：在支持技能机制的 AI 客户端中按技能名 dotnet-ddd 或技能ID 12916 检索并启用，或将技能包放入本地技能目录。技能详情标注为 MIT 许可，本身不涉及额外费用；客户端是否收费、具体安装入口与命令以官方说明为准。

Q2：它和让大模型直接写 DDD 代码有什么区别？ A：区别在于"约束"和"边界"。这个技能只做战术 DDD，明确不适用于简单 CRUD 和贫血模型场景，并在输出中强制执行不变量、ID 引用、工厂方法等规则；通用提问往往给出教学示例，缺少这些一致性约束。

Q3：适合谁用？前端或非 .NET 团队能用吗？ A：面向 C#/.NET 开发者与架构师，输出为现代 C# 代码。非 .NET 团队可以借鉴其中的建模思路，但代码示例不能直接复用。

Q4：它会不会替我做战略层面的领域划分？ A：不会。技能明确把有界上下文、上下文映射、子域分析划给配套的领域分析技能。如果你需要先划分业务边界，应先做战略分析，再用本技能落地代码。

Q5：生成代码能直接上生产吗？ A：可以作为高质量起点，但需要按项目实际补全：命名空间与目录、ORM 映射配置、仓库实现、事件分发机制、参数校验与日志等。建议先用约束清单做一轮自检，再进入代码评审。