未来的软件系统，很可能不再依赖大量手写的代码，而是依赖可验证的业务规范，以及对这些规范的自动化实现。\ ——这正是从 DDD → SDD + TDD 的演进方向。

在 AI 深度参与软件开发的时代，传统的代码中心开发方式正在加速老化。\ 我们正在经历一次结构性转变：\ 从“写代码”转向“写规范 + 写测试 + 让 AI 自动补全逻辑”。

这篇文章试图提供一个前瞻性的观点（深度使用 vibe coding 近半年后的想法）：\ 领域驱动设计（DDD）将演进为以规范为核心的 SDD（Spec-Driven Development），并与 TDD 深度融合，形成未来 AI 自动化开发的基础范式。

Auto-Coding 示意图

graph LR
    DDD --> AI(AI Driven)
    AI --> SDD1["SDD(Self-Containd)"] --> AI_apply[AI Apply] --> TDD[TDD] --> AI_last[AI complete]
    AI --> SDD2["SDD(Self-Containd)"] --> AI_apply
    AI --> SDD3["SDD(Self-Containd)"...] --> AI_apply
    AI_last --> |Auto Coding| AI_apply    

TLDR;

一、DDD 为何不足以支撑 AI 时代？

DDD 提供了：

• 领域建模
• 领域语言（Ubiquitous Language）
• 聚合、实体、值对象等结构
• “业务先行”的思想

这些思想极其重要，但它有一个天然的短板：

DDD 不提供可以被机器直接消费的“规范化结构”。

DDD 写成文档、白板图、人类可读的分析，但对机器而言，它仍然太模糊：

• “库存不足自动补货”
• “支付成功触发发货流程”
• “用户注册后发送邮件”

这些是业务描述，但不是机器可执行的规则。

因此：

传统 DDD 让 AI 无从下手，而 SDD（规范驱动开发）提供了突破口。

二、SDD：把领域知识转化为“可执行规范”

SDD（Spec-Driven Development）是什么？

它强调：

先以业务规范（Spec）定义领域行为，再让代码（甚至 AI 自动化生成）去满足规范。

SDD 不像 PRD，也不是 UML，也不是流程图。\ 它是：

• 结构化
• 机器可读
• 可验证
• 可生成代码框架
• 能被 AI 理解和执行

的“业务行为规范”。

例如：

domain: order

events:
  - OrderCreated
  - PaymentCompleted

rules:
  - name: auto_ship
    on: PaymentCompleted
    do: ShipOrder

这是机器可理解的。\ AI 可以从这里生成：

• 事件处理器
• 状态变迁逻辑
• 接口
• 验证代码
• 文档
• 测试样例

而人类只需要写规范。

SDD 是 DDD 的“可执行层”。\ DDD 提供思想，SDD 提供让机器执行的内容。

三、TDD：为 AI 自动生成代码提供 “审判官”

当我们有了可执行规范（SDD）之后，下一步是什么？

不是直接写代码。\ 而是：

用 TDD（测试驱动开发）来验证 AI 是否正确实现了规范。

TDD 在 AI 时代获得了全新地位：

• 人不再需要自己手写所有逻辑
• AI 会填补大量代码细节
• TDD 成为检验 AI 代码是否符合规范的关键
• 测试变成整个体系的“法律裁决者”

在 TDD 中，一个领域规则被验证为：

Given 某状态
When 某事件发生
Then 应产生某行为

它和 SDD 的事件模型天然对齐。

例如：

Scenario: Payment triggers shipping
  Given order is created
  When PaymentCompleted event is received
  Then order should become Shipped
  And OrderShipped event should be emitted

AI 可以据此自动修正代码，直到测试通过。

四、DDD → SDD + TDD：未来开发流水线的雏形

以下是未来项目的典型流程：

1. DDD（定义领域语言与边界）

• 识别领域
• 建立实体/聚合
• 统一语言
• 事件与状态变化的含义

DDD 是战略层，它定义“是什么”。

2. SDD（生成业务规范：机器可读）

将 DDD 转化为结构化规范：

• 事件
• 命令
• 规则
• 状态流转
• 约束条件
• 权限模型
• 输入/输出契约

SDD 是执行层，它定义“应该怎样”。

3. TDD（验证业务规范是否正确实现）

AI 自动根据 SDD 生成初始代码框架后：

• 用 TDD 的验收测试校验实现
• 测试失败 → AI 修复
• 测试通过 → 规范被落实

TDD 是守护层，它定义“是否满足规范”。

4. AI 自动补全逻辑

AI 根据 SDD + TDD 自动生成：

• 事件处理器
• 数据访问层
• API 层
• 文档
• 部署脚本
• 可观测性
• 甚至自动化 CI/CD

开发者从“写代码”转向：

写规范（SDD） + 写验证（TDD）

代码由 AI 完成

业务由 DDD 驱动

五、为什么 DDD → SDD + TDD 是未来？

三个不可逆的趋势在合力推动：

趋势1：AI 正在吞噬手写代码

日常代码（Curd、API、Repository）\ 已经能由 AI 几乎零成本生成。

未来开发者不需要写这些。

趋势2：业务变化比技术变化更快

业务规则每天在变：

• 新政策
• 新定价
• 新流转规则

用规范驱动业务，比改代码快十倍。

趋势3：可验证的系统成为核心诉求

随着 AI 自动写代码，真正重要的就变成：

• 如何描述业务行为
• 如何验证行为正确
• 如何确保一致性与可追踪性

这正是 SDD + TDD 的价值所在。

六、扩展：事件驱动（EDD）作为天然的结合层

DDD 和 SDD 都强调“领域事件”\ TDD 也以事件触发逻辑为基础。

因此未来的系统几乎全会是：

事件驱动的系统\ （事件是行为主线，规范是规则，测试是验证）

其优势在于：

• 更易建模
• AI 更易理解
• 更适合自动生成与验证
• 更符合人类对业务行为的描述方式

七、未来开发者的角色将彻底改变

现在：\ 开发者 → 写代码、写接口、调试、修 bug

未来：\ 开发者 → 写规范、定义领域、设计业务规则、写测试

AI → 自动生成代码、复写、修复、优化

开发者成为“业务逻辑的法官”，不是“代码的工人”。

八、结语：软件开发的未来从 DDD 继续前进

DDD 不会消失，它会成为软件系统的哲学基座。

但真正能与 AI 深度结合的，是：

• SDD：让业务规则可结构化、可验证、可生成
• TDD：让 AI 的实现可检验、可纠正、可可靠

未来的主流开发方式将会是：

DDD（理念） → SDD（规范） → TDD（验证） → AI（实现）

这是一个比过去任何开发范式都更清晰、更可控、更自动化的未来。

而这条路径，也许正是未来 5～10 年软件工程的主干路线。