最近在团队里推DDD最常听到的一句话是“模型图好看落地就抓瞎。”这事我太有同感了。DDD难落地不是理念有问题而是从业务语言到代码结构之间隔着一整条流水线过程中全是需要耗费大量心力的转译和判断。也正是这份“重”让“DDD落地难”成了微服务架构团队里最常见的叹息。前阵子我接触到 cleanddd-skills 这套东西思路很直接DDD 那些标准动作比如事件风暴、聚合拆分、防腐层设计、代码骨架生成交给 AI 去干人只负责拍板业务规则。听起来像偷懒实际上是把 DDD 从“个人专家手艺”变成“团队可复制流程”。这篇文章我会用实际项目场景过一遍它的设计逻辑、完整使用路径、生成效果以及我踩过的坑想用 AI 把 DDD 落地往前推一把的工程师应该能从中拿到可以直接用的东西。1. DDD落地的真实痛点为啥大部分项目最后都变成了“伪DDD”先说结论大多数团队不是不知道 DDD 的好处而是死在了从“建模”到“代码”之间的漫长转译上。DDD 本身提供的是一套思考框架但它没有把手把手教你把每个概念变成代码的路径于是项目刚开始时雄心勃勃半年后全部退回 CRUD 加 Service 大杂烩。1.1 模型与代码脱节评审会说“好”上线就变“烂”我见过太多项目开过漂亮的建模工作坊白板上画得清清楚楚领域专家也在场大家一致同意订单聚合根、商品值对象、库存领域服务的设计。可等真正进入开发阶段问题全冒出来。今天一个紧急业务需要改订单状态后天一个报表需求要跨多个聚合查询大家没有耐心去维护那个精心设计的模型直接在应用服务里把仓储干掉写了个原生 SQL join。代码和模型很快就对不上了。到上线一年后再回头做技术复盘想照着当初的模型文档去维护代码发现已经没有对应关系了。所谓“DDD架构”只剩下一堆空壳文件夹domain 目录下有 Entity但里面躺着几十个 getter/setterapplication 目录下有 Service但业务规则全写在里面一个事务里处理五六个实体。这种“伪 DDD”比不用 DDD 还要糟糕因为它给了团队一种虚假的架构安全感后续维护时很难判断这块逻辑到底应该放哪一层。深挖根因关键瓶颈不是开发者不懂聚合而是模型和代码之间缺少一个“持续校验”的反馈环。白板上的模型是一次性产物代码才是持续演化的活物。没有工具持续督促模型对齐、没有自动化能力把模型结构映射成代码骨架模型就注定会在开发压力下腐化。这正是 AI 可以切入的地方——它不是帮你做业务决策而是帮你在每次改动时都保持模型与代码的对应。1.2 事件风暴门槛高不是每个团队都有领域专家坐镇事件风暴是 DDD 里最经典的建模活动一堆人贴便签把业务事件、命令、聚合、限界上下文一步步理出来。但这个活动对参与者要求很高尤其是那个能拍板业务规则的领域专家。现实中大多数团队根本没有专职领域专家所谓业务人员可能是产品经理也可能是懂一点业务的开发组长。让他们对“订单已提交”“库存已预占”这类领域事件做分类他们自己都很难拿出准确说法。更要命的是事件风暴通常只有一两天产出却是后续几个月开发的依据。会议一散便签拍个照塞进 Wiki没人再打开。后续开发时遇到边界模糊谁敢去找业务对线只好自己拍脑袋。于是模块边界、聚合划分、上下文映射全靠个人理解每个人理解还不一致。我也试过把事件风暴压缩成半天工作坊请业务方聊核心流转结果聊出来的都是接口字段和页面流程不是领域规则。后来才意识到让业务方直接讲“领域事件”是反直觉的他们习惯讲操作步骤不会讲状态变化。这里就需要有人能做一层转译把操作步骤拆成领域事件再组织成模型。这个转译工作AI特别擅长它不需要“现场理解”业务只要你把原始业务描述喂进去它就能按照事件风暴的格式梳理出一版候选事件流然后再由人筛选确认效率完全不同。1.3 聚合边界总是拍脑袋防腐层最后都成了摆设聚合边界设计堪称 DDD 落地里最考验功力的一环。一个订单要不要包含订单项库存是一个独立聚合还是值对象支付记录要不要直接挂在订单上这些设计决策如果没有清晰原则最终往往取决于“哪个方案代码写着方便”。常见情况是开发为了事务一致性把所有东西塞进一个大聚合最后一张表几千个字段任何修改都锁同一行并发能力差到离谱。反过来有人为了性能把聚合拆得太碎一个业务操作跨四五个聚合分布式事务满天飞一致性无法保证。这两种极端都是一个原因聚合的边界不是从业务不变量推导的而是看心情定的。防腐层就更惨了。设计的时候都同意“不能让外部系统模型污染领域模型”但真做的时候防腐层要么被忽略要么变成了一个只知道转字段的工具类调用链还是把外部 DTO 直接传进 domain 层。因为防腐层本身是“没有业务价值”的代码它不像下单、退款那样能讲出故事KPI 考核也没人看它。但它恰恰是 DDD 架构长期健康的护城河丢了它领域模型就会被各种外部协议的字段侵蚀。所以我说DDD 落地难难的不是概念是没人把这些苦活累活持续做到位。而 AI或者说 cleanddd-skills 这类技能包能帮我们把这一整套流程变成标准化流水线。2. cleanddd-skills的设计思路把DDD重活拆给AI干当我把“让AI干”挂在嘴边时很多人第一反应是嗤之以鼻“不就是一个提示词吗让 AI 写 DDD 代码”事实没那么简单。cleanddd-skills 确实依赖 AI但它核心的设计思路是把一个资深 DDD 架构师解决问题的完整路径固化成了 AI 可执行的工作流。它不只是一个会写代码的助手更像一个 24 小时在线的建模搭档。2.1 它的本质一组可复用的DDD专家技能包cleanddd-skills 本质上是“技能包集合”。你可以把它理解成给 AI 预装的一系列“专业能力模块”包括事件风暴、聚合设计、限界上下文划分、领域模型生成、防腐层生成、代码骨架生成等。每个 skill 内部包含几个部分触发场景、执行步骤、输入输出格式、质量检查清单。比如事件风暴这个 skill它的执行步骤大致是先读取你描述的业务流程识别关键状态变化输出领域事件表再根据事件归属划分聚合然后识别命令和角色最后生成一张带优先级的建模问题清单让 ChatGPT 或 Claude 去提问而不是一股脑给你结果。这里有一个很关键的机制skill 不是靠“大模型开悟”一次性输出而是靠结构化的步骤约束模型逐步推理。和普通“帮我设计一个订单聚合”的 prompt 相比step-by-step 的工作流能把“拍脑袋”变成“推导”每一步都有依据。2.2 和普通“AI写代码”提示词有什么不同很多人用过“帮我写一个电商系统的 DDD 架构”然后 AI 吐出来一堆带有 domain/application/infrastructure 三层的目录结构。看起来很标准但深究一下那个模型只是把“电商系统”四个字映射到泛型模板上完全不含业务逻辑。这种生成的架构属于“绣花枕头”看着像 DDD实际上价值很有限。cleanddd-skills 的区别体现在两点。第一它有建模前置环节。你在代码生成之前AI 会先引导你描述业务流程、领域事件、规则约束把领域知识榨干然后基于领域事实做设计。普通 prompt 是“从关键词直接到代码”skill 是“从业务描述到事件流到模型到代码”然后到代码只是流水线最后一站。第二它维护了一整套“约束规则”。比如实体和值对象的区分依据、聚合内引用规则、领域服务无法归入现有实体时才创建、应用层不直接依赖基础设施层。这套约束在生成代码的每一步都会被检查减少了 DDD 的“形似神不似”。从实际体验来说普通提示词生成代码的正确率也就是“能用”而用 skill 工程跑出来的结果至少是“符合 DDD 原则且可评审”。这两者之间差着一个完整的架构评审环节。2.3 工作流三段式建模、映射、生成我把 cleanddd-skills 的工作流简单归纳为三段式建模 → 映射 → 生成。建模阶段解决“领域模型是什么”。AI 作为一个结构化助手会引导你输入业务故事识别出领域事件、命令、聚合、限界上下文。这个阶段的核心产物是一份领域模型文档它描述的是业务逻辑本身不掺杂技术细节。映射阶段解决“模型怎么映射到代码结构”。同一套领域模型可以映射到 Spring Boot、Java EDA、TypeScript 等不同技术栈。cleanddd-skills 在这个阶段会根据目标技术栈确定代码目录结构、对象职责、依赖方向、事务边界。比如在 Spring Boot 下它会把聚合根实现为 JPA Entity值对象实现成 embeddable领域服务实现成 Spring Bean仓库实现为接口加 Implementation。生成阶段才真正开始产出代码。AI 基于前两个阶段的模型和技术映射生成领域模型、仓库接口、应用服务、防腐层、基础实现等完整代码。对工程师来说前两个阶段才是决定架构质量的部分最后一个阶段只是体力活。这套设计的好处是它把“决策”和“转译”分开了。人负责拍板业务决策AI 负责把决策转译成模型、再把模型转译成代码。这也解决了开头说的“模型腐化”问题——因为模型一旦变更重新跑一遍流水线代码骨架就能同步更新模型和代码始终保持对应关系。3. 安装与上手从一个真实业务需求开始理论部分说了那么多接下来进入实战。我用一个真实的业务需求来演示一下 cleanddd-skills 的使用流程。拿“订单履约”场景举例这个场景足够典型大家都能看懂涉及的 DDD 元素也丰富。3.1 环境准备和安装cleanddd-skills 的使用前提是你有一个能跑 AI 对话的环境以及一个支持加载外部技能包的客户端一般是 Claude Desktop、知识库型 IDE 插件这类工具。安装步骤很简单把 cleanddd-skills 项目克隆到本地把 skills 目录下的技能包路径配置到 AI 客户端的技能加载目录然后在对话中开启对应技能即可。给第一次接触的人一个建议别一上来就装全套技能包先用核心的三个——event-storming、aggregate-design、code-gen。这三个技能覆盖了“建模到生成”的最短闭环。其他的比如 context-mapping、anti-corruption-layer等玩熟了再逐步加。我实际的安装配置大概长这样伪配置# 克隆项目 git clone https://github.com/xxx/cleanddd-skills.git # 将 skills 目录加入 AI 客户端的技能路径 # 例如在你使用的客户端配置文件中加入 skill-path: ./cleanddd-skills/skills enabled-skills: event-storming, aggregate-design, code-gen这里有个容易忽略的坑技能包加载之后最好新建会话验证一下。有些客户端会缓存技能列表旧会话里可能无法触发新技能导致你写了半天它也没走上 DDD 流程。实测下来新建会话是最稳的。3.2 用自然语言描述业务让skill跑完第一轮建模安装完成后我不建议直接说“帮我设计订单履约 DDD”那样表达信息量太少。正确做法是像给一位刚入职的领域专家讲业务一样把业务流程讲清楚。一个可参考的写法是我们要设计一个订单履约系统。核心流程如下用户创建订单后系统先做库存预占然后调用支付网关收款支付成功后订单流转到仓库仓库进行拣货、打包、出库出库后物流系统揽收并更新物流轨迹。用户可以在任意环节取消订单但已出库订单取消需要走拦截流程。仓库库存不足时订单进入缺货等待状态到货后自动恢复履约。请基于以上业务启动事件风暴建模。这里的关键是信息密度。你把状态变化、分支条件、超时规则、决策规则都写上AI 才有足够素材提取领域事件。如果描述里只有“订单支付”四个字模型设计必然单薄。启动 event-storming 技能后AI 首先会输出一份领域事件草稿。这段输出我建议不要直接当结论而是当作“值得评审的候选清单”。领域事件候选 1. 订单已创建 2. 库存预占完成 3. 库存预占失败 4. 支付完成 5. 支付超时 6. 订单已取消 7. 订单已进入缺货等待 8. 订单已恢复履约 9. 订单已出库 10. 物流已揽收这段输出里你会发现一个值得讨论的点支付超时算不算领域事件严格来说“超时”是一种时间触发的状态变化应该算但它的归属聚合需要讨论。这类问题正好是人工介入评审的价值点。AI 不是替代你决策而是把所有候选摆上台面让你做更高密度、更高层次的决策。3.3 关键产物一事件风暴与限界上下文草稿第一轮事件流出来后skill 会继续引导你划界限上下文Bounded Context。这个环节它通常会用几个维度去判断业务语义是否一致、变更频率是否相近、团队组织边界、性能吞吐要求等。以订单履约为例AI 会在事件流基础上把“订单创建与查询”“库存仓储控制”“支付结算”“物流履约”几个候选上下文梳理出来。值得提醒的是限界上下文划分没有一个“标准答案”。同一个电商场景淘宝、京东、拼多多这类不同平台的边界设计都可能不一样。AI 给出的推荐是合理基线你应根据团队组织架构进行调整。比如团队里只有一支后端队伍那拆成 5 个上下文意义就不大可以合并成 3 个模块重点保住聚合边界和依赖方向。这时候需要打开 context-mapping 技能让 AI 输出上下文之间的关系图。它一般会用文本形式描述订单上下文依赖库存上下文支付上下文通过事件异步通知订单上下文访问外部 WMS 时通过防腐层隔离。结合领域事件清单你会得到一张“上下文关系表”这比白板上画的更精细因为每个依赖都标注了来源和理由。3.4 关键产物二聚合根候选清单与拆解理由聚合设计是 DDD 里最富争议的部分。cleanddd-skills 在这步的输出逻辑是先列出所有候选实体再根据业务不变量和一致性边界分组最后对每个组选出聚合根。以订单履约场景为例AI 会先列出订单、订单项、商品、库存、支付单、出库单、物流运单等候选。接着它会对“订单与订单项为何在一个聚合”给出理由订单行的增删改必须保持总数一致跨订单项的不变量要求在单个事务内完成所以必须同聚合。而库存为什么不应该做成订单的子实体因为库存没有强一致要求允许超卖预占失败并且库存事务边界通常独立于订单。这里 AI 的设计决策完全是从业务规则推导的推导链路上每一步都有依据。输出的聚合根候选长这样聚合根包含实体/值对象业务不变量事务边界订单订单项、收件地址、金额明细订单总金额 所有订单项金额之和订单状态变更与订单项变更同事务库存单库存明细、预占单库存预占数量不可超过实际库存预占成功/失败影响订单状态但不跨聚合强一致支付单支付记录、退款单支付总金额与订单应付金额一致支付回调处理独立幂等如果你发现 AI 给出的聚合边界和你的业务理解不一致务必要在生成代码之前让它调整因为聚合边界一旦固化到代码里后续改动成本极高。这是整个技能流里人工介入权重最高的环节宁可在这一步多花一小时也别到代码阶段返工。4. 实战演示用订单履约场景跑通全流程现在用订单履约场景完整走一遍从建模到代码生成的流水线。这部分你会看到 AI 产出的模型长什么样、生成代码的目录结构是什么样、以及人工需要在哪些地方做修改。4.1 输入的业务描述为了更接近真实开发我加了一些边界条件进去包括用户下单时可以选择预占锁定库存还是下单后异步确认库存不足时一旦补货自动恢复已出库订单取消要走 WMS 回传拦截结果。规则越细生成的模型越可信。订单履约规则如下用户提交订单后可选择“库存锁定”或“支付后再确认库存”若选择锁定库存则下单即预占库存预占失败则订单进入冻结状态并提示库存不足若未锁定库存则支付成功后才尝试占库失败则自动退款并取消订单已支付订单可申请取消若订单未出库则直接取消若已出库则进入拦截流程等待仓库回传拦截结果缺货等待的订单在补货入库后自动恢复履约不需要人工介入。这段描述的每一句话都对应了后续代码里的一个业务规则分支。输入质量决定了模型质量这句话在 DDD 设计里永远成立。你可以看到这些规则里其实已经隐含了多个聚合之间的交互方式比如订单状态受库存结果和支付结果的双重影响。如果不对这些分支做显式建模代码里百分之百会出现长长的 if-else 判断写着写着就把领域规则丢进应用层了。4.2 AI生成的领域模型实体、值对象、聚合第一轮建模后AI 输出了一组领域模型。我贴在下面的是精简版聚合根订单Order内部包含订单项OrderLine值对象、收件地址RecipientAddress值对象、金额明细MoneyAmount值对象、库存预占状态StockReservationStatus值对象。Entity Table(name orders) public class Order { EmbeddedId private OrderId orderId; Embedded private RecipientAddress address; OneToMany(cascade ALL, fetch LAZY) JoinColumn(name order_id) private ListOrderLine lines; Enumerated(EnumType.STRING) private OrderStatus status; Embedded private StockReservationStatus reservationStatus; // 领域行为只有当订单处于 PENDING_PAYMENT 且未锁定库存时可以切换为支付后占库 public void confirmStockAfterPayment() { if (this.reservationStatus ! StockReservationStatus.NOT_LOCKED) { throw new IllegalStateException(订单已锁定库存不允许切换扣库方式); } this.reservationStatus StockReservationStatus.PAYMENT_CONFIRM; } }这段代码里有几个值得注意的设计点。Order 作为聚合根它暴露的是领域行为方法 confirmStockAfterPayment而不是直接暴露 setStatus、setReservationStatus 之类的操作。外部唯一能改变状态的方式就是调用语义清晰的业务方法。这一层保护是 DDD 的核心价值所在。仓库接口也生成了。它的接口只定义领域需要的方法具体的数据库实现由 infrastructure 层提供。public interface OrderRepository { OptionalOrder findById(OrderId orderId); void save(Order order); OptionalOrder findPendingRestoreOrders(); }这里你想让 AI 不要把所有查询都塞进 Repository可以在技能里配置规则。默认情况下订单查询、报表类方法会被拆到单独的查询服务避免污染聚合仓库。这一点相当重要因为报表需求会拖着一个巨型查询接口最终导致聚合根变成一个数据访问门面。4.3 生成的Spring Boot骨架代码与实际调整点建模确认后code-gen 技能会把模型映射成完整的 Spring Boot 工程骨架目录结构大概是这样的order-service ├── application │ ├── service │ │ ├── OrderApplicationService.java │ │ └── OrderQueryService.java │ └── dto ├── domain │ ├── model │ │ ├── Order.java │ │ ├── OrderId.java │ │ ├── OrderLine.java │ │ └── OrderStatus.java │ ├── repository │ │ └── OrderRepository.java │ └── service │ └── OrderDomainService.java ├── infrastructure │ ├── repository │ │ └── OrderRepositoryImpl.java │ └── anticorruption │ └── WmsAdapter.java └── interfaces ├── controller └── event └── OrderEventConsumer.java对于这个结构我要强调两个在实际项目中反复踩坑的点。第一个是依赖方向。domain 层不应该直接引入 Spring 的注解或依赖。但 AI 默认生成的代码很容易把 spring-data-jpa 注解写在 entity 上比如前面的 Order 类里就有 Entity、Table 这类标准 JPA 注解。如果你的团队非常洁癖希望领域层完全与技术框架解耦需要在技能里追加一条显式规则领域层禁止使用任何框架注解JPA 映射放到 infrastructure 层或者单独 mapping 类。第二个是事务边界。AI 生成的应用服务里事务粒度默认都是方法级别也就是一个用例一个事务。这在大多数场景下是对的但万一某个用例需要跨两个聚合比如“支付成功且有锁定库存”的场景里既要改支付单状态又要改订单状态这时事务边界要画在哪层skill 本身无法替你决策它只能按单聚合事务生成。真实生产里这类跨聚合一致性比较常见的解法是引入本地消息表加事件驱动而不是硬写在同一个事务里。这是你在评审代码时要重点看的地方。5. 效果实测与踩坑记录AI写的DDD代码有哪些坑没有任何工具是银弹。我用 cleanddd-skills 跑通整个流程后确实感受到了效率的提升但也发现 AI 在 DDD 落地上有一些倾向性问题。如果不注意这些坑照样会把项目带回“伪 DDD”。5.1 最大收益模型评审效率明显提升先说收益这也是我推荐这套玩法的根本原因。过去我们建模评审会最痛苦的是大家对着白板“从一个对象聊到另一个对象”没有结构。用 skill 跑出来的候选模型把实体、事件、上下文、聚合边界、业务不变量都列成清单评审会直接变成了清单评审会效率和深度完全不同。过去一次评审可能要 4 小时大家最后在“报销单算不算一个聚合”上吵一小时。现在 AI 把候选设计摆出来每个人直接对着候选提意见十分钟之内就能收敛分歧。不是 AI 比人更懂业务而是它把讨论对象从“空气”变成了“可反驳的草案”。在很多团队里缺的就是这么一份“看起来已经很完善”的初稿有了初稿讨论才有的放矢。另外一个隐藏收益是新人也能参与架构讨论。之前如果对 DDD 理解不深进评审会基本是听天书。现在 AI 给出的每个决策都带理由和业务不变量新人读着这些理由就能快速理解模型设计思路团队的整体 DDD 能力都在被托起来。5.2 坑一AI太爱设计“万能聚合”需要人工砍AI 生成聚合边界时有一种倾向下意识把所有关联的对象都塞进同一个聚合因为它本能地觉得“都要在一个事务里改”。比如营业额统计、促销活动规则、会员积分策略这些都被 AI 试图挂在订单聚合上。结果就是聚合内对象膨胀事务范围越拉越大最终必然遇到并发锁冲突和性能瓶颈。我的处理方式是在大多数业务里保持一个原则聚合尽量小而专一优先保证不变量而不是图操作方便。如果跨聚合的一致性无法避免就显式用领域事件去处理而不是扩大聚合边界。所以每次 AI 给出聚合设计后我都会强制问它一句如果这个聚合去掉某个子对象哪些业务规则会破坏如果不会破坏就说明它可能不应该在这里。实际项目中订单聚合最后只保留订单项、金额、地址这类必须同生共死的对象库存、支付、物流全部独立成聚合。这样做后代码里少了跨聚合的大事务事件驱动流程也变得更加清晰。5.3 坑二生成代码的包结构容易“串层”AI 生成代码时最容易出的低级错误是包结构串层。domain 层里出现 Spring 注解算一个更常见的是 infrastructure 层里出现了业务规则。比如“库存不足时订单进入冻结状态”这段规则逻辑被 AI 放进仓储实现里因为实现里恰好有判断库存的代码。但严格说这是领域规则应该由 domain 服务或应用服务协同多个聚合完成不应该沉到 infrastructure 层。对付这个坑没有捷径只能靠代码评审和静态检查。cleanddd-skills 自带的 quality-check skill 可以帮你做一轮自动检查它会扫描生成的分层结构里是否存在依赖倒置违规、领域层是否出现框架依赖、聚合根是否暴露 setter 等。实测下来它抓得还是比较准的能过滤掉七八成明显问题。但自动化检查永远替代不了人工判断。我推荐在每个模块生成完成后指定一个“DDD守门人”角色做最终评审。他会提问这条规则属于哪个对象的核心职责如果这个对象被删掉规则会怎么变化这类问题能逼着开发者把散落各处的规则重新安放到正确位置。5.4 坑三依赖倒置执行过头接口满天飞另一个让我哭笑不得的坑是AI 对“依赖倒置”执行得太彻底生成了大量不必要的接口。每个领域服务、每个应用服务、每个仓储、每个集成点都配了一个接口一个实现类。接口数量翻倍没人知道哪些接口是真正为了抽象多态而存在哪些只是为抽象而抽象。代码里充满了这种结构public interface OrderQueryService { ... } public class JpaOrderQueryService implements OrderQueryService { ... } public interface InventoryCheckService { ... } public class CompositeInventoryCheckService implements InventoryCheckService { ... }这些接口并没有多个实现也没有在未来需要多个实现的迹象纯属增加理解成本和跳转路径。DDD 里的依赖倒置不是要求每个类都接口化而是要求依赖方向从政策层指向机制层。对没有多实现需求的类直接用具体类完全没问题。我自己调整时会把 AI 生成的接口实现二合一只保留那些确实需要隔离技术细节的查询服务。比如访问 WMS 系统的防腐层肯定要独立接口因为后面很可能会接第二家物流供应商但订单查询服务这类纯内部逻辑直接一个类结束战斗。5.5 人工必须守住的几个检查点从这套流程跑下来总结出几个 AI 干不了、必须人工把关的检查点。首先是业务不变量。AI 可以从描述里提取出“金额必须相等”“状态不允许跳变”这类规则但判断这个不变量是否真的需要强一致、是否可以容忍最终一致只有业务方说了算。其次是聚合边界的最终裁决。AI 给出的是基于当前描述的推荐但当业务规则存在竞争关系时比如“库存要实时准确”和“库存要支持高并发”这个取舍是 AI 无法替你决定的。第三是事件命名与语言统一。团队内部统一用“预占成功”还是“占用完成”看起来是小问题但术语不一致会造成技术人员和业务人员沟通时的语义错位这个习惯得靠人维护。把话说得更直白一点AI 在这条流水线上其实是“执行者”和“初稿者”它负责把你拍到桌面上的需求高效地转成结构化模型和代码。但业务决策者始终是人。用的时候别把 AI 的输出当成最终答案而要把它的输出当成一个“值得认真讨论的候选项”。这个心态转变很关键否则 A 用想法工程化B 也会变成另一种形式的“伪 DDD”。6. 团队落地建议从个人玩具到团队协作如果你自己把 cleanddd-skills 玩顺了下一步自然是把它引入团队。这个东西从“个人效率工具”到“团队协作规范”之间还有一段路要走下面是我觉得比较实用的落地方案。6.1 怎么把skill包接入团队规范最推荐的做法是把 cleanddd-skills 定义的核心产物纳入团队的架构设计文档模板。现在团队里很多需求是从 PRD 直接跳代码的中间缺了领域建模环节。可以约定涉及核心业务规则的模块必须先跑一轮事件风暴建模把领域事件表、聚合清单、上下文关系作为设计文档附件随代码一起评审。这个规范对 AI 的约束同样有效。团队代码仓库里可以维护一个 ddd-model 目录存放每个模块的模型描述源文件实现了什么它实际上就是一份人机共同维护的活文档。模型变更时更新源文件然后重新跑一遍 code-gen 技能生成骨架代码人工再把新逻辑合到业务实现里。这样模型和代码之间的关系从“各自演化”变成“同源同步”实现了我开头说的反馈环。6.2 与AI协作的正确姿势和 AI 协作做 DDD 架构姿势很重要。我见过翻车最厉害的同事是因为他把 AI 当成可以全权委托的同学做完建模直接照单全收。问题在于他缺少独立的架构判断力AI 怎么建议他就怎么实现遇到模型与业务摩擦时他不会调整反而试图强行改业务去适配模型。这是本末倒置。正确姿势是把 AI 当成一个“极其勤奋但需要明确指令的初级架构师”。给它输入业务时尽量喂原汁原味的业务素材而不是你已经加工过的技术方案。你越是只用技术语言告诉它“我要一个订单聚合”它的设计空间就越窄产出就越模板化。你越是把真实业务中的例外规则、分支条件、模糊冲突全面交代给它它生成的模型就越贴合实际。AI 模糊不清的地方不要让它猜马上追问它。比如“支付完成后库存预占失败操作应发生在哪个用例中”让它在下一步生成代码前把条件补齐避免模型带病进入编码阶段。6.3 后续还能怎么扩展沿着这条路再往前看这套思路的扩展空间还很大。最直接的是把 cleanddd-skills 接到 CI 流程里每次合并请求自动跑一个 DDD 结构检查检查领域层是否出现外部依赖、聚合根是否有实体注入、防腐层是否被绕过。不用特别复杂标准也可以从严格到宽松逐步配置核心是让“模型腐化”在提交阶段就被发现而不是上线半年后追悔莫及。另一个方向是把建模产物和接口文档、测试用例联动起来。既然事件、命令、聚合边界都已经结构化了理论上可以从模型直接生成接口定义、状态机测试用例再和代码实现对照。这已经接近模型驱动开发的思路了。我目前也在试等有足够样本了再写成更细的内容分享出来。最后简单说说使用心得吧。踩过几次坑之后我最大的体会是DDD 的瓶颈向来不是“知识”而是“耐力”。大多数人不是不知道聚合原则而是缺乏一次又一次把模型搬进代码、在细节中维持一致性的毅力。cleanddd-skills 的价值恰恰在于把这份“耐力活”自动化了把人的精力从机械转译中释放出来重新聚焦到业务判断上。只要你能守住业务决策这道闸门让 AI 帮忙跑完从建模到生成的流水线DDD 落地这件事是真的可以往前跨一大步的。