AI Agent驱动DDD落地：从事件建模到聚合根代码生成

我去一家做供应链系统的公司做技术交流，对方架构师上来第一句话就是：“DDD我们提了三年，代码里一个聚合根都没见到。”我当时就笑了，因为太熟悉了。DDD这东西，在圈子里几乎是“正确”的代名词，谁都说好，谁都想上，结果十有八九倒在半路。问题从来不在理念，而在落地：领域模型怎么挖？聚合边界怎么划？一堆领域专家坐在一起，讨论三天能出个大概，但一回到代码里，模型就变形了。直到我把AI Agent引入建模和编码流程之后，才真正找到一条让DDD从PPT走进代码仓库的路子。这个思路我整理成了cleanddd-skills——一个把AI当作领域建模助手和代码生成器来驱动DDD落地的实践集合。

所谓cleanddd-skills，简单说，就是让AI扮演“懂DDD的咨询顾问”，通过结构化指令把建模过程拆成可执行的步骤，从业务事件梳理一直干到聚合根、领域服务、应用层的骨架代码生成。如果你正被DDD落地折磨，或者你已经在用Cursor这类AI编程工具但不知道怎么把设计方法论塞进去，这篇文章会给你一套能直接抄作业的完整方案。

1. DDD为什么总是卡在落地上？先搞清真正的病根

1.1 不是你不会写代码，是建模和编码之间的鸿沟太大

DDD全称是Domain-Driven Design，翻译过来是领域驱动设计。核心思想并不复杂：软件的本质是解决业务问题，所以代码结构应该以业务领域的模型为核心，而不是以技术实现为核心。这话听起来特别对，几乎没人反对。但真做起来，尴尬就出现了。

我见过太多团队，启动会上热血沸腾，画了一堆事件风暴的便签纸，贴在墙上非常壮观。结果到了写代码的时候，谁也不敢确定这个聚合根该包含哪些实体，那个值对象到底是独立成类还是干脆用个String算了。最后的结果就是，架构师拍脑袋定一版，开发闷头写，写完之后发现跟当初的白板模型完全是两个东西。

这里面的病根，我总结下来有三条。第一，领域建模本身是高熵活动——它需要同时理解业务规则、系统边界、未来扩展方向，信息量极大，人类短时间处理不过来。第二，建模结果到代码之间缺少“翻译机制”，即使白板上的模型是对的，落到Java或TypeScript里也会因人而异地走样。第三，DDD的学习曲线陡，团队里真正能把战术建模玩明白的人少之又少，大多数人是“听过大词、没动过手”。

1.2 传统DDD落地路径：事件风暴到代码的断裂带

传统路径通常是这样的：先组织业务人员和开发团队做事件风暴，把业务过程拆成一个个领域事件，比如“订单已提交”“库存已扣减”。然后对事件做归类，划分出不同的限界上下文，再在上下文内部找聚合、实体、值对象。这些活动做完，产出物通常是一堆白板照片和几页Word文档。

问题就出在这个环节。白板上的模型要变成代码，中间需要有人做一次极高难度的“设计决策翻译”。举个例子，白板上写着“订单聚合包含订单项，订单项引用商品快照”，但到了代码里，订单项到底是用实体还是值对象？商品快照要不要单独建表？订单聚合的仓储接口该返回什么粒度？这些问题，白板上根本不会写。于是每个开发都有自己的理解，十个开发能写出八种不同的“DDD实现”。

再加上文档和代码天然会漂移——模型更新了，文档往往还是旧的。时间一长，代码就成了唯一事实来源，而代码里DDD的影子早就淡到看不见了。这就是我见过的“DDD三年没落地”的真正原因。

1.3 AI为什么能解决这个问题？它补上的是“翻译层”

如果让我用一句话概括cleanddd-skills的底层逻辑，那就是：用AI的能力来填补建模决策到代码生成之间的那个巨大空隙。

先不要神化AI。它不是上来就替你建模的，而是当你有初步认知后，它负责把DDD方法论里那些高度依赖经验和判断的操作，变成程序化的、可执行的工序。比如事件风暴之后，你可能只有十几个领域事件的名字。传统做法是组织专家开两天会去划聚合边界，现在你可以把事件列表喂给AI，让它基于你预设的规则（比如“同一聚合内对象变更必须一致提交”）推荐候选聚合，并给出划分理由。AI再强，也不可能比老业务专家更了解业务，但它有一个巨大优势——对DDD规则的理解极其稳定，不会累，不会烦，不会把聚合根写串。

更重要的是，一旦AI参与建模，它输出的模型产物是结构化的。结构化意味着可以直接映射成代码框架，不再需要人工“翻译”。这个特性，才是cleanddd-skills真正咬合DDD困局的关键点。

2. cleanddd-skills到底是个什么？一次把概念讲透

2.1 先理解Skill这个概念：它比Prompt更进一步

如果你用过Cursor或者类似的AI编程工具，你多半有过这种体验：在对话框里写“帮我生成一个订单模块”，AI确实给你生成了一堆代码，但结构稀烂，既没有清晰的层划分，也没有领域模型的味道。问题出在哪？出在你的指令只有“目标”，没有“方法论约束”。

Skill这个概念，就是为了解决这个问题出现的。它不是单一的一句话Prompt，而是一套可复用的结构化指令包——里面包含了角色设定、处理流程、约束规则、输出模板，有时候还会带上少量示例。你可以把它理解成给AI装了一套前置知识系统。它让AI不仅仅知道“你要什么”，还知道“按什么方法论去达成”。

cleanddd-skills就是这样一组专门为DDD服务的Skill集合。打个比方，如果你把AI当成一个刚毕业的聪明程序员，它确实聪明，但它不知道你们团队的建模规范、不知道聚合怎么划分、不知道代码目录应该长什么样。cleanddd-skills就是一本把这套规范写好的员工手册，AI照着这本手册去思考、去提问、去产出，出来的东西自然就带着DDD的味道了。

2.2 cleanddd-skills的核心组成：一个完整的DDD工作台

光说概念不够，具体看内容。我把这套Skill拆成几个部分，各自负责DDD落地流程中的一个环节，合在一起就形成了一条从业务探索到代码生成的流水线。

第一个模块，是“业务事件梳理助手”。这个模块的作用是帮你从一段业务描述或者一堆会议纪要中，提取出领域事件、命令、外部依赖这些要素。实际操作中特别有用，因为你不可能天天约业务专家聊，但你可以把访谈录音转成文字，扔给这个模块做初筛，它能把对话里的业务过程自动抽成结构化事件流。

第二个模块，是“聚合与限界上下文划分助手”。这是整个SKILL里最有技术含量的部分，它要求AI基于你输入的事件流和业务规则，识别聚合边界，判断聚合根归属，找出值对象。它会主动向你提问，比如“订单提交时是否需要同时校验库存？”这类澄清性追问，问完才给出聚合设计。

第三个模块，是“六边形架构代码生成助手”。AI在这个环节只会把前面确认好的模型转成代码框架，但它不是一把梭哈全部生成，而是按层按模块一步步来，每生成一部分就停下来给你看，确认无误再接下一步。这种模式，比一次性生成两千行代码的体验好太多了，你随时能纠偏。

这三个模块配合使用，基本覆盖了我个人实操中最常走的DDD落地路径。下面就把这条路径完整走一遍。

3. 用cleanddd-skills实操一次：从业务描述到DDD骨架代码

3.1 前期的场景设定与技术栈选择

先定场景。假设我们要做一个零售积分系统，核心业务包括：用户下单获得积分、积分兑换商品、积分过期清零。这是一个非常适合演示DDD的领域，因为它有清晰的状态流转、有跨聚合的一致性需求（比如下单和积分增加），又不像电商订单那种巨复杂的体系难以上手。

技术栈我这边选的是Spring Boot 3加Java 17，这是目前国内后端最主流的组合。但需要说清楚，cleanddd-skills本身跟语言和框架无关，核心在于它输出的模型决策是通用的，换成TypeScript加NestJS也一样能跑通。选择Spring Boot，纯粹是因为团队熟、生态好，代码生成出来后大家能直接看懂。

把这套Skill装进编辑器的时候，我用的是Cursor的rules方式，但其实Claude Code和通义灵码这类工具的Skill机制也都能兼容。关键并不在于哪个工具，而在于你有没有把DDD的约束规则系统性地表达给AI。

3.2 第一步：用AI做事件梳理，把业务描述变成事件流

实操第一步，是把业务描述扔给“业务事件梳理助手”。这里我强烈建议不要直接丢一句“帮我分析积分系统”，信息量太少了，AI并不知道你真实复杂的业务环境，只会给出一堆教科书式泛泛答案。

我给团队示范的输入是这样的：

text复制领域背景：零售积分系统，用户在门店消费后根据实付金额累积积分，积分可以用来兑换商品。
业务过程：用户买单后，系统根据订单金额计算积分并放入用户账户；用户可以在积分商城里浏览可兑换商品并提交兑换申请；兑换申请提交后，先冻结对应积分，库存确认后扣减积分并发放兑换商品；如果库存不足，取消冻结。积分有一个过期时间，通常是次年年底统一清零。
请基于以上描述提取领域事件、命令，并识别其中的业务不变量（关键业务规则）。

注意我做了什么操作：我给的已经是一个初步加工的流程描述，而不是原始录音。这个步骤很关键，AI虽然能处理原始材料，但如果你先帮它理一遍大框架，它产出的事件流质量会高一个档次。大概几十秒后，AI返回了一组结构化输出，包括“订单已支付”“积分已计入账户”“兑换申请已提交”“积分已冻结”等十几个领域事件，同时也识别出了两条业务不变量：一条是“积分冻结期间不能被清零”，另一条是“账户积分总余额不能为负”。

正是这最后两条不变量，在后面划分聚合边界的时候起到了决定性作用。

3.3 第二步：聚合建模——AI的追问比它的答案更值钱

拿到事件流之后，进入第二个模块：聚合划分。这个环节我把刚才的事件流和不变量一起输入，让AI给出候选聚合设计。但有意思的是，AI并没有直接给答案，而是先反问了我几个问题。

比如它问：“积分冻结是由兑换上下文操作，还是由账户上下文内部操作？”这个问题的本质是在确认限界上下文的边界——如果积分冻结逻辑归兑换流程管，那积分账户的可用余额变更就必须通过应用服务协调；如果积分冻结是账户内部行为，那聚合边界就可以划得更大一些。

它还问了：“订单模块是否存在且已经落地？”因为如果订单系统已经存在并且不同团队维护，那积分系统面对订单就只能做一个理性的事件监听者，而不是跨系统去改订单状态。

这个阶段我特别想强调一点：很多人用AI建模，价值感最强的环节是在“答案”上，但我自己的体感恰恰相反。AI的追问才是它真正帮你梳理思路的地方，它的框架是完整且可持续的。你回答问题的时候，会发现自己原本很多模糊不清的判断被迫变得明确，这就是高质量的推进。

几次澄清之后，AI给出了聚合划分：一个“积分账户聚合”，负责余额变动和过期清零，保护业务不变量“余额不为负”；一个“兑换记录聚合”，负责整个兑换流程，内部状态机覆盖从提交到完成或取消。这两个聚合的边界清晰，彼此通过应用服务通信，完全符合战术建模里“事务只在一个聚合内”的原则。

3.4 第三步：骨架代码生成——按层渐进式输出，不搞一口吃成胖子

模型确认之后，进入代码生成。我第一次跑这一步时犯过一个错，就是图省事，让AI一次性把整个项目生成出来。结果AI确实生成了，但导出之后发现大量import不存在、循环依赖、代码风格完全不统一，改起来比从头写还痛苦。

后来我调整了姿势：按层生成，每层确认后再进入下一层。现在我在SKILL里固化了下述顺序：

先让AI生成领域层，包括聚合根实体、值对象、领域事件定义。这个层是整个DDD的核心，值得花最多精力去核对。我的要求是，实体必须包含状态流转的领域方法，比如“积分冻结”不能只是set一个字段，而必须是一个内聚了业务规则的freeze()方法。

然后是应用层，主要是应用服务与命令处理器。这一层扮演的是流程编排角色，它负责协调聚合和基础设施，但不承载业务规则。我盯它时的重点在于检查事务边界：命令处理器的服务方法会不会把两个聚合的状态变更包进同一个事务里？如果包了，就得改回去。

最后是基础设施层，也就是仓储实现、消息发送、外部接口适配这些偏技术的部分。这个层面比较机械，AI出错率低，可以适当放宽生成速度。

整条链路走完，大概二十分钟到半小时。比起传统方式里两三个人花一周推导加编码，这个速度已经是另一个量级了。

3.5 生成后的必经之路：人工审查清单和模型修正

这里我必须坦诚：代码生成不是终点。AI生成出来的聚合和代码结构，大方向合格，但细节上仍然可能出现让你皱眉的情况。比如我遇到过一次，AI把积分账户聚合里的“积分明细”设计成了一个List实体集合，每次变更都全量加载。这个设计在小流量下没问题，但真要面对高并发场景，就是性能灾难。

正确的修复应该是把积分明细设计成单独的数据库表，聚合只维护当前有效余额，并在需要时读取分页的明细记录。这种“经验型决策”AI做不好，因为它缺少对生产环境流量的直觉，需要人来兜底。

所以我在团队里立了一个规矩：AI生成代码后，至少要过一个资深开发的人工审查。审查的重点不是代码风格，而是聚合边界是否合理，事务范围是否收敛，业务不变量是否被完整封装。审查完了，把修改意见直接反馈给AI，它会根据反馈更新已有的设计文档和代码。这个反馈闭环用起来出奇地顺手，因为AI没有面子包袱，你让它改，它立刻改。

4. 避坑手册：实测cleanddd-skills时遇到的典型问题

4.1 问题一：AI生成的聚合边界总被外部依赖带偏

我实际跑的时候发现一个高频问题，AI特别容易根据外部系统给它看到的接口来反推聚合设计。举个例子，在积分兑换流程里，它需要对接库存系统。因为库存系统提供了一个“预占库存”的接口，AI就倾向于把这个调用动作直接内聚进兑换聚合的领域方法里，让领域层直接依赖了外部系统。

这个设计放到DDD框架里是有问题的，会让领域模型被外部实现绑架。领域层的核心逻辑应该保持纯粹，仓储出口是外部基础设施，而防腐层（Anti-Corruption Layer）应该接住网关防腐层的责任，在应用层或独立模块里做适配。一旦领域层出现import一个rpc client的情况，方向就全错了。

我的排查经验是，在审查阶段专门盯AI生成代码里实体类的方法签名。如果一个领域方法里有明显的调用外部服务的语句，就追着这条链路去找，基本能快速定位出防腐层位置的偏差。发现问题后，不要只是让AI改一行代码，而是让它把领域层和应用层的职责重新梳理一遍再让你审，这样它才能真正修正。

4.2 问题二：AI在一致性边界上的理解飘忽不定

DDD里有一条红线：一个事务只操作一个聚合。这条规则AI有时就执行得很随心所欲。比如在生成兑换服务时，有一次生成的代码直接成功踩雷，在同一个事务方法里同时调用了积分账户聚合的冻结方法和兑换记录的创建方法。单体应用下事务或许能勉强看到行为正确，但这在架构上其实是个错误的信号。

为什么这条规则这么重要？因为一旦两个聚合的事务被强行绑在一起，就破坏了独立的业务生命周期边界，将来分库分表或引入微服务时，这些地方就会变成分布式事务的炸弹。正确做法是两个聚合各自独立提交，通过领域事件做最终一致性，积分冻结成功事件驱动兑换记录的推进。

排查的方式是翻Application Service的类，看它方法上有没有直接跨聚合操作。只要我看到两个不同的仓储接口在同一个方法里被调用，并且各自承载了独立的状态变更，就会条件反射式地标记出来，要求AI给出两个方案让团队决策：是改成事件驱动的最终一致性，还是确实可以做本地事务处理。这个决策不能跳过。

4.3 问题三：依赖注入方向搞反，Controller直连仓储

这个是新手团队最灾难性的问题，AI生成的Controller层代码非常喜欢直接把OrderRepository接进来做查询，抛开了用例层的应用服务角色，将领域层直接暴露给外部。短看确实省几行代码，代码能跑、测试能过，但维护三个月后，当领域逻辑开始复杂之后，你就会发现大量的查询和操作逻辑散落在Controller里，聚合根的存在感几乎为零。

解决这个问题的土办法，也是在SKILL里加了一条铁律：外部输入必须穿过Input Port也就是应用服务接口，才能触达领域层。我让AI每一次生成Controller之前，都先自报一遍依赖链，从Controller到Application Service再到Domain Repository，直到链路是完整的方可生成代码。

其实这背后有一个更值得思考的点，就是AI工具好不好用，取决于你给的约束是否明确。在我的实践里，把类似“依赖方向必须单向”这样的规则写进Skill描述里，AI的输出质量会立刻上一个台阶。

4.4 问题四：业务规则只存在于注释里，没有落进方法

这个更隐蔽。有一次我检查AI生成的积分过期清零逻辑，发现代码倒是挺干净，但表达式判断直接写在了Service层，代码注释里写着“如果积分过期时间小于当前时间则清零”。实际上这个业务规则应该是一种领域表达，业务上是“积分已过期”，它就应该是积分聚合上的一个状态判断方法，语义和源码完全对齐才正确。

规则放错位置的后果是，将来业务语义变化时，你得去应用层翻逻辑，而不是在领域模型里找到它。时间一长，那些藏在Service层某行很难说清楚来源的业务规则，都会成为大坑。

我现在培训团队时的做法是复查清单：如果看到Service方法里有一堆if-else且条件里带着日期计算、金额判断这类业务词汇，就要求团队成员重构，把逻辑移动到聚合根的内部方法里去。这么做的核心目标，不是代码结构好看，是为了业务变化的收敛足够可控。

4.5 一张表总结：常见问题、原因与对策

5. Skill是“活”的：把团队经验和规范持续反哺给AI

5.1 搭建团队级别的SKILL沉淀库

这里聊一个很多人忽略的进化问题：SKILL是一次性的还是长期积累的？答案是，它必须像代码库一样被长期维护。

我第一次跑通这套流程后，生成的代码虽然骨架齐全，但一眼就能看出它没有我们团队的独特约定。比方说，我们要求聚合根必须有业务标识字段，值对象必须实现equals和hashCode，应用服务不能包含任何事务注解，这些约束散落在代码规范文档里，AI一开始并不知道。

后来我把这个“注入认知”的动作做在了前面，把这些约束直接写进了SKILL中，系统化的code review意见也被我持续追加到版本库。持续沉淀三个月后，SKILL的输出质量已经提高到一个新水平，骨干开发者都明显感受到AI生成代码里符合团队约定的比例大幅上升了。现在它已经能主动问“这个值对象是否需要实现自定义相等性比较”，而不是每一条都靠你事无巨细地去纠正。

5.2 定期复盘：让AI参与它自己的改进迭代

我们团队现在每两个星期做一次SKILL迭代复盘，固定动作是把最近两周的code review意见汇总，提炼出重复出现的问题，更新到SKILL规则里。做这个复盘的动作，意外养成了一个好的副产品——团队开始愿意更细致地复盘Review意见，因为每一条真实教训都被沉淀为结构化认知，之后就不再是空泛的“下次注意风格”了。

对这个过程，我的强烈建议是最好指定一个轮值维护人。因为SKILL维护其实是一个非常灵活的写作加规则提炼工作，如果变成全团队无主状态，几天就会停滞。而有了轮值机制，每个人都能从“输出代码”的位置，转去理解“定义规范”的位置，成长速度很明显不同。

5.3 不只是代码生成：SKILL还能驱动文档和模型同步更新

DDD落地经常还有一个痛，就是代码跟文档脱节。但在我们的工作流里，这个问题已经自然缓解了。因为AI在生成代码的同时。也能同步输出一套基于模型决策的架构说明文档，包括聚合关系描述、业务不变量清单、关键流程时序这些。文档是它生成的，它再生成代码的时候，天然就知道这套模型长什么样。

每次模型变更后，AI也能基于变更内容更新对应的说明文档，文档和代码的漂移就再也没有大到失控过。我特别推荐你复制这种工作模式，要求AI在每次代码变更的同时更新文档片段，而不是等周末补文档。这样做的好处是，PR（代码评审）描述里自带模型变更说明，评审人看代码时可以同步理解设计意图。

6. 一点个人体会：工具永远只能替你干活，替不了你做决定

整套cleanddd-skills体系用了快半年，最深的感受是：DDD落地的瓶颈从来不是工具，而是方法、工具和人的协作流程。AI确实强大，它最大的价值是把那些重复性高、方法论明确但靠人做容易遗漏的动作接了过去，比如持续的规则校验、一致性的代码生成、标准语义的输出。但我们自己也必须做好关键决策：聚合边界的最终确认、业务规则的调整、目录结构风格的决定，这些只有人类能够理解上下文并承担责任。

这几年我越来越强烈地感觉到，AI在软件开发里的最佳打开方式，其实不是交给它一个巨大的目标让它自由发挥，而是把它放进一套有约束的行事规则里，像对待一个高执行力但经验不足的伙伴一样，给它标准、给它流程、给它反馈。它慢慢成为团队的稳定层，而专家们把有限的精力聚焦到真正值得投入设计和判断力的地方。

如果你也是那种“DDD喊了半年还在画图”的人，我建议你今天就可以试一次：选一小块业务，用SKILL的方式让AI带你走完整条建模与编码链路。跑通一次之后，你会回来感谢这个思路的——因为你会发现DDD这东西，原来真的可以被一架不知疲倦的机器推着往前走。