乐正雕漆做后端这些年，DDD 我前前后后推过三四个项目，半数以上中途又默默改回了传统三层架构。原因不是 DDD 理论有问题，而是从“理论”到“代码”这段路太难走，领域建模、聚合边界、防腐层、事务一致性，任何一步没想清楚，后面全是窟窿。后来我开始尝试让 AI 编程助手先读 DDD 规范再动手写代码，把方法论固化成提示词和技能文件，效果比我预期的好不少。这套东西我整理成了一个开源项目，名字叫 cleanddd-skills，本质是一组面向 AI Agent 的 DDD 技能包：不写业务代码，不绑定框架，只负责让 Cursor、Claude Code 这类工具在生成代码前，先按领域驱动设计的规则思考。如果你也被 DDD 落地折磨过，同时又想用 AI 提效，这篇文章值得看完。
1. DDD 落地的尴尬，到底卡在哪
1.1 卡住的地方从来不是语法，而是建模
很多人觉得 DDD 难，是因为它不像三层架构那样有明确的 Controller-Service-Mapper 路径。DDD 要求开发者和领域专家统一语言，先建立领域模型，再设计聚合、值对象、领域事件、应用服务。这套东西做得好，系统确实能抗住复杂业务变化，但问题是团队往往在需求还没理清时就被要求“先跑起来”，结果就是建模阶段被压缩，代码层生搬硬套各种模式。
我见过最典型的场景：项目里到处是 XXXEntity、XXXRepository、XXXServiceImpl，文件结构看着很 DDD，点进去发现 Service 里写了两千行业务逻辑，聚合根连实体都不是，领域事件只是空壳。这种“伪 DDD”比不用 DDD 还难受，因为多了抽象层，但没有任何收益。
AI 在此时反而是个不错的“外挂”。它不会像人一样碍于情面跳过思考步骤，只要你把规则写清楚，它会老老实实先做事件风暴，再画限界上下文，再生成代码。cleanddd-skills 做的就是这件事：把 DDD 建模流程变成 AI 可执行的上下文。
1.2 传统三层架构与领域模型的冲突
传统三层架构的 Controller-Service-DAO 思路，天然把业务逻辑堆在 Service 层。当业务规则一多，Service 层就变成一个“上帝类”。改一个订单状态，可能要同时改订单表、库存表、日志表，还可能在事务里调用远程服务。这种写法不是不能上线，而是后续每一次需求变更都像走钢丝。
DDD 要求把业务逻辑收敛到聚合根和领域服务里，应用层只做协调和事务边界控制。但要真正做到这点，团队必须对“哪些行为属于订单聚合自身，哪些行为属于应用服务编排”有共识。这个共识不是开会能解决的，而是需要一套能落到代码上的检查规则。
cleanddd-skills 的应对方式，是把这些规则写成 AI 能理解和执行的 markdown 文件。模型在生成代码前会先读这些文件，然后按 DDD 战术模式的约束输出。表面上看只是多了一个步骤，实际上相当于给 AI 装上了“领域建模方法论”这个外脑。
1.3 AI 时代，落地 DDD 的成本被重新分配
过去我们推行 DDD，最大的成本是沟通和试错。领域专家画一张事件风暴贴纸，开发照着一顿猛敲，回头发现模型理解错了，改起来几乎等于重写。有了 AI 之后，试错成本被大幅压缩——模型可以很快产出一版聚合设计初稿，开发只需要对照需求做取舍，而不是从零开始建模。
当然，AI 生成的东西不能直接用。我的定位是“AI 负责把 DDD 的重复性推导做掉，人负责决策和兜底”。cleanddd-skills 就是在给 AI 划边界：让它先产出领域模型、限界上下文、聚合边界，再由人来修订。这种协作方式，比人肉建模快，也比无脑让 AI 写 CRUD 靠谱。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. cleanddd-skills 是怎么一个东西
2.1 项目定位与整体结构
cleanddd-skills 不是一个应用，也不是代码生成器，它是一组“技能包”，专门给支持 Skills 机制的 AI 编程工具使用。当前 Cursor 和 Claude Code 都支持通过 markdown 定义 skill，AI 在对话中可以按需读取对应文件，从而获得该领域的专业知识。项目结构大致如下：
text复制cleanddd-skills/
├──