企业官网建设流程全解析

做了这么多年架构，我见过太多团队在 DDD（领域驱动设计）上铩羽而归。你大概率不是不会写代码，也大概率认真翻过《实现领域驱动设计》或者 Evans 那本蓝皮书，但一回到真实项目，第一个问题就能把人卡住：这个限界上下文到底怎么切？那个"订单"到底是实体还是聚合根？这个服务到底是领域服务还是应用服务？说实话，几年前我自己也卡在这里，硬着头皮画的上下文映射图，评审会上被人问两句就露馅了。

后来我想明白一件事：DDD 难落地，难的不是理论，而是从"业务语言"到"软件结构"这条翻译链上，每一步都需要经验判断，而这种判断没办法通过看书获得。于是我把整套建模流程——事件风暴、限界上下文划分、聚合设计、Clean Architecture 分层——做成了一个可复用的 AI 技能包，起名 cleanddd-skills。思路很直接：让 AI 按 DDD 方法论当建模引导者，把过去要凑齐一屋子人开三天工作坊才能走完的流程，压缩成几轮有结构的对话，并且每一步都留下可审查的建模文档。

这篇文章写给三类人：学完 DDD 却不知道怎么下笔的人，想用 AI 提升设计效率的开发者，以及正在搭建 AI 辅助开发体系的团队。我会把 cleanddd-skills 的设计思路、运行机制、一次完整的实战推演，以及我在反复使用中踩出来的坑全部摊开来说。

1. 为什么 DDD 总是学完就废：概念和实战之间有一条经验断层

1.1 理论是"原则"，项目是"选择题"

DDD 的知识框架其实非常清晰：限界上下文、通用语言、聚合、实体、值对象、领域服务、领域事件、防腐层……每个概念单独拎出来都不难理解，考试能拿满分。但现实项目不会按照教材出题，它给的全是开放式的选择题：客户说"一个订单可以包含多个商品，但有些商品需要单独审批"，那么"需要审批"到底是一个独立的聚合，还是订单内部的一个状态？订单和商品是同一个限界上下文里的两个聚合，还是干脆属于两个不同的上下文？

这种判断的背后不是理论背得熟不熟，而是有没有见过足够多的业务形态，有没有踩过事务边界过大导致性能崩掉的坑，有没有被跨上下文调用的耦合坑到过。书上给的是判据，但把判据落到一个具体的、充满例外规则的业务场景里，需要的是经验。

很多团队学完 DDD 之后，最大的产出是一堆术语，代码还是按老办法写。原因是没人带着他们完成"业务事实→领域事件→命令→聚合→上下文"这条完整的推导链，而这条链才是 DDD 的真正骨架。 cleanddd-skills 解决的就是这个问题：把推导链固化成 AI 的提问和输出流程，逼着模型在每个决策点停下来追问，不跳步。

1.2 事件风暴很贵，贵到大多数团队办不起

DDD 最推荐的启动方式是事件风暴（Event Storming），一张长桌，一面便利贴墙，把业务人员、产品经理、开发、测试还有运维全聚在一起。理想情况下，一天下来，领域事件时间线有了，聚合识别出来了，限界上下文也有了雏形。

但现实往往是这样：约了八个人，因为各自的项目周期，时间凑了两周；人到齐了，却发现没有一位合格的引导者（facilitator），会议很快变成"订单优先级"和"退款逻辑"的业务辩论，一上午过去，墙上只贴了十几个橙色便签，其中还有一半是领导为了活跃气氛贴的。

我在自己的项目里试过不下五次线下事件风暴，经验是：事件风暴的价值毋庸置疑，但它的成本结构决定了它不可能成为日常迭代的一部分。一次高质量的工作坊，需要领域专家、架构师、业务分析师和工程团队同时在场，而且最好是连续的两到三天。这种组织成本，很多中小型团队一次都承担不起。

所以我想的是，能不能把事件风暴的引导能力做成一个"永远在线"的数字化教练，它可以部分替代线下工作坊里那个最有经验的人——也就是负责提问、归纳、追问的引导者。AI 不懂你的业务，但它非常擅长在正确的时间点问正确的方法论问题，这就够了。

1.3 AI 的角色定位：不是架构师，是建模教练

这里需要把 AI 的定位说清楚。我从来不认为 AI 能替代架构师做有限上下文划分和聚合设计的最终决策，因为伟大的架构决策背后往往是对组织行为、团队分工和系统演进节奏的理解，这些背景信息 AI 拿不到，即使拿到了也很难准确权衡。

但 AI 能做一个非常具体、价值极高的事情：做那个每天 24 小时在线、不厌其烦、永远不会因为"这个问题听起来太基础"而跳过检查点的建模教练。它会追着问"这个命令对应的领域事件是什么""这两个聚合之间是通过什么机制同步状态的""这个值对象为什么需要独立标识"，它会把零散的业务描述整理成结构化的领域事件流，还会在建模完成后一次性给出需要人工复核的决策点清单。

这就是 cleanddd-skills 的设计出发点：把方法论变成流程，把流程变成可执行的 AI 指令链，让 AI 作为一个严格的"流程执行器"和"初步模型起草者"，把人从繁重的整理与推导工作中解放出来，去思考那些真正需要人来拍板的问题。

2. cleanddd-skills 是什么：把 DDD 全流程固化成 AI 工作流的技能包

2.1 技能包的组成：知识库、决策树、输出规范和检查清单

先说一下这个名字的来历：cleanddd 是我对自己这套工作法的叫法，本质上就是 Clean Architecture 与 DDD 的组合实践。skills 部分指的是 AI 技能包的标准形态——它不是一个装满代码的软件仓库，而是一套极其结构化的提示词工程产物，通常由一个主文件加若干辅助文件组成。

我拆解下来，cleanddd-skills 里真正起作用的是四个部分。

第一部分是方法知识库，把事件风暴的便签规则（橙色是领域事件、蓝色是命令、黄色是聚合、紫色是策略等）、聚合设计的基本判据（不变式、事务边界、生命周期）、上下文映射的几种关系（Partnership、Shared Kernel、Customer-Supplier、Conformist、ACL 等）以及 Clean Architecture 的依赖规则，全部写成 AI 可以直接调用的知识片段。

第二部分是提问决策树，这是技能包最核心的引擎。它规定了 AI 在建模的每个关键节点必须提出的问题清单和判断分支。比如进入一个业务场景时，先识别涉众和核心事件；出现一个候选聚合时，先检查它能否独立维护不变式；跨上下文出现协作时，先询问两个团队的协作模式而不是默认上防腐层。

第三部分是输出 Schema，规定了建模文档的固定结构：业务背景、涉众与角色、领域事件表、命令表、聚合清单、限界上下文清单、上下文映射关系、充血模型骨架。这个 Schema 的价值在于，它让 AI 的产出变得可审查、可对比、可迭代。

第四部分是自动检查清单，每完成一个阶段，AI 必须先跑一轮自检，把所有潜在问题列在"待人工确认"清单里，而不是直接说"建模完成"。

2.2 运行方式：把它看成你身边多了一个 DDD 陪练

安装 cleanddd-skills 的过程不复杂，凡是支持 Skills 或类似插件机制的 AI 编程工具都能跑，把技能包目录放到约定位置，然后在对话里通过一句话激活，比如"我想用 cleanddd-skills 对这套检验系统做一轮 DDD 建模"。

激活之后，它会要求你提供基础业务材料。理想情况下，你应该准备：一段业务介绍、主要角色和操作流程的说明、如果是已有代码库，再把核心模块结构发过去。材料越全，模型出图越快；材料不全，它会用对话方式一点一点问你。

我自己的使用习惯是把建模过程当作连续对话来维护，同一场建模的上下文保持在同一个会话里，不随便新开窗口。因为 DDD 建模是一个不断迭代的过程，事件风暴阶段发现的领域事件，会直接影响限界上下文的切分，进而影响聚合设计，最后影响代码骨架。中断上下文会让 AI 丢掉前面的推导链，重新找回来很费劲。

2.3 五阶段流水线：诊断、风暴、战略设计、战术设计、生成与评审

cleanddd-skills 的工作流程是五个阶段，顺序几乎不可调整，因为它是顺着 DDD 方法论的内在逻辑设计的，先战略后战术，先业务后技术。

第一阶段是需求诊断。AI 先不急着建模，而是围绕业务场景提问，目标是把业务范围画清楚：有哪些角色，核心业务流程是什么，有没有外部系统依赖，哪些环节目前是手工操作，哪些规则是行业合规要求。这个阶段的核心产出是一份"业务事实清单"。

第二阶段是事件风暴。AI 沿着时间线拉出业务全流程的领域事件序列——注意，这里是先找事件，再找命令，最后才找聚合。

第三阶段是限界上下文划分。AI 根据领域事件背后的语言差异，以及业务变化的频率和一致性要求，把模型拆分成若干个独立的上下文，并绘制上下文映射图。

第四阶段是战术设计。针对每个限界上下文，把聚合根、实体、值对象、领域服务、领域事件细化到代码级，同时确定仓储接口和应用服务的边界。

第五阶段是代码骨架生成与评审。按照 Clean Architecture 四层结构生成初始工程代码，并输出一份评审清单，把 AI 自己也不确定、需要人工拍板的点全部标记出来。

这个流水线设计的核心价值，在我看来不是快，而是"方向正确"。很多 DDD 项目做不下去，不是因为某个类写得不对，而是从事件风暴到上下文划分的中间环节出了偏差，越往后返工越贵。cleanddd-skills 把每一阶段的输入输出用 Schema 固定住，让偏差在早期就暴露。

3. 实战推演：用 cleanddd-skills 跑一遍实验室样本送检域建模

3.1 需求诊断阶段：AI 是怎么把模糊业务问清楚的

为了不落入电商订单的俗套，我选了实验室样本送检这个场景来做实战推演：门诊护士采集患者样本，生成样本管和条码，物流把样本运到中心实验室，实验室签收后安排检测，试剂上机出结果，审核后发布报告，如果结果异常还需要复核甚至重新检测。

我把这段描述丢给 AI，激活 cleanddd-skills 后，它问的第一轮问题是这样的："样本在运输过程中出现损坏，操作员是怎么处理的？是重新采集还是实验室拒收？""报告中出现异常值时，审核员的角色是复核还是直接不发布？""整条链路里，哪些环节是系统自动完成的，哪些必须人工干预？"

这些问题看起来琐碎，但每一个都在锚定建模边界。损坏后的处理路径，决定了你会不会在模型里多出一个"异常事件"以及对应的补偿流程；审核员的权限边界，决定了报告状态机的状态转移是否允许跳过审核直接发布；自动化环节识别的意义，是让我只关注真实有业务规则的地方。

我陆续回答完后，AI 生成了一份业务事实清单，并把所有角色列出来：护士（采集者）、物流司机（转运者）、实验室签收员、检测员、审核员、报告查看者。到这一步，我意识到它已经把业务全景拉出来了，后面的事件风暴有了足够扎实的底座。

3.2 事件风暴阶段：从领域事件反推命令，直到聚合现形

进入事件风暴阶段后，AI 沿着时间线先拉了一长串领域事件，这里我按它的推导逻辑重新整理了一遍，完整序列大致如下：

• SampleCollected（样本已采集）
• SampleCodeGenerated（样本条码已生成）
• SamplePickedUp（样本已被物流取走）
• SampleReceived（样本已被实验室签收）
• TestScheduled（检测已安排）
• TestStarted（检测已开始）
• TestCompleted（检测已完成）
• ResultValidated（结果已通过审核）
• ReportReleased（报告已发布）
• SampleRetested（已发起重新检测）
• ReportRevised（报告已修订）

这里有两点值得留意。第一，AI 先拉事件而不是先画实体，这是事件风暴方法论的硬性要求——事件是业务已经发生的事实，是不可否认的，而实体往往带着建模者的主观预设。第二，"SampleRetested"和"ReportRevised"这两个事件是我在给 AI 补充业务信息时提到的"异常值复检流程"的产物，说明事件风暴阶段特别容易遗漏补偿性事件，而 AI 的提问决策树里刚好包含了"除了正常主链路，是否存在回退、重试、取消、补偿流程"这条检查分支，帮助追回来了。

事件序列拉完后，AI 开始反推每个事件对应的命令（Command），我把它整理成了事件-命令对照表：

这张表的出现，标志着已经从"讲故事"进入了"建模"。接下来 AI 做了一件我认为最体现技能包价值的事情：它会对每个命令追问一句"这个命令是否会跨越多个对象的生命周期？修改后是否需要同时满足多个对象的不变式？"——这正是识别聚合边界的关键判据。

以 Sample 聚合为例，从 SampleCollected 到 SampleReceived 这一串事件，都围绕着同一个物理对象（样本管）的状态迁移，而且每一步都要求样本管的状态不可跳变，等于这个聚合维持着一个强一致的状态机，所以这些命令天然归属于 Sample 这个聚合。

而 TestScheduled 这个命令，表面上看是在操作样本，但其实在业务层的语义是"把样本分配到一个检测批次中"，它关心的是批次和检测项的分配，而不是样本条码本身，所以独立出来一个 TestOrder 聚合更合适。这里 AI 没有直接把所有跟样本相关的东西揉成一团，而是根据"是否处于同一条强一致状态链"来切，让我很意外。

3.3 限界上下文划分：三个上下文，每个都有自己的"样本"模型

事件和聚合列表出来后，AI 进入战略设计阶段，核心任务是划分限界上下文。它用的判据是业务语言一致性，也就是同一个词在不同语境下是否代表了不同概念。

"样本"这个词，在三个不同阶段含义有明显的差异：

• 在样本采集与物流上下文里，"样本"指的是"贴了条码的物理试管"，关心的属性是条码号、采集时间、采集位置、运输状态，不关心检测结果。
• 在检测执行上下文里，"样本"关心的是它所属的检测批次、检测项目、上机时间、是否满足检测前置条件，条码只是唯一标识。
• 在报告发布上下文里，"样本"则被抽象为"检测对象"，关注的是它的各项结果值、参考范围、异常标记。

同一个物理事物，在三个上下文中的模型完全不同，这恰恰说明必须拆成三个限界上下文，否则一个 Sample 类会膨胀到无法维护。

AI产出的上下文划分是：样本采集与物流、检测执行、报告发布，外加一个对所有上下文提供基础主数据（如检测项目、参考范围）的支持上下文。上下文映射关系上，AI 没有粗暴地给所有关系都加防腐层，而是让"采集与物流"上下文作为上游，"检测执行"作为下游形成 Customer-Supplier 关系；"报告发布"与"检测执行"之间由于确实分别属于不同的运维团队和发布周期，才建议使用防腐层。这个判断就比早期版本合理很多。

3.4 战术设计与代码生成：Clean Architecture 四层一次性铺开

限界上下文确定后，AI 进入战术设计。以"检测执行"上下文为例，它产出的领域模型包括：TestOrder 作为聚合根，维护检测批次和同一批次下的样本集合；SampleTestResult 作为实体，拥有独立的生命周期；SampleCode、ReferenceRange、TestStatus 作为值对象；TestOrderService 作为领域服务处理"分配样本到批次"这种需要跨实体的逻辑。

全套模型生成后，AI 按 Clean Architecture 的依赖规则输出了工程骨架。包结构大致是这样的：

com.lab.lims ├── domain │ ├── testorder │ │ ├── TestOrder.java │ │ ├── TestOrderRepository.java │ │ ├── SampleTestResult.java │ │ ├── TestStatus.java │ │ └── SampleCode.java │ └── event │ ├── TestScheduledEvent.java │ ├── TestCompletedEvent.java │ └── ResultValidatedEvent.java ├── application │ ├── TestOrderApplicationService.java │ └── dto │ ├── ScheduleTestCommand.java │ └── CompleteTestCommand.java ├── infrastructure │ ├── persistence │ │ └── TestOrderJpaRepository.java │ └── messaging │ └── DomainEventPublisher.java └── interfaces ├── rest │ └── TestOrderController.java └── consumer └── SampleReceivedConsumer.java

我随机抽查了 TestOrder 聚合的实现，发现依赖方向是符合 Clean Architecture 要求的：领域层不依赖任何 Spring 注解和基础设施类，仓储接口定义在领域层，基础设施层的 JpaRepository 只是适配实现。这个骨架拿去直接开发，至少省掉了两个工作日的搭建时间。

需要注意的是，AI 生成的只是骨架，里面的业务规则还是空的。比如"样本到达实验室后，必须在 4 小时内完成签收确认"这种时限规则，它只会给你留一个注释为 TODO 的方法。真正把业务逻辑填充进去，仍然需要你对自己的领域有足够理解。

4. 中间踩过的三个硬坑：AI 建模结果真的不能直接信

4.1 值对象满天飞转实体：条码不是一条可独立追踪的记录

我最早用这套技能包建模时踩的最大的坑，是 AI 倾向于把值对象建模成实体。典型例子就是 SampleCode 样本条码。

理论上讲，条码只是一串无状态的字符序列，它没有独立的生命周期，不可能被单独修改，更不可能发生状态迁移。它描述的是"这个样本管的身份的标签"，替换它表达的是"换了个标签"而不是"这条条码从一个状态变成另一个状态"。所以它是教科书标准的值对象。

但早期的 cleanddd-skills 在建模"检测执行"上下文时，竟然给 SampleCode 单独建了一张表，还配了一个 CodeRepository，理由是"它需要被单独查询，用来反查样本信息"。这就是典型的把"查询需求"和"建模需求"混为一谈了。样本条码查询频率高，本质上是因为它作为样本的标识被广泛使用，这只需要在样本表上建唯一索引就够了，不需要为编码单独建实体和仓储。

发现这个问题后，我在技能包的提问决策树里加了一条强制规则：任何候选对象都必须依次回答五个问题——它有独立生命周期吗？它会被单独发起命令修改吗？它会被多个聚合共享引用吗？它是否承载了某种需要跟踪的状态？它的相等性是通过标识还是属性值判断？五个问题全部回答完，AI 必须给出判断理由，而不能再凭"感觉像实体"来建模。

4.2 聚合边界：要么巨型聚合，要么碎一地

第二个坑是聚合边界的两个极端。

早期版本有一种倾向，是把"检测执行"上下文里的 TestOrder、SampleTestResult、检测规则、参考范围全部塞进一个巨大的 TestOrder 聚合里，理由是"它们都是围绕检测开展的东西"。结果就是这个聚合在一个事务里要锁一大堆数据，并发一高，问题就出来了。而且每次加载一个聚合，要把所有包含的子实体全部查一遍，性能开销很大。

反过来，在"C 端用户下单"这种业务里，它又可能把一个强一致的流程拆成三个聚合，让它们通过领域事件最终一致，理由仅仅是"用户下单和支付是两个不同的操作流程"。但实际上，下单和支付虽然在时间上有先后，它们共享同一个核心不变式"订单不能超卖"，这恰恰是聚合应该保护的一致性边界，拆开之后超卖风险就变成分布式问题了。

我的解决办法，是在技能包中加入了"聚合分裂提示"规则：当一个聚合包含超过五个实体，AI 必须主动问一句"是否可以拆成独立聚合，并通过领域事件进行最终一致的同步？"反过来，当两个聚合之间需要通过领域事件维护强一致关系时，AI 必须提示"这里是否存在共享的不变式，是否应该合并为一个聚合？"这两条规则把聚合设计从"凭感觉"拉回到了"基于不变式和事务边界"的轨道上。

4.3 上下文映射图：AI 真的会让全世界都变成防腐层

限界上下文划分出来之后，AI 绘制上下文映射图时还会踩第三个坑：它对防腐层（ACL）的使用过于慷慨。在早期的输出里，几乎每一个跨上下文交互，它都建议加一个防腐层。

这个判断在理论上没错，但在工程上却是高成本的。防腐层的本质是模型翻译器，当上游的模型语言会污染下游的通用语言，或者上游系统是完全不可控的外部系统时，才值得用。它带来的额外成本包括：一层映射代码、一层转换测试、以及每次上游变化后的同步维护成本。如果所有的跨上下文关系都上防腐层，这套系统的维护代价会非常惊人。

在实验室这个场景里，"样本采集与物流"上下文和"检测执行"上下文其实是同一个团队在维护的，两个上下文之间的数据模型确实存在差异，但团队完全可以通过约定的 API 直接对接，用 Customer-Supplier 关系来约束，根本不需要防腐层。而"报告发布"上下文如果未来要对接一个外部的体检平台，那个场景才值得认真做 ACL。

这个坑的终极原因，是 AI 无法感知组织结构和团队协作模式。它只能从纯技术角度判断，而语义差距和团队协作方式恰恰是人在 DDD 建模里最不可替代的判断依据。所以我在最终版的技能包里写死了这条规则：所有防腐层建议必须标注"依赖团队协作模式判断，默认不推荐"，把决策权交还给人。

5. 怎么验证 AI 的产物：我沉淀出的一套 Review 流程

5.1 五问校验法：每个建模结果都要过一遍

不管 AI 的产出看起来多完美，我在把它变成正式设计文档或代码之前，一定会按下面的五个问题逐一审查。这五个问题不是从理论书里抄的，是我在多个项目里反复试错后沉淀出的最有效的过滤器。

第一个问题：每个概念在业务语言里真实存在吗？DDD 强调通用语言，建模里的每个类名，都应该能说人话，医生听得懂，护士也听懂了，这个类才具备领域含义。如果 AI 生成了一个叫"TestOrderStateSynchronizer"的类，我会直接怀疑它是在技术层面硬造概念，而不是源自业务语言。

第二个问题：这个聚合的不变式是什么？如果答不上来聚合到底在保护什么规则，那这个聚合的边界大概率画错了。聚合并不仅仅是一组对象的容器，它的存在是为了在并发环境下保护某个业务规则不被破坏。没有不变式的聚合，本质上只是一个普通对象集合。

第三个问题：事务边界是不是严格约束在一个聚合内？跨聚合事务在 DDD 里是明确反对的。我拿到 AI 生成的代码后，会先扫描所有带 @Transactional 注解的方法，看有没有一个事务里操作了多个聚合根。如果有，要么是聚合划分有误，要么必须改成通过领域事件达到最终一致。

第四个问题：依赖方向是否一致指向领域层？这个比较简单，用代码检查工具就能覆盖，但 AI 在生成 Spring 项目时经常顺手把 Repository 注解灌进领域层，所以我仍然会把这一检查放在人工 Review 清单里。领域层应该是全项目最干净的一层，不依赖任何框架细节。

第五个问题：这个模型能不能承受未来三个月的演进？这是最难回答，也最考验经验的一个问题。我会对着建模文档问自己：如果下周要新增一个"临床决策支持"上下文，它会不会侵犯现有上下文的边界？如果要接一个外部报告推送平台，是加一个端口适配器就能解决，还是需要改动领域层？如果答案是需要改动领域层，说明当前模型里混入了不该有的技术假设。

5.2 上下文映射图的最终裁定权，必须留在人手里

每轮 Review 的最后，我会把 AI 输出的上下文映射图当成一份"备选方案"，而不是结论。AI 在对业务没有深入认知的情况下给出映射关系，这决定了它无法感知组织结构、团队协作模式、系统未来的所有权变化，而这些恰恰是决定两个上下文之间到底用 Partnership、Customer-Supplier 还是 ACL 的关键因素。

我见过一个真实的例子：两个系统之间的模型冲突非常严重，从技术角度分析，加防腐层绝对正确。但实际上这两个系统的维护团队马上就要合并成一个团队，模型冲突可以通过团队内的直接沟通来缓解。这时候硬加防腐层就变成过度设计。这种基于组织演进的判断，AI 再强也算不出来。

所以我给 cleanddd-skills 里的上下文映射表加了一个固定输出字段——"决策依据"，要求 AI 在给出映射类型时必须注明它是基于技术语义差距、系统边界、还是团队协作假设给出的判断。下一步我就能快速识别哪些映射是客观的技术结论，哪些只是 AI 的推测，然后针对推测部分专门找业务和团队负责人去确认。

5.3 建模文档的管理：让模型持续演进，而不是一次定稿

还有一个实操层面很容易被忽略的问题：建模文档的管理。DDD 模型不是一次会议就能定稿的，尤其当系统在持续迭代时，领域模型必须随着业务认知的加深不断演进。我现在的做法是把 cleanddd-skills 每次产出的建模文档作为独立文件提交到版本库，和代码一样走评审、合并流程。

这样做的直接好处有三个：第一，模型变更与代码变更有迹可循，出现"模型和实现脱节"时能快速定位是哪个迭代引入的偏差；第二，新成员入职时，直接看建模文档比翻代码理解业务快得多，尤其当文档里保留了每个边界划分的决策理由；第三，每次业务方提出新需求时，我可以先把需求丢给 AI，基于现有建模文档做增量推导，而不是每次从零开始。

我个人的体会是，AI 不会让 DDD 变简单，但它彻底解决了"对着空白画布发怵"的问题。以前启动一个新项目，从业务梳理到第一个可以工作的骨架，我至少要花一周；现在用 cleanddd-skills 跑完五阶段，拿到一份带评审清单的建模文档和一套 Clean Architecture 骨架，一个周末就够了。但真正重要的不是快，而是每一次判断都有了可追溯的依据，模型里的每一个关键决策都经得起追问。

这套技能包目前还在持续迭代，我近期在补的方向是事件表驱动测试：既然事件风暴阶段已经把领域事件都列出来了，可以把事件序列直接生成集成测试的骨架，让测试跟着模型走。如果你也在 DDD 落地的路上挣扎，我的建议很简单——别去读第十遍书，拿一个真实业务跑一轮事件风暴，让 AI 当你的陪练，你会比我当年困在书桌前更快地捅破那层窗户纸。