领域驱动设计Skill：让 AI 成为你的领域建模专家，把业务规则真正写进代码
- 它是什么：一个把 DDD（领域驱动设计）战略模式与战术模式固化成 AI 行为准则的技能，覆盖实体、值对象、聚合、有界上下文、领域事件与一致性策略。
- 它解决什么：多数团队懂 DDD 名词却落不了地——聚合越拆越大、业务逻辑散落在 Service 里、一个事务改多个聚合、到处是原始类型。这个技能让 AI 在建模时按规则办事，并主动指出反模式。
- 怎么用：安装后，用一句「帮我建模 XX 业务领域」即可激活，AI 会先读项目上下文文件，再按通用语言 → 有界上下文 → 聚合 → 一致性策略的顺序输出设计。
- 适合谁：后端架构师、业务系统开发者、正在做遗留系统重构或微服务拆分的团队，以及需要和领域专家对齐术语的产品/业务同学。
- 最大差别：普通大模型会给你一段「看起来像 DDD」的代码，而这个技能会拒绝贫血模型、拒绝跨聚合对象引用、拒绝单事务多聚合，并给出可勾选的检查清单。
该技能叫什么？如何一键安装 AI 技能提升开发效率？
基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | 领域驱动设计Skill |
| 技能英文名 | domain-driven-design |
| 技能ID | 11710 |
| 核心描述 | 领域驱动设计（DDD）的战术和战略模式，包括实体、值对象、聚合、有界上下文和一致性策略；用于建模业务领域、设计聚合边界、实现业务规则或规划数据一致性 |
它解决什么问题
在真实项目里，DDD 的失败往往不是「不懂概念」，而是「没有纪律」：
- 聚合边界拍脑袋决定，最后变成几千行、几十个关联对象的巨型聚合，乐观锁冲突不断；
- 领域对象只剩 getter/setter，
calculateTotal()、validate()、submit()全部堆在 Service 里，形成典型的贫血域模型； - 下单时顺手扣库存，把订单和库存放进同一个数据库事务，服务一拆就崩；
customerId、productId、price全是 string 和 number，参数顺序写错也能编译通过；- 同一个「客户」在销售、客服、计费三个团队嘴里是三套含义，接口对不上。
这个技能的价值，就是把这些隐性的建模纪律变成 AI 的硬约束：从小聚合开始、建模前先定义通用语言、值对象必须不可变、跨聚合一致性走领域事件、聚合之间只用身份引用。
一键安装的思路与步骤
技能市场的具体入口、命令与版本要求以官方说明为准，这里给出通用的操作路径：
- 确认前提：你所使用的 AI 编程工具或 Agent 平台支持「技能 / Skill」机制，并能读取项目内的说明文件（如架构说明、规范文档）。若不支持技能机制，通常也可以把技能说明作为系统提示词或规则文件引入，具体方式以官方说明为准。
- 找到技能：在技能市场或技能列表中，用技能ID 11710 或英文名 domain-driven-design 检索，也可以直接用中文名「领域驱动设计」搜索。
- 一键添加：在技能详情页点击安装 / 启用，将其绑定到你当前的工作空间或项目。多数平台支持「项目级启用」，建议只在业务建模类项目里开启，避免污染纯前端或脚本类任务。
- 验证是否生效：新建一个会话，输入「帮我为电商下单场景设计订单聚合，注意 DDD 规范」。如果 AI 的输出中出现以下特征，说明技能已生效：
- 先问或先声明通用语言与限界上下文；
- 聚合从单实体起步，
customerId、productId只做 ID 引用； Money、Quantity、OrderId等被封装成不可变值对象并自带校验；- 明确写出「每个事务只更新一个聚合」，跨聚合用领域事件或 Saga 补偿；
- 主动列出反模式提醒（贫血模型、大型聚合、原始类型痴迷）。
- 固化到项目：把技能产出的词汇表和建模结论沉淀进项目文档，后续每次建模让 AI 先读这些文档，形成正循环。
该技能的主要功能和特点
- 战略建模：有界上下文划分。提供上下文识别的四个判断问题（通用语言在何处变化、哪个团队拥有哪个概念、集成点在哪、哪些能独立部署），并用「销售 / 支持 / 计费三个上下文中的客户含义不同」这类图示帮助对齐。
- 上下文映射六模式：共享内核、客户-供应商、顺从者、防腐蚀层、开放主机服务、发布语言，每种都标注了适用场景，避免团队在集成方式上吵架。
- 通用语言落地机制：不只是喊口号，而是给出「从领域专家对话提取术语 → 写成精确定义 → 在类名/方法名/变量名中强制执行 → 随理解演进」的四步法，并示范词汇表条目（含「非：购物车（是意图，非订单）」这类排除项）。
- 战术模式全家桶：实体（身份相等、状态可变）、值对象（不可变、属性相等、自我验证）、聚合（边界保护不变式、根唯一）、领域事件（过去时命名、不可变事实）、仓库（每聚合一个、只返回聚合根）。
- 聚合大小启发法：给出「聚合过大」和「聚合过小」的双向判断信号——频繁乐观锁冲突、为简单操作加载过多数据是过大；不变式未受保护、规则散落服务中是过小。这个双向视角比单向的「拆小」更实用。
- 一致性策略分级：单聚合内用 ACID 事务，同服务跨聚合用最终一致性 + 领域事件，跨服务用 Saga + 补偿，读模型用投影，并给出选择对照表。
- 三种事件模式区分：事件通知、事件携带状态、事件溯源，分别对应松耦合、性能/离线、审计/时间查询。
- 反模式拦截：贫血域模型、大型聚合、原始类型痴迷，都给出「反模式写法 vs 更好写法」的对照代码。
- 上下文内化能力：建模前会主动读取项目的架构说明、
docs/specs/规范、CONSTITUTION.md等约束文件，让设计贴合项目现状而不是空中楼阁。 - 可勾选的实现检查清单：聚合设计、实体、值对象、仓库四类共十余项验收标准，可直接用于 Code Review。
和普通工具比强在哪：普通代码生成器给你「能跑的代码」，这个技能给你「能扛住业务变化的结构」，并且会为了守住边界而拒绝你的不合理要求，例如当你说「下单时顺便扣库存」，它会提示这违反单事务单聚合原则并给出 Saga 方案。
如何使用该技能？
步骤 1：准备好项目上下文 建模前把架构说明、现有领域模型、需求规范放到 AI 可读取的位置。技能会优先读项目说明文件与规范文档，这一步做得越扎实，输出越贴合实际。
步骤 2：用一句话激活技能 示例输入：
我们做一个 SaaS 订阅计费系统，涉及套餐、订阅、账单、支付、退款。帮我建模：先给通用语言和限界上下文，再做聚合设计，最后说清一致性策略。
步骤 3：先对齐通用语言 技能会输出术语表，例如「订阅：客户对某套餐在特定周期内使用服务的权利，区别于订单（一次性购买）」。此时你要做的是挑错：把不符合业务习惯的词改掉，这一轮值得多花时间。
步骤 4：让它划分有界上下文并做上下文映射 输出通常包含上下文清单（如「计费上下文」「订阅管理上下文」「支付上下文」）与集成模式建议，例如支付上下文对外发布开放主机服务，计费侧用防腐蚀层隔离第三方支付模型。
步骤 5：做战术建模 典型输出结构：
- 聚合根
Subscription，内含SubscriptionId、PlanId（仅 ID 引用）、Period（值对象）、SubscriptionStatus； - 值对象
Money含amount与currency，构造时校验金额非负，add()在货币不一致时抛错； - 行为方法
renew()、cancel()、changePlan()写在聚合内部，而不是 Service 中； - 领域事件
SubscriptionRenewed、InvoiceIssued，过去时命名、携带必要数据。
步骤 6：确定一致性策略
输入追问：「续费成功后要出账单并扣款，怎么保证一致性？」技能会给出「续费聚合内事务 + 发布 SubscriptionRenewed → 账单处理程序生成账单 → 支付 Saga（扣款失败则退款并回滚订阅状态）」的分层方案。
步骤 7：用检查清单验收 把技能输出的检查清单直接贴进 PR 描述，逐项打勾：不变式是否在边界内受保护、是否只通过 ID 引用其他聚合、值对象是否全部只读、仓库是否只返回聚合根。
步骤 8：沉淀与迭代 把确认后的词汇表、上下文地图、聚合图写入项目文档，下一轮建模让 AI 先读它们，避免每次都从零开始。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 领域驱动设计Skill（本技能） | 内置 DDD 纪律的 AI 建模顾问 | 有界上下文、上下文映射、通用语言、实体/值对象/聚合/事件/仓库、一致性策略、反模式拦截、检查清单 | 低：在支持技能的平台一键启用，或用英文名/技能ID检索；输出质量依赖你提供的业务信息 | 业务建模、聚合边界设计、微服务拆分、遗留系统重构 | 优势：约束明确、会主动拒绝反模式、输出可直接进 Code Review；不足：需要业务侧配合确认术语，纯技术类任务用不上 |
| 通用大模型直接对话 | 通用问答与代码生成 | 能讲 DDD 概念、能写示例代码 | 极低：开箱即用 | 概念答疑、临时写个小例子 | 优势：零门槛；不足：容易产出贫血模型、聚合边界随意、缺少一致性分级，需要你反复纠正 |
| DDD 经典书籍与方法论（如原著 + 团队建模工作坊） | 方法论与组织实践 | 完整的战略/战术理论体系、事件风暴等工作坊形式 | 高：需要团队投入时间学习与共创 | 组织级架构治理、跨团队统一语言 | 优势：体系完整、能改变团队认知；不足：落地慢、依赖专家、缺少即时代码级产出 |
| 代码脚手架 / ORM 代码生成器 | 代码生成工具 | 根据表结构生成实体与仓储 CRUD | 低：配置数据源即可 | 简单 CRUD、快速原型 | 优势：快；不足：以数据库为中心，天然导向贫血模型与大聚合，不解决边界与一致性问题 |
| 架构评审 / 建模白板工具 | 协作建模 | 画上下文地图、事件流、聚合图 | 中：需要人工绘制与维护 | 团队共创、汇报沟通 | 优势：可视化好、便于对齐；不足：图与代码脱节，无法生成符合规范的领域模型代码 |
选型建议：如果你要的是「把 DDD 落到代码里、并且每天都能用」，本技能的性价比最高；如果团队还没建立 DDD 共识，先用书籍与工作坊打底，再用本技能承接落地；纯 CRUD 项目不必强上。
该技能的典型应用场景与实际体验情况
场景一：电商下单与库存扣减的一致性设计
角色是后端架构师，痛点是「下单扣库存写在同一个事务里，秒杀一上就锁表」。使用方式是描述业务链路后追问一致性方案，技能会拆出订单聚合、库存聚合，用 OrderPlaced 事件驱动库存预留，并给出 Saga 补偿顺序（取消订单 → 释放库存 → 退款）。
实际体验：上手难度低，一次提问就能拿到分层方案；效果最明显的是它会把「不要在一个事务里更新多个聚合」当成硬规则反复提醒；注意点是 Saga 的补偿动作必须幂等，技能会提示但需要你结合中间件能力落地。
场景二：SaaS 多业务线的有界上下文拆分 角色是技术负责人，痛点是「客户」在销售、客服、计费三个系统里字段完全不同，接口天天扯皮。使用方式是先让它识别上下文边界，再做上下文映射。 实际体验：技能输出的「同一术语在不同上下文含义不同」对照，可以直接拿去做跨团队对齐的幻灯片；防腐蚀层的建议对隔离第三方支付/税务模型尤其有用；注意点是上下文划分涉及组织架构，AI 只能给技术建议，最终要靠团队共识。
场景三：遗留系统重构与贫血模型治理
角色是接手老系统的开发者，痛点是 Service 层三四千行、规则散落、没人敢改。使用方式是把现有类结构贴给 AI，让它标注反模式并给出重构顺序。
实际体验：技能的反模式段落（贫血域模型、大型聚合、原始类型痴迷）几乎是为这类代码写的，能明确指出「OrderService.calculateTotal() 应该回到 Order.total」；建议按「先引入值对象 → 再把行为搬回实体 → 最后拆聚合」的顺序渐进重构，避免一次性大改；注意点是重构涉及回归测试，务必先补测试再动结构。
场景四：新人上手与建模评审 角色是团队新人或评审者，痛点是「DDD 名词都认识，但不知道自己画的对不对」。使用方式是把聚合图描述给 AI，让它按检查清单逐条打分。 实际体验：检查清单（单实体可作为根、不变式在边界受保护、其他聚合仅通过 ID 引用、每聚合一事务）非常可操作，评审时不用凭感觉；注意点是清单是启发式而非教条，极少数场景确实需要更大的聚合，此时技能会提示「仅在不变式要求时扩展」，需要你用业务理由说明。
该技能能为用户带来的价值
- 把方法论变成可执行纪律：DDD 最大的成本是「知道但做不到」。技能把约束前置到生成环节，贫血模型、跨聚合引用、单事务多聚合这些高频错误在写代码之前就被拦下。
- 显著压缩建模讨论时间：过去一轮聚合边界评审往往要开两三次会，现在可以让 AI 先出一版含通用语言、上下文地图、聚合图的完整草案，团队在其上做减法，讨论从「从零构思」变成「评审与修正」。
- 降低一致性设计的门槛：ACID / 最终一致性 / Saga / 投影的分级对照表，让不熟悉分布式事务的开发者也能选对策略，避免「先上事务，拆服务时再返工」。
- 统一团队语言，减少沟通损耗：通用语言词汇表带「非：xxx」的排除项，能有效消除同词异义，这对跨团队接口对齐的价值往往超过代码本身。
- 长期可维护性收益：小聚合意味着更少的锁冲突与更小的加载成本，值对象意味着参数不会错位、校验不会遗漏，领域事件意味着扩展新流程时不必改动核心聚合——这些都是随时间放大的复利。
- 可直接复用的资产：词汇表、上下文地图、聚合设计、检查清单四类产出都能沉淀进项目文档，成为团队长期资产，而不是一次性对话。
常见问题 FAQ
Q1：这个技能怎么安装？需要付费吗？ A：在支持技能机制的 AI 编程工具或 Agent 平台中，用技能ID 11710 或英文名 domain-driven-design 检索并一键启用即可，也可以直接用中文名搜索。具体入口、支持平台与是否收费以官方说明为准。如果你的工具不支持技能机制，通常也可以把技能说明作为规则/系统提示词引入，效果接近但不如原生技能稳定。
Q2：它和直接问大模型「帮我用 DDD 设计订单」有什么区别？ A：区别在于约束。普通对话里模型容易给你贫血模型和巨型聚合，因为它倾向于「满足你的字面要求」；而这个技能内置了「从不创建贫血域模型」「从不通过对象引用其他聚合」「从不在单个事务中更新多个聚合」等硬性禁止项，会反过来纠正你的不合理设计，并附带检查清单供验收。
Q3：适合谁用？前端或脚本类项目需要吗？ A：最适合后端架构师、业务系统开发者、正在做微服务拆分或遗留系统重构的团队，以及需要与研发对齐术语的产品/业务同学。纯前端页面、一次性脚本、简单 CRUD 工具类项目通常不需要，强行引入反而增加设计成本。
Q4：它会不会过度设计，把简单项目搞复杂？ A：这个风险真实存在，但技能本身有对冲机制：它要求「从小聚合开始，仅在不变式要求时扩展」，并列出聚合过大的信号。实际使用时建议明确告诉它业务复杂度与团队规模，简单模块就让它用单实体聚合加基本值对象，不必上事件溯源和 Saga。
Q5：和 DDD 书籍、建模工作坊这类方案怎么选？ A：两者不冲突。书籍与工作坊解决「团队认知统一」，周期长但影响深；本技能解决「日常落地与代码级产出」，即时可用。推荐路径是先用工作坊建立共识，再把本技能接入日常开发流程承接建模与评审；如果你只是个人开发者想快速把业务规则写进代码，直接用本技能即可。