一套可验证的 DDD 建模技能流水线：从模糊需求到聚合模型的工程化落地

一套可验证的 DDD 建模技能流水线：从模糊需求到聚合模型的工程化落地

本体系由 8 个 AI Agent Skill 组成 4 阶段流水线（发现→战略→战术→验证），以 SKILL.md 7 节合约固定输入输出类型，以 10 条数值化回溯触发器实现非线性反馈，以 6 步盲跑方法提供外部评分基线。Cargo Shipping 首轮验证：加权 85.8 %，回溯触发器 3/3 全通过。

引言

领域驱动设计提出已逾二十年，落地却始终依赖少数资深建模者的经验直觉。Eric Evans 在 2003 年奠定了战略与战术的双层框架，Alberto Brandolini 用事件风暴让协作建模走进了工作坊，Vaughn Vernon 的实施手册让 Aggregate 和 Bounded Context 有了操作指南——但"一个人带不走一个工作坊"的困境从未真正被解决。建模者离开，模型就停止演进。

本文以一个开源实验——"DDD 技能聚合仓库"为样本，说明如何把领域建模切分为 8 个边界清晰、可串行可回溯、并能用真实案例评分的 AI Agent Skill。其中 Cargo Shipping 验证案例取得加权 85.8 %、回溯触发器 3/3 全通过的成绩，将"建模能不能被工程化"这一老问题重新推到可度量的工作面上。

如果你正在犹豫"要不要让 AI 辅助我的团队做 DDD"，这篇文章提供的不是一个承诺，而是一组数字和一套可复现的验证方法。

一、背景：DDD 与 AI Agent 的双向奔赴

"领域驱动设计"和"AI Agent Skill"分别成熟于不同的年代，却在 2024–2026 年的交汇窗口产生了化学反应。一侧是方法论的稳定态——理论已无大争议、实践却仍高度依赖人；另一侧是 Skill 形态的工程范式——把原子能力封装为可组合、可调用的单元。两股力量碰撞出一个核心诉求：让隐性的建模思考路径变成显性的 Skill 合约。

1.1 DDD 方法论的稳定态

DDD 的知识结构已经相当稳定。战略层面，Bounded Context 与 Ubiquitous Language 构成宏观骨架，Context Map 定义了上下文间的协作拓扑；战术层面，Aggregate、Entity、Value Object、Domain Event 则是微观构件。从 Evans 的蓝皮书到 Vernon 的红皮书，从 ddd-crew 的 Starter Modelling Process 到社区的 Event Storming 实践，核心模式的语义已高度固化。

然而方法论的固化并没有带来交付的一致性。Event Storming 的产出停留在便利贴上，聚合设计的决策存在于架构师的脑中，Ubiquitous Language 写入 Wiki 后再也无人维护。方法论口头高频被用，却很难沉淀为可重复执行、可机器解析的制品。

1.2 AI Agent Skill 的工程范式

AI Agent 的 Skill 形态提供了一种全新的承载介质。一个 Skill = 一段带 YAML 元数据的 Markdown 提示词 + 显式的 Input/Output/Process/Checklist。它不是一个黑箱模型，而是一份结构化的"认知合约"——告诉 Agent 在什么条件下启动、按什么步骤执行、用什么格式输出、以及何时判定自己完成或需要回退。

@skill-name 的调用模式天然适配 DDD 建模：同一业务问题需要多轮专业化推理——先发现领域边界，再划分上下文，再设计聚合内部结构——这恰好是多个 Skill 接力完成的任务。

1.3 交汇点

上述方法论与 Skill 形态在交汇处提出了一个核心诉求：让资深建模者的隐性思考路径，以显性 Skill 合约沉淀下来，使中等经验的工程师（或 AI Agent）也能跑出 80 分以上的领域模型。

这不是要替代专家，而是要把专家的决策框架编码为可重复执行的步骤，让团队不再因为"没有那个人"就建不出模型。

二、问题：为什么现有 DDD 技能生态仍然"不可信"

交汇点的诉求足够诱人，但现有生态的三条结构性短板——碎片化、无契约、无验证——让"AI 辅助 DDD 建模"长期停留在演示阶段。任何一个认真评估过的技术负责人都会问：我凭什么信任这些 Skill 的产出？

2.1 碎片化：20+ 外部 Skill 各行其是

开源社区已经涌现了大量 DDD 相关 Skill。antigravity-awesome-skills 提供了 ddd-strategic-design 和 ddd-context-mapping；claude-skill-registry 有 ddd-planning；wondelai-skills 有通用的 domain-driven-design；cleanddd-skills 提供了 .NET 平台的四阶段工作流；aiee-team 专注 Python 生态的 arch-ddd。

问题不是"太少"，而是"太碎"。这些 Skill 各自定义命名规范、阶段划分、交付物格式。有的只做战略，有的直接跳到代码生成，有的把事件风暴和聚合设计混在一步里完成。结果是阶段覆盖有洞、概念重复有冗余，难以组装成端到端流水线。A 仓库的"事件风暴"输出无法直接传递给 B 仓库的"聚合设计"——它们说的不是同一种语言。

2.2 无契约：Skill 输出随机漂移

缺乏统一的接口约束意味着同一 Skill 在不同会话中给出的粒度、字段、层级都不稳定。第一次跑，它给你一张包含 6 列的表格；第二次跑，变成了 3 段散文。这对下游消费者——无论是人还是 Agent——都是灾难。

下一个 Skill 无法预期前一个 Skill 会给它什么。 如果 ddd-aggregates 不知道 ddd-contexts 会输出一张格式固定的"上下文目录"表，它就不得不在每次执行时重新猜测输入的结构。这种不确定性在多步流水线中逐级放大，最终使整条链路变得不可信赖。

2.3 无验证：没有真值、没有评分、没有回溯

行业里几乎没有"把某 DDD Skill 放在经典样本上盲跑并打分"的公开案例。所有的改进都是基于直觉："这个 Skill 感觉输出不太对，我调整一下 prompt"——没有基线，没有度量，没有证据。

没有打分就没有反馈闭环。Skill 无法沿着证据迭代，一切改动都靠手感。 更糟糕的是，当建模过程出现问题时，没有任何机制能告诉你"应该回到第几步修正"。整条链路是单向的、不可逆的——这与真实的领域建模过程（非线性、需要反复校正）形成了根本矛盾。

三、方案：8 Skill × 4 阶段 × 验证方法的三位一体

针对上述三条短板，DDD 技能聚合仓库提出一个三位一体的答案：以 4 阶段流水线给碎片定骨架、以 SKILL.md 合约给输出定契约、以盲跑验证方法给迭代定证据。本节沿着"骨架 → 合约 → 反馈 → 验证 → 实证"的过程叙事逐层展开。

3.1 骨架：四阶段线性主路

碎片化问题的根源是缺少一条公认的主路。体系主干采用 4 个阶段，代表 4 种不同类型的建模工作——从发散探索到精确设计再到批判审查：

8 个 Skill 覆盖了从"我们在解决什么问题"到"模型是否一致、完整、可实现"的完整认知链。每个 Skill 在一次对话轮次内产出结构化工件，工件直接流入下游 Skill 的输入——像流水线上的标准件一样可衔接。

关键认知：主路不是"瀑布"。它给出的是一个推荐执行序列，但系统同时支持 5 种非顺序入口——已有需求可从 ddd-discover 切入，子域已知可直接进入 ddd-contexts，已有模型可用 ddd-model-review 做体检。骨架不是牢笼，而是高速公路的主干道。

3.2 合约：SKILL.md 接口规范

把主路上的每个 Skill 接上同一套接口合约，才能让它们真正互相调用。合约强制 7 节结构，每一节都有明确的职责定义：

1. 1. YAML Frontmatter——name、description、risk、source、tags、date_added，让机器可以发现与索引。
2. 2. 使用时机——何时调用、前置条件是什么，避免误触发。
3. 3. 输入要求——上游必须提供什么（标注来源 Skill），可选输入有哪些。
4. 4. 流程——5-7 步执行步骤，Agent 按序操作。
5. 5. 输出——表格化产出，列字段固定，下游可直接消费。
6. 6. 校验清单——本 Skill 的退出门禁，所有条目通过后方可交付。
7. 7. 回溯触发——触发返回上游 Skill 的具体条件与阈值。

这套合约解决的是"输出漂移"问题。以 ddd-aggregates 为例，它的输出被固定为 6 张表：聚合目录、不变量表、实体与值对象清单、事务边界说明、跨聚合一致性策略、仓储接口草案。每张表的列名、含义、结构要求都写在合约里。输入输出都被写成类型——Agent 之间才谈得上组装，就像函数之间传递的是强类型参数而非随机字符串。

3.3 反馈：非线性回溯触发器

合约中的回溯触发（Backtrack Triggers）一节不是装饰，而是整个系统区别于线性流水线的关键机制。真实建模从来不是一次通过：聚合设计做完才发现上下文边界划错了，事件目录写完才发现术语冲突无法调和。

体系定义了 10 条结构化的回溯规则，覆盖从阶段 IV 到阶段 I 的全链路反馈。其中最核心的 5 条：

触发器的价值在于把"经验判断"转成"数值门限"。当 ddd-model-review 计算出某一维度低于阈值时，它不需要请示人类专家就能决定回退到哪个 Skill 重新执行。同时，为防止无限循环，系统规定同一回溯路径最多执行 3 次——若第 3 次仍触发，标记为"需人工介入的架构决策"。

这套机制让 Agent 在没有人类专家在场时也能自主选择回退深度——它不是简单地"从头再来"，而是精准定位到出问题的层级。

3.4 验证：六步盲跑方法

触发器有了，还需要一把外部尺子来判定 Skill 组合是否真的"达标"。仅靠 Skill 自身的校验清单无法证明整条链路的有效性——你需要一个独立于系统的真值源。

验证方法固化为六步闭环：

步骤 1：构造模糊输入。 从参考实现出发，改写出一份 500–800 字的业务简报——仅含业务场景、角色、目标、约束，剔除所有 DDD 术语与参考实现的类名。这确保了 Skill 是在"真正不知道答案"的条件下执行。

步骤 2：盲跑 8 Skill。 严格按 4 阶段顺序执行，每一步只读当前 Skill 规定的上游产出。盲跑纪律要求执行过程中不得引用真值文件——只有全部 8 个 Skill 产出完毕后，才可进入评分阶段。

步骤 3：抽取真值。 从参考实现的源码、架构文档、测试用例中独立抽取上下文、聚合、事件、集成映射四类真值，放入 reference/ 目录。真值与盲产出完全隔离。

步骤 4：对标评分。 按 Skill 影响力分配 1.0–2.0 权重（合计 11.0），用 0–4 五档标准评分。评分规范包含"A 类锚点"（必须命中的关键概念）和"B 类加减分"（正向越位 / 反模式），确保分数可复核、可重复。

步骤 5：回溯注入测试。 对盲产出主动注入可控缺陷（如删除大部分不变量、让只读聚合承担业务判定），然后重跑 ddd-model-review，验证触发器能否正确激活并路由到预期目标。

步骤 6：汇总报告。 产出包含 8 节结构的最终报告：执行摘要、验证范围、评分总览、回溯测试结果、关键发现、改进建议、工件目录、结论。

三条关键约束使这套方法可信：盲跑纪律保证了评估的客观性；真值独立抽取保证了基线的可靠性；注入测试保证了反馈闭环的功能性。