赵guo栋开头
提到DDD（领域驱动设计），做后端的人第一反应通常是两件事：概念很美好，落地很痛苦。我见过太多团队在启动会上把事件风暴、聚合划分、限界上下文讲得头头是道，结果一写代码就原形毕露——Service层胖成山，实体变成纯数据容器，值对象被塞成Map，防腐层直接消失。这些不是团队不努力，而是DDD对人的要求实在太高：既要懂业务建模，又要懂代码设计，还得在任何一次需求变更中坚持架构约束。脑力一跟不上，架构马上就漂移了。
最近我在折腾AI编程工作流的时候，接触到一个很有意思的东西：cleanddd-skills。说白了，它是一套给AI Agent用的"DDD技能包"，让大模型在写代码时不再是机械地生成CRUD，而是被规则约束着，按DDD的战术模式去产出代码。这篇文章就把我对它的理解、实际折腾过程和踩过的坑完整写出来，希望对那些想用AI辅助做领域建模、又怕AI把代码写成一坨屎的团队有帮助。
这个思路解决的是实打实的痛点：AI写代码确实快，但它没有架构贞操感，你如果不约束它，它默认就会生成Controller + Service + Mapper三件套，跟你聊再多DDD也没用。cleanddd-skills做的事，就是给AI装上一套"DDD岗位职责说明书"。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
1. DDD落地难的本质：不是概念不行，而是缺少可执行的工程约束
1.1 建模会议开完，代码是另一套
很多人把DDD落地难归咎于概念抽象，比如实体和值对象的边界如何界定、聚合多大算合适、事件风暴怎么组织。但根据我的观察，真正的崩塌点不在这里，而是在"建模结论迁往代码"的这个过程。事件风暴产出了一大面便利贴，领域专家拍板了核心子域怎么划分，架构师画好了限界上下文关系图——然后呢？回到工位上，从Controller开始写，写着写着就回到老路了。
原因在于，DDD的建模产物和工程代码之间存在一条巨大的翻译鸿沟。领域专家表达的是"订单可以包含多个商品项，每个商品项有自己的快照价格和数量"，但Java代码要用什么组件承载这个结论？是Order聚合根里放List<OrderItem>，还是直接在订单Service里用List<Map<String, Object>>传参？如果没有人持续做这种"翻译决策"，开发人员靠直觉写代码的结果，绝大多数情况下就是贫血模型+万能Service。
贫血模型不是说不能跑，而是在业务复杂到一定程度后，业务规则散落在各个Service方法中，同一个规则在不同地方有不同实现，改一个校验逻辑要翻遍五六个类。我见过最夸张的例子，一个订单取消的状态校验逻辑被复制到了三个不同的Service里，其中两处已经因为业务迭代而语义不一致了。架构腐化从来不是一夜之间发生的，它就是每次"先这样写，下次再重构"累积出来的。
1.2 传统代码生成器为什么解决不了
既然人是不可靠的，那用工具来约束行不行？很多人已经试过代码生成器。MyBatis Generator、JHipster、以及各色低代码平台，我都见过团队尝试。它们能解决的是"通用CRUD层的机械劳动问题"，但解决不了"业务规则在不同层之间的正确分配问题"。
打个比方，代码生成器像是一台只能做指定款式家具的木工机床——你调好参数，它能又快又准确地切出抽屉和挡板。但如果这批次家具需要根据每个用户的房型定制，尺寸和结构每次都不一样，机床就无能为力了。DDD恰恰是这种高度定制化的活儿：每个聚合的边界、仓储接口的方法语义、应用服务对事务边界的组织方式，都依赖具体业务场景，不可能靠一套固定模板穷举。
更麻烦的是，代码生成器产出的代码是一次性的。项目一旦进入持续迭代，需求变了，结构自然跟着改。生成器没有办法感知你后面的手工改动，于是它生成的代码和手工代码逐渐分叉，最后没人敢再碰那个生成按钮。DDD需要的是"持续的结构守护"，而不是"一次性的代码生成"。
1.3 AI编程时代，问题的解法变了一个维度
大模型编程工具的出现，让这个死局出现了松动。AI写代码的本质不是模板填充，而是"在给定上下文条件下进行概率化生成"。它完全可以生成符合DDD风格的分层代码，前提是它的上下文里被注入了足够强的DDD约束规则。
但没有约束的AI，默认写出来的东西极其"泥石流"。你让它实现一个订单创建功能，它会非常贴心地生成OrderController、OrderService、OrderMapper、OrderDO，然后在OrderService里完成所有的状态流转和金额计算。如果你在提示词里写下"请用DDD实现"，它确实会给出domain、application、infrastructure这样的包名，但你细看代码就会发现——它只是把Service改名成了ApplicationService，业务规则仍然写在一个个方法里，实体依然没有行为。这就是典型的"挂着DDD的羊头，卖着三层架构的狗肉"。
cleanddd-skills这个技能包的思路，恰好是针对这个现象来的。它想解决的问题不是"提高AI代码生成速度"，而是"保证AI在一套指定代码架构约束下进行生成"。
2. cleanddd-skills到底是什么：给AI塞进一份"DDD岗位说明书"
2.1 它不是框架，不是模板，是一种Agent技能定义
先说清楚一个容易混淆的概念：cleanddd-