1. DDD的落地上帝已死痛点到底在哪先聊个真实场景。我见过不少团队花了两三千块钱去上 DDD 培训课回来每个人都信心满满觉得终于找到了应对复杂业务系统的银弹。结果呢一个月后打开代码仓库还是老样子Controller 里写满业务逻辑Service 层化身 God Class所谓领域模型就是一堆只有 getter/setter 的 POJO。这真不是这帮程序员偷懒。我接触过的团队里DDD 落地失败率极高而且往往越认真学过的团队挫败感越强。原因很简单DDD 的理论体系看起来不复杂可真要落下去中间隔着太多“只可意会不可言传”的东西。1.1 领域建模时技术出身的团队最容易翻车做技术的人有个思维惯性看到需求第一反应是表结构怎么设计、接口怎么定义、状态流转怎么实现。但 DDD 的第一步是拒绝这种思维要求你先用业务语言聊天把领域术语对齐。光是这一步就能卡死一票团队。举个例子。一次项目里业务方管“取消订单”叫“退单”运营文档里写的是“作废”老系统代码里叫“closeOrder”。这些名词背后其实是同一个业务动作但团队里三个人开会能说出三个词导致后面领域模型里头概念全是乱的。这还只是命名对齐更别说判断某个行为到底该放在哪个聚合里、哪些业务规则属于不变量这种高端操作了。1.2 架构分层和编码落地之间的鸿沟教科书告诉你 DDD 分四层接口层、应用层、领域层、基础设施层。但没人告诉你边界画完之后落成代码时每一层该写什么、不该写什么。聚合根、实体、值对象、领域服务、仓储、防腐层……每一个战术模式在实战里都有十几个“这样的话要不要这么写”的判断点。我说个最典型的痛点。很多团队建模阶段画了一堆漂亮的聚合关系图到了写代码时发现不知道聚合根之间怎么关联。有的直接懒省事用仓库跨聚合查数据结果聚合边界形同虚设有的过度设计一个简单需求硬拆五个微服务。这些决策书上只给原则不给答案。1.3 一个标准的 DDD 落地最低需要多少步别觉得夸张我把一套完整的 DDD 落地流程拆开给大家看事件风暴2~3 天拉上业务方和技术方贴满一整面便利贴划分限界上下文确定上下文映射关系识别聚合、实体、值对象、领域事件设计仓储接口、领域服务、应用服务编写防腐层和适配器代码骨架落地把模型翻译成实际的类、方法、依赖方向持续重构每次变更都要检查模型是否腐化这套流程走下来动辄好几周。问题来了前面六步真的是只有人类才能做的事吗我现在的答案已经变了不是。而且很多步骤AI做得比人快得多。这也是我为什么要写这篇介绍——我把一套专门给 AI 用的 DDD 技能包cleanddd-skills折腾了出来用来专门干“DDD 从概念到代码”这摊最脏最累的翻译活。下面我详细说它是什么、能做什么、怎么用。2. cleanddd-skills是什么它不是AI框架是一套AI的DDD大脑先说结论cleanddd-skills不是一个像 Spring Boot 那样的代码框架而是一大套精心编排过的AI Skills技能包。你可以把它理解成“给 AI 加载的领域驱动设计外挂”。2.1 项目的定位与上手指南目前各类 AI 编程工具Claude、ChatGPT 的项目/知识库、Codex 的自定义指令、甚至通义灵码之流的提示词工程都开始支持 Skills 机制。所谓 Skills本质上就是一组结构化的提示词和规则文件告诉 AI 遇到什么任务时按什么流程走、输出时遵守什么格式、完成后要自查哪些质检点。cleanddd-skills干的事情就是把从事件风暴到代码落地的整套 DDD 方法论拆解成几十个按顺序触发的 Skill 文件。你不再需要跟 AI 废话“请你扮演一个 DDD 专家……”这种弱爆的提示词而是直接把对应 Skill 加载进去AI 就会自动进入“DDD 实施顾问”或者“事件风暴引导师”的角色按标准动作执行。上手路径很简单把仓库克隆下来把skills/目录下的文件拷到你的 AI 工具知识目录里按项目需要在对话开始时 对应的 skill不同工具触发方式不太一样本质就是让 AI 读取指令然后把你手里的业务描述、需求文档甚至是一段脏兮兮的老代码丢给它流程就转起来了2.2 Skill/提示词集的核心构成我按 DDD 的工作流把这套技能包分成了四大模块每个模块里面挂了一堆粒度更细的 Skill模块覆盖环节包含的Skill示例战略设计事件风暴、限界上下文、统一语言event-storming-guide、bounded-context-divider、ubiquitous-language-miner战术设计聚合划分、实体/值对象识别、领域事件定义aggregate-design、value-object-detector、domain-event-describer编码落地分层骨架、依赖方向、防腐层接口、仓储模式layered-architecture-generator、anti-corruption-layer-builder、repository-contract-generator评审重构贫血模型诊断、模型腐化识别、代码评审anemic-model-detector、domain-model-rot-scanner每个 Skill 文件内部包含了任务定义、输入要求、输出格式、质检点四块内容。任务定义告诉 AI 它当前扮演的角色和职责输入要求规定了它开始干活前必须要向你要哪些材料输出格式则强制它把结果按可评估的模板输出——比如事件风暴的产出必须是一张结构化的事件-命令-阅读模型表质检点是最后让它自查的清单防止它一本正经地胡编。这里我说一个设计理念我不是让 AI“生成一段关于订单的 DDD 示例代码”而是让 AI 严格按 DDD 流程从业务事实出发逐步推导出模型。区别在于前者是幻觉重灾区后者有输入约束和逻辑链条过程可以被回溯。这一点对后续实操非常关键因为 AI 一旦跑偏你能从它的推理链里快速定位是哪一步出了问题。3. 用AI按DDD标准重新走一遍建模流程这一部分我拿一个实际场景完整走一遍这套 Skill 包的用法。我用的例子是一个电商订单系统的子模块业务描述就三句话“用户下单后系统要锁定库存支付完成生成出库单如果超时未支付订单自动取消并释放库存。”这套流程如果你让一个初级开发来推 DDD 模型大概率会推出一堆奇怪的东西。我们看看 AI 按 Skill 包会怎么处理。3.1 从业务描述到事件风暴加载event-storming-guideSkill 后我把上面那段业务描述丢给 AI然后给它一个命令“按事件风暴流程完善这个流程可能涉及的事件、命令和角色。”AI 的产出逻辑很有意思。它不会直接给我一张表而是先反过来向我确认问题库存锁定是由哪个系统触发、超时未支付的时间窗口是业务规则还是技术配置、用户取消订单和系统自动取消是否走同一个命令……这一步让我很惊喜它把“事件风暴引导师”该做的业务澄清动作做出来了。我补了几个信息后AI 输出了这样一张表类型名称触发方/角色备注命令CreateOrderCommand用户创建订单命令LockInventoryCommand订单服务锁定库存命令MarkOrderPaidCommand支付网关回调支付成功命令CancelOrderCommand用户/系统定时器取消订单领域事件OrderCreated订单服务触发库存锁定领域事件InventoryLocked库存服务锁定成功后发出领域事件OrderPaid订单服务触发生成出库单领域事件OrderCancelled订单服务触发释放库存阅读模型OrderDetail查询端订单详情展示这张表不能说全对但已经达到了一个中级架构师做事件风暴的第一轮产出水平。它还额外标注了哪些事件与聚合之间的时序关系这为下一步做聚合划分提供了原材料。3.2 从事件风暴到聚合划分聚合划分是 DDD 战术设计里最考功力的环节因为它没有唯一正确答案只有“当时看合不合理”的设计权衡。aggregate-designSkill 在拿到上面的事件表后会先列出候选对象订单、库存单、出库单、支付单。然后它做了一件书上会写但不告诉你细节的事——逐个分析业务不变量invariant。比如“锁定库存”这个动作。AI 会问锁定失败时订单还能不能创建超时释放库存和手动取消释放库存会不会发生并发如果订单取消和支付成功几乎同时发生系统该怎么保证一致性这些追问把聚合间的一致性边界给逼了出来。最后 AI 给出的划分建议是Order聚合聚合根为订单包含订单项、收货地址、支付状态、订单状态Inventory聚合聚合根为库存项独立管理锁定数量Outbox聚合负责消息可靠投递记录领域事件其中“订单取消时验证是否已支付”这个业务规则被划到了订单聚合内因为这是订单自身的状态一致性边界而“库存锁定数量”则是独立的不变量绝对不能放进订单聚合否则一旦出现并发会导致超卖——这个判断逻辑被 AI 明确列了出来而不是黑箱输出。这点很关键因为就算你不同意 AI 的划分你也能看到它划分的依据然后和人讨论。3.3 从聚合到限界上下文拿到聚合模型后bounded-context-dividerSkill 开始工作。它会依据“聚合不要跨界”“语言要统一”“事务边界要清晰”这几个标准去划分限界上下文并生成上下文映射图。上文那个电商子域AI 给出了这样的判断订单聚合和库存聚合虽然都出现在“下单”这个业务场景里但它们分属不同的限界上下文——订单上下文和库存上下文。二者通过领域事件InventoryLocked/InventoryReleased解耦而不是直接调用各自仓储。它在两个上下文之间生成了一段防腐层接口描述InventoryGateway并标注实现可以是 Feign 接口调用、MQ 消息、或者本地进程内事件这取决于部署形态。到这里战略设计阶段的产出已经可控。AI 甚至额外提示了上下文映射类型订单上下文和库存上下文是“防腐层 合作者”模式库存作为下游系统契约稳定性要求极高。我把这些结果发给团队里的资深架构师看他说了一句“这套输出已经达到了我带三年的初中级架构师独立完成的水平而且速度真的快。4. AI辅助落地的三个最实用场景模型设计得再漂亮最终要落到能跑的代码里。这一章节我挑三个我日常用 AI 辅助 DDD 落地最频繁的场景每个都是可以直接抄作业的。4.1 生成分层骨架代码含示例建模完成后layered-architecture-generatorSkill 会把我们前两步的产出翻译成一个符合 DDD 分层架构的代码骨架。我特意选了 Java 技术栈DDD 在 JVM 生态里的工具链最成熟拿上面订单上下文的部分契约举例。第一轮AI 直接生成了如下几个核心类// 领域层 - 聚合根 public class Order { private OrderId id; private ListOrderLine lines; private OrderStatus status; // 领域行为取消订单 public void cancel(OrderCancelPolicy policy) { if (this.status.isPaid()) { throw new OrderAlreadyPaidException(已支付订单不可取消); } if (!policy.canCancel(this)) { throw new OrderNotCancellableException(订单当前状态不允许取消); } this.status OrderStatus.CANCELLED; this.addDomainEvent(new OrderCancelled(id, lines)); } // 领域行为标记支付成功 public void markPaid() { if (this.status ! OrderStatus.AWAITING_PAYMENT) { throw new IllegalStateException(订单当前状态无法支付); } this.status OrderStatus.PAID; this.addDomainEvent(new OrderPaid(id)); } }看到这个骨架我的第一反应是它至少没有犯新手最常犯的错。每个业务动作都写在聚合根上、状态变更必须从方法进入、领域事件在状态变化时触发。这个代码可以直接作为代码评审的基线。这里我也明确提醒一句AI 生成的骨架代码只能作为设计蓝图的代码化表达不是可以无脑跑到线上的东西。事务边界、并发控制、消息可靠性这些基础设施问题它给的往往偏简化需要团队自己补强。但它帮我们省掉了从“空目录”到“分层包结构 核心领域对象”的半天时间。4.2 现有代码的DDD化重构建议第二个场景更常遇到——老系统改造。我给 AI 丢了一个典型的“贫血模型上帝服务”类让它做 DDD 化诊断。初始代码是一个写满了订单逻辑的OrderService里面包含了价格计算、库存校验、优惠券使用、物流单生成等十几个方法。anemic-model-detectorSkill 工作方式不是直接给我一版正确的代码而是先出一份“病灶清单”OrderService承担了本属于聚合根、领域服务、应用服务三层的职责Order实体沦为数据包无任何领域行为优惠券计算逻辑依赖外部服务未定义防腐层耦合过紧库存扣减直接调用仓储事务未显式表达最终一致性需求然后它给出了重构路径的建议顺序先抽领域服务PricingService→ 把订单状态流转收敛回聚合根 → 引入CouponGateway防腐层 → 最后再考虑代码级拆分。这里关键点在于顺序如果把防腐层改造放在最后前期的状态收敛还能小步提交如果顺序反了中间态代码会把整个团队逼疯。我在多个项目里验证过这个模式让 AI 先做“诊断”比直接让它“改给一版代码”可靠得多。因为诊断结果是给人做决策的而改动结果是需要人来承担后果的。4.3 持续评审让AI盯住防腐层DDD 项目最怕的其实是“慢慢腐烂”。上线没问题但每隔几次迭代就有新同学嫌跨限界上下文查数据太麻烦直接在应用服务里加了一个仓储查询把防腐层绕了过去。这种腐化靠代码评审人工查非常累因为每次 diff 都很大。domain-model-rot-scannerSkill 用起来就很简单。我在代码提交前把变更的 diff 文件扔给加载了该 Skill 的 AI并附一句指令“扫描本次变更检查是否存在跨限界上下文调用、聚合越界、行为泄漏到应用层。”实测下它检查出来的问题形形色色在OrderApplicationService里直接写过inventoryRepository.reduceStock()本该走InventoryGateway、在查询接口里直接拿了聚合内部状态来拼页面本该用阅读模型/查询模型、还有在实体上加了updateInventoryByOrderId()这种“反 DDD”的静态方法。当然AI 的评审结果和资深架构师相比判断精度还差一点会有误报、甚至漏报。但把它当作第一道自动化防线配合人工抽查效果非常明显。一个小团队每个月能少打十几场“这个责任该谁付”的扯皮仗。5. 实测中踩过的坑和需要注意的边界工具再顺坑还是有的。说实话AI 做 DDD 咨询的上限很高但下限也很低。如果使用者自己没有足够的判断力去和它对话AI 会一本正经地用非常流利的语言产出一堆华丽但错误的设计。我用这套技能包踩过几个坑专门拿出来说说。5.1 AI的DDD知识有方言问题你打开任何一篇讲 DDD 的文章可能都会说“聚合是一致性边界”但这句正确的废话到了不同的 AI 模型手里解释出来的差异极大。有的模型把聚合理解成“一组对象的集合”有的理解成“事务边界”有的甚至会认为“一个聚合只能有一个实体”。我遇到过最离谱的一次AI 在一个进销存系统里生成出了单个聚合包含“商品、库存、采购单、销售单”的巨型模型。它的理由是“这些都是围绕商品核心业务紧密关联的对象”。如果在团队讨论里出现这种设计肯定得被喷死。所以现在我使用这套技能包之前一定加一步热身对话先让 AI 讲出它对 DDD 里关键概念的定义比如“聚合根”“值对象”“防腐层”我会快速判断它跟主流 DDD 理解是否有偏差。如果偏差大先纠正它再来做正事。还有一个更隐蔽的问题AI 训练数据里的 DDD 案例大多是旧版企业应用架构对“现代微服务下 DDD 怎么和分布式事务协作”这类问题很多模型的回答是自相矛盾甚至过时的。这个锅不完全在 DDD 和 AI而是领域在不断演化。所以技能包中的提示词我特别加了“当前项目技术栈上下文”这一段要求 AI 在回答前先确认部署形态和技术栈降低“老案例套新场景”的风险。5.2 提示词不能一次到位怎么办你可能会发现第一次加载 Skill 包让 AI 输出结果不理想。这太正常了。这套技能包设计的是“多轮对话工作流”不是“一条提示词生成最终结果”的魔法。我的建议是遇到输出不对不要立刻否定 AI而是先让它解释推理链路。比如它把Inventory聚合划分错了你让它“说出你这样划分满足哪些业务不变量、依赖的是哪条领域规则”。它往往会在自我解释过程中发现自己忽略了某个业务约束然后主动修正模型。这个过程和人类设计师的“设计评审迭代”很像只是 AI 迭代一轮只需要几十秒。还有一种情况是 Skill 文件触发了但 AI 没有记住上下文。项目稍微大一点对话历史一长AI 就会“忘了”自己是在做 DDD 建模开始自由发挥。我的解决方法是在关键节点主动引用初始输入里已经确认过的模型契约用一句“继续按我们之前确认的Order聚合边界推进”把话题拉回来。一句话成本的投入能换来方向的大幅收敛。5.3 哪些步骤绝对不该交给AI虽然我把这套技能包描述得神通广大但下面这几件事我强烈建议永远不要让 AI 代替人来做业务规则的最终拍板。AI 可以帮你列出候选方案并分析利弊但“到底接受最终一致性还是强一致性”“库存不足时是阻断下单还是预占后通知”这类决策必须由业务负责人和技术负责人当面聊清楚AI 无法理解决策背后的组织政治和成本考量。大型架构方向选择。是引入 CQRS 还是保持传统 CRUD、要不要拆微服务、消息中间件选型——这些远超 DDD 范畴的问题靠 Skill 包硬套只会得到表面正确、实际错误的建议。合规与监管需求。金融、医疗等领域的审计要求、数据驻留政策、安全审计日志AI 在这些领域的“知识”往往缺乏时效性藏着合规风险。一句话总结用 AI 做“翻译”和“推断草稿”用人做“决策”和“审批”。这套分工在当前阶段最靠谱。你要是图省事把决策权也交给 AI那后来出的事就不是 AI 的锅了而是你自己的判断出了问题。6. 我个人的使用心得与后续玩法最后聊几句掏心窝子的话。我在实际使用中最大的感受是AI 把 DDD 落地最大的隐形门槛——从业务语言到代码语言的翻译成本——给降下来了。过去团队里只有少数能同时在业务会议室和白板前挥洒自如的技术骨干才能完成这种翻译。现在一个愿意动脑子、能拿主意的普通开发在 AI 的辅助下也能撸出一版及格的 DDD 设计初稿。当然这是辅助不是替代初稿质量大概在“可评审”级别还达不到“可直接拍板”级别但它至少让评审这事的参与门槛降了很多更多人可以围绕具体产出物发表意见了。关于落地节奏我的建议是从小处开始不要一上来就找个核心系统搞三个月大改造。选一个边缘但真实的业务模块花一两天把技能包跑通让团队看看 AI 的产出物长什么样、评审讨论怎么进行、代码怎么落下去。有了这个“样板间”再往核心业务推进阻力会小很多。顺带说一个我自己在用的扩展玩法。这套技能包不只是能服务 DDD它的编排思想可以平移到其他有标准作业流程的方法论上。比如我后来把自己团队的整洁架构落地规范也按照同样的模式做了一份技能包还做过一个给 AI 用的“微服务拆分决策引导包”核心就是把“固有方法论 团队实际情况”缝合成一套结构化指令让 AI 的能力被约束在团队认可的框架内输出。如果你现在正准备在一个项目里尝试 DDD或者正苦恼怎么让自己的团队从“学过 DDD”变成“会用 DDD”我真的建议你去试试让 AI 干这活。别指望它一步到位给它输入正确的背景信息、让它多轮推演、你来拍板这套打法目前实测下来是目前让我这一百多号人的技术团队里DDD 落地成功率提升最明显的路径。最后给一个小技巧把技能包里的质检点清单摘出来贴到你们项目的 README 或代码评审模板里。即使你还没准备全面引入 AI 辅助开发这套清单本身就已经是一份极好的 DDD 代码评审规范了。 AI辅助DDD落地：cleanddd-skills技能包实战解析
1. DDD的落地上帝已死痛点到底在哪先聊个真实场景。我见过不少团队花了两三千块钱去上 DDD 培训课回来每个人都信心满满觉得终于找到了应对复杂业务系统的银弹。结果呢一个月后打开代码仓库还是老样子Controller 里写满业务逻辑Service 层化身 God Class所谓领域模型就是一堆只有 getter/setter 的 POJO。这真不是这帮程序员偷懒。我接触过的团队里DDD 落地失败率极高而且往往越认真学过的团队挫败感越强。原因很简单DDD 的理论体系看起来不复杂可真要落下去中间隔着太多“只可意会不可言传”的东西。1.1 领域建模时技术出身的团队最容易翻车做技术的人有个思维惯性看到需求第一反应是表结构怎么设计、接口怎么定义、状态流转怎么实现。但 DDD 的第一步是拒绝这种思维要求你先用业务语言聊天把领域术语对齐。光是这一步就能卡死一票团队。举个例子。一次项目里业务方管“取消订单”叫“退单”运营文档里写的是“作废”老系统代码里叫“closeOrder”。这些名词背后其实是同一个业务动作但团队里三个人开会能说出三个词导致后面领域模型里头概念全是乱的。这还只是命名对齐更别说判断某个行为到底该放在哪个聚合里、哪些业务规则属于不变量这种高端操作了。1.2 架构分层和编码落地之间的鸿沟教科书告诉你 DDD 分四层接口层、应用层、领域层、基础设施层。但没人告诉你边界画完之后落成代码时每一层该写什么、不该写什么。聚合根、实体、值对象、领域服务、仓储、防腐层……每一个战术模式在实战里都有十几个“这样的话要不要这么写”的判断点。我说个最典型的痛点。很多团队建模阶段画了一堆漂亮的聚合关系图到了写代码时发现不知道聚合根之间怎么关联。有的直接懒省事用仓库跨聚合查数据结果聚合边界形同虚设有的过度设计一个简单需求硬拆五个微服务。这些决策书上只给原则不给答案。1.3 一个标准的 DDD 落地最低需要多少步别觉得夸张我把一套完整的 DDD 落地流程拆开给大家看事件风暴2~3 天拉上业务方和技术方贴满一整面便利贴划分限界上下文确定上下文映射关系识别聚合、实体、值对象、领域事件设计仓储接口、领域服务、应用服务编写防腐层和适配器代码骨架落地把模型翻译成实际的类、方法、依赖方向持续重构每次变更都要检查模型是否腐化这套流程走下来动辄好几周。问题来了前面六步真的是只有人类才能做的事吗我现在的答案已经变了不是。而且很多步骤AI做得比人快得多。这也是我为什么要写这篇介绍——我把一套专门给 AI 用的 DDD 技能包cleanddd-skills折腾了出来用来专门干“DDD 从概念到代码”这摊最脏最累的翻译活。下面我详细说它是什么、能做什么、怎么用。2. cleanddd-skills是什么它不是AI框架是一套AI的DDD大脑先说结论cleanddd-skills不是一个像 Spring Boot 那样的代码框架而是一大套精心编排过的AI Skills技能包。你可以把它理解成“给 AI 加载的领域驱动设计外挂”。2.1 项目的定位与上手指南目前各类 AI 编程工具Claude、ChatGPT 的项目/知识库、Codex 的自定义指令、甚至通义灵码之流的提示词工程都开始支持 Skills 机制。所谓 Skills本质上就是一组结构化的提示词和规则文件告诉 AI 遇到什么任务时按什么流程走、输出时遵守什么格式、完成后要自查哪些质检点。cleanddd-skills干的事情就是把从事件风暴到代码落地的整套 DDD 方法论拆解成几十个按顺序触发的 Skill 文件。你不再需要跟 AI 废话“请你扮演一个 DDD 专家……”这种弱爆的提示词而是直接把对应 Skill 加载进去AI 就会自动进入“DDD 实施顾问”或者“事件风暴引导师”的角色按标准动作执行。上手路径很简单把仓库克隆下来把skills/目录下的文件拷到你的 AI 工具知识目录里按项目需要在对话开始时 对应的 skill不同工具触发方式不太一样本质就是让 AI 读取指令然后把你手里的业务描述、需求文档甚至是一段脏兮兮的老代码丢给它流程就转起来了2.2 Skill/提示词集的核心构成我按 DDD 的工作流把这套技能包分成了四大模块每个模块里面挂了一堆粒度更细的 Skill模块覆盖环节包含的Skill示例战略设计事件风暴、限界上下文、统一语言event-storming-guide、bounded-context-divider、ubiquitous-language-miner战术设计聚合划分、实体/值对象识别、领域事件定义aggregate-design、value-object-detector、domain-event-describer编码落地分层骨架、依赖方向、防腐层接口、仓储模式layered-architecture-generator、anti-corruption-layer-builder、repository-contract-generator评审重构贫血模型诊断、模型腐化识别、代码评审anemic-model-detector、domain-model-rot-scanner每个 Skill 文件内部包含了任务定义、输入要求、输出格式、质检点四块内容。任务定义告诉 AI 它当前扮演的角色和职责输入要求规定了它开始干活前必须要向你要哪些材料输出格式则强制它把结果按可评估的模板输出——比如事件风暴的产出必须是一张结构化的事件-命令-阅读模型表质检点是最后让它自查的清单防止它一本正经地胡编。这里我说一个设计理念我不是让 AI“生成一段关于订单的 DDD 示例代码”而是让 AI 严格按 DDD 流程从业务事实出发逐步推导出模型。区别在于前者是幻觉重灾区后者有输入约束和逻辑链条过程可以被回溯。这一点对后续实操非常关键因为 AI 一旦跑偏你能从它的推理链里快速定位是哪一步出了问题。3. 用AI按DDD标准重新走一遍建模流程这一部分我拿一个实际场景完整走一遍这套 Skill 包的用法。我用的例子是一个电商订单系统的子模块业务描述就三句话“用户下单后系统要锁定库存支付完成生成出库单如果超时未支付订单自动取消并释放库存。”这套流程如果你让一个初级开发来推 DDD 模型大概率会推出一堆奇怪的东西。我们看看 AI 按 Skill 包会怎么处理。3.1 从业务描述到事件风暴加载event-storming-guideSkill 后我把上面那段业务描述丢给 AI然后给它一个命令“按事件风暴流程完善这个流程可能涉及的事件、命令和角色。”AI 的产出逻辑很有意思。它不会直接给我一张表而是先反过来向我确认问题库存锁定是由哪个系统触发、超时未支付的时间窗口是业务规则还是技术配置、用户取消订单和系统自动取消是否走同一个命令……这一步让我很惊喜它把“事件风暴引导师”该做的业务澄清动作做出来了。我补了几个信息后AI 输出了这样一张表类型名称触发方/角色备注命令CreateOrderCommand用户创建订单命令LockInventoryCommand订单服务锁定库存命令MarkOrderPaidCommand支付网关回调支付成功命令CancelOrderCommand用户/系统定时器取消订单领域事件OrderCreated订单服务触发库存锁定领域事件InventoryLocked库存服务锁定成功后发出领域事件OrderPaid订单服务触发生成出库单领域事件OrderCancelled订单服务触发释放库存阅读模型OrderDetail查询端订单详情展示这张表不能说全对但已经达到了一个中级架构师做事件风暴的第一轮产出水平。它还额外标注了哪些事件与聚合之间的时序关系这为下一步做聚合划分提供了原材料。3.2 从事件风暴到聚合划分聚合划分是 DDD 战术设计里最考功力的环节因为它没有唯一正确答案只有“当时看合不合理”的设计权衡。aggregate-designSkill 在拿到上面的事件表后会先列出候选对象订单、库存单、出库单、支付单。然后它做了一件书上会写但不告诉你细节的事——逐个分析业务不变量invariant。比如“锁定库存”这个动作。AI 会问锁定失败时订单还能不能创建超时释放库存和手动取消释放库存会不会发生并发如果订单取消和支付成功几乎同时发生系统该怎么保证一致性这些追问把聚合间的一致性边界给逼了出来。最后 AI 给出的划分建议是Order聚合聚合根为订单包含订单项、收货地址、支付状态、订单状态Inventory聚合聚合根为库存项独立管理锁定数量Outbox聚合负责消息可靠投递记录领域事件其中“订单取消时验证是否已支付”这个业务规则被划到了订单聚合内因为这是订单自身的状态一致性边界而“库存锁定数量”则是独立的不变量绝对不能放进订单聚合否则一旦出现并发会导致超卖——这个判断逻辑被 AI 明确列了出来而不是黑箱输出。这点很关键因为就算你不同意 AI 的划分你也能看到它划分的依据然后和人讨论。3.3 从聚合到限界上下文拿到聚合模型后bounded-context-dividerSkill 开始工作。它会依据“聚合不要跨界”“语言要统一”“事务边界要清晰”这几个标准去划分限界上下文并生成上下文映射图。上文那个电商子域AI 给出了这样的判断订单聚合和库存聚合虽然都出现在“下单”这个业务场景里但它们分属不同的限界上下文——订单上下文和库存上下文。二者通过领域事件InventoryLocked/InventoryReleased解耦而不是直接调用各自仓储。它在两个上下文之间生成了一段防腐层接口描述InventoryGateway并标注实现可以是 Feign 接口调用、MQ 消息、或者本地进程内事件这取决于部署形态。到这里战略设计阶段的产出已经可控。AI 甚至额外提示了上下文映射类型订单上下文和库存上下文是“防腐层 合作者”模式库存作为下游系统契约稳定性要求极高。我把这些结果发给团队里的资深架构师看他说了一句“这套输出已经达到了我带三年的初中级架构师独立完成的水平而且速度真的快。4. AI辅助落地的三个最实用场景模型设计得再漂亮最终要落到能跑的代码里。这一章节我挑三个我日常用 AI 辅助 DDD 落地最频繁的场景每个都是可以直接抄作业的。4.1 生成分层骨架代码含示例建模完成后layered-architecture-generatorSkill 会把我们前两步的产出翻译成一个符合 DDD 分层架构的代码骨架。我特意选了 Java 技术栈DDD 在 JVM 生态里的工具链最成熟拿上面订单上下文的部分契约举例。第一轮AI 直接生成了如下几个核心类// 领域层 - 聚合根 public class Order { private OrderId id; private ListOrderLine lines; private OrderStatus status; // 领域行为取消订单 public void cancel(OrderCancelPolicy policy) { if (this.status.isPaid()) { throw new OrderAlreadyPaidException(已支付订单不可取消); } if (!policy.canCancel(this)) { throw new OrderNotCancellableException(订单当前状态不允许取消); } this.status OrderStatus.CANCELLED; this.addDomainEvent(new OrderCancelled(id, lines)); } // 领域行为标记支付成功 public void markPaid() { if (this.status ! OrderStatus.AWAITING_PAYMENT) { throw new IllegalStateException(订单当前状态无法支付); } this.status OrderStatus.PAID; this.addDomainEvent(new OrderPaid(id)); } }看到这个骨架我的第一反应是它至少没有犯新手最常犯的错。每个业务动作都写在聚合根上、状态变更必须从方法进入、领域事件在状态变化时触发。这个代码可以直接作为代码评审的基线。这里我也明确提醒一句AI 生成的骨架代码只能作为设计蓝图的代码化表达不是可以无脑跑到线上的东西。事务边界、并发控制、消息可靠性这些基础设施问题它给的往往偏简化需要团队自己补强。但它帮我们省掉了从“空目录”到“分层包结构 核心领域对象”的半天时间。4.2 现有代码的DDD化重构建议第二个场景更常遇到——老系统改造。我给 AI 丢了一个典型的“贫血模型上帝服务”类让它做 DDD 化诊断。初始代码是一个写满了订单逻辑的OrderService里面包含了价格计算、库存校验、优惠券使用、物流单生成等十几个方法。anemic-model-detectorSkill 工作方式不是直接给我一版正确的代码而是先出一份“病灶清单”OrderService承担了本属于聚合根、领域服务、应用服务三层的职责Order实体沦为数据包无任何领域行为优惠券计算逻辑依赖外部服务未定义防腐层耦合过紧库存扣减直接调用仓储事务未显式表达最终一致性需求然后它给出了重构路径的建议顺序先抽领域服务PricingService→ 把订单状态流转收敛回聚合根 → 引入CouponGateway防腐层 → 最后再考虑代码级拆分。这里关键点在于顺序如果把防腐层改造放在最后前期的状态收敛还能小步提交如果顺序反了中间态代码会把整个团队逼疯。我在多个项目里验证过这个模式让 AI 先做“诊断”比直接让它“改给一版代码”可靠得多。因为诊断结果是给人做决策的而改动结果是需要人来承担后果的。4.3 持续评审让AI盯住防腐层DDD 项目最怕的其实是“慢慢腐烂”。上线没问题但每隔几次迭代就有新同学嫌跨限界上下文查数据太麻烦直接在应用服务里加了一个仓储查询把防腐层绕了过去。这种腐化靠代码评审人工查非常累因为每次 diff 都很大。domain-model-rot-scannerSkill 用起来就很简单。我在代码提交前把变更的 diff 文件扔给加载了该 Skill 的 AI并附一句指令“扫描本次变更检查是否存在跨限界上下文调用、聚合越界、行为泄漏到应用层。”实测下它检查出来的问题形形色色在OrderApplicationService里直接写过inventoryRepository.reduceStock()本该走InventoryGateway、在查询接口里直接拿了聚合内部状态来拼页面本该用阅读模型/查询模型、还有在实体上加了updateInventoryByOrderId()这种“反 DDD”的静态方法。当然AI 的评审结果和资深架构师相比判断精度还差一点会有误报、甚至漏报。但把它当作第一道自动化防线配合人工抽查效果非常明显。一个小团队每个月能少打十几场“这个责任该谁付”的扯皮仗。5. 实测中踩过的坑和需要注意的边界工具再顺坑还是有的。说实话AI 做 DDD 咨询的上限很高但下限也很低。如果使用者自己没有足够的判断力去和它对话AI 会一本正经地用非常流利的语言产出一堆华丽但错误的设计。我用这套技能包踩过几个坑专门拿出来说说。5.1 AI的DDD知识有方言问题你打开任何一篇讲 DDD 的文章可能都会说“聚合是一致性边界”但这句正确的废话到了不同的 AI 模型手里解释出来的差异极大。有的模型把聚合理解成“一组对象的集合”有的理解成“事务边界”有的甚至会认为“一个聚合只能有一个实体”。我遇到过最离谱的一次AI 在一个进销存系统里生成出了单个聚合包含“商品、库存、采购单、销售单”的巨型模型。它的理由是“这些都是围绕商品核心业务紧密关联的对象”。如果在团队讨论里出现这种设计肯定得被喷死。所以现在我使用这套技能包之前一定加一步热身对话先让 AI 讲出它对 DDD 里关键概念的定义比如“聚合根”“值对象”“防腐层”我会快速判断它跟主流 DDD 理解是否有偏差。如果偏差大先纠正它再来做正事。还有一个更隐蔽的问题AI 训练数据里的 DDD 案例大多是旧版企业应用架构对“现代微服务下 DDD 怎么和分布式事务协作”这类问题很多模型的回答是自相矛盾甚至过时的。这个锅不完全在 DDD 和 AI而是领域在不断演化。所以技能包中的提示词我特别加了“当前项目技术栈上下文”这一段要求 AI 在回答前先确认部署形态和技术栈降低“老案例套新场景”的风险。5.2 提示词不能一次到位怎么办你可能会发现第一次加载 Skill 包让 AI 输出结果不理想。这太正常了。这套技能包设计的是“多轮对话工作流”不是“一条提示词生成最终结果”的魔法。我的建议是遇到输出不对不要立刻否定 AI而是先让它解释推理链路。比如它把Inventory聚合划分错了你让它“说出你这样划分满足哪些业务不变量、依赖的是哪条领域规则”。它往往会在自我解释过程中发现自己忽略了某个业务约束然后主动修正模型。这个过程和人类设计师的“设计评审迭代”很像只是 AI 迭代一轮只需要几十秒。还有一种情况是 Skill 文件触发了但 AI 没有记住上下文。项目稍微大一点对话历史一长AI 就会“忘了”自己是在做 DDD 建模开始自由发挥。我的解决方法是在关键节点主动引用初始输入里已经确认过的模型契约用一句“继续按我们之前确认的Order聚合边界推进”把话题拉回来。一句话成本的投入能换来方向的大幅收敛。5.3 哪些步骤绝对不该交给AI虽然我把这套技能包描述得神通广大但下面这几件事我强烈建议永远不要让 AI 代替人来做业务规则的最终拍板。AI 可以帮你列出候选方案并分析利弊但“到底接受最终一致性还是强一致性”“库存不足时是阻断下单还是预占后通知”这类决策必须由业务负责人和技术负责人当面聊清楚AI 无法理解决策背后的组织政治和成本考量。大型架构方向选择。是引入 CQRS 还是保持传统 CRUD、要不要拆微服务、消息中间件选型——这些远超 DDD 范畴的问题靠 Skill 包硬套只会得到表面正确、实际错误的建议。合规与监管需求。金融、医疗等领域的审计要求、数据驻留政策、安全审计日志AI 在这些领域的“知识”往往缺乏时效性藏着合规风险。一句话总结用 AI 做“翻译”和“推断草稿”用人做“决策”和“审批”。这套分工在当前阶段最靠谱。你要是图省事把决策权也交给 AI那后来出的事就不是 AI 的锅了而是你自己的判断出了问题。6. 我个人的使用心得与后续玩法最后聊几句掏心窝子的话。我在实际使用中最大的感受是AI 把 DDD 落地最大的隐形门槛——从业务语言到代码语言的翻译成本——给降下来了。过去团队里只有少数能同时在业务会议室和白板前挥洒自如的技术骨干才能完成这种翻译。现在一个愿意动脑子、能拿主意的普通开发在 AI 的辅助下也能撸出一版及格的 DDD 设计初稿。当然这是辅助不是替代初稿质量大概在“可评审”级别还达不到“可直接拍板”级别但它至少让评审这事的参与门槛降了很多更多人可以围绕具体产出物发表意见了。关于落地节奏我的建议是从小处开始不要一上来就找个核心系统搞三个月大改造。选一个边缘但真实的业务模块花一两天把技能包跑通让团队看看 AI 的产出物长什么样、评审讨论怎么进行、代码怎么落下去。有了这个“样板间”再往核心业务推进阻力会小很多。顺带说一个我自己在用的扩展玩法。这套技能包不只是能服务 DDD它的编排思想可以平移到其他有标准作业流程的方法论上。比如我后来把自己团队的整洁架构落地规范也按照同样的模式做了一份技能包还做过一个给 AI 用的“微服务拆分决策引导包”核心就是把“固有方法论 团队实际情况”缝合成一套结构化指令让 AI 的能力被约束在团队认可的框架内输出。如果你现在正准备在一个项目里尝试 DDD或者正苦恼怎么让自己的团队从“学过 DDD”变成“会用 DDD”我真的建议你去试试让 AI 干这活。别指望它一步到位给它输入正确的背景信息、让它多轮推演、你来拍板这套打法目前实测下来是目前让我这一百多号人的技术团队里DDD 落地成功率提升最明显的路径。最后给一个小技巧把技能包里的质检点清单摘出来贴到你们项目的 README 或代码评审模板里。即使你还没准备全面引入 AI 辅助开发这套清单本身就已经是一份极好的 DDD 代码评审规范了。