AI时代的领域驱动设计：DAD

在 AI 开始直接参与系统交互之后，传统领域驱动设计（DDD）暴露出一个根本性局限：

系统长期只理解“结构”，却不真正理解“意图”。

无论是方法调用、DTO、RPC 还是事件消息，本质上都是结构化协议。
而在真实世界中，尤其是 AI 参与的场景里，交互首先出现的是语义意图，而不是稳定结构。

DAD（Domain Actor Design），是一种面向 AI 时代的领域建模方式，其核心系统单元是 AI Actor。

---

一、Actor 模型：不是并发技巧，而是领域单元

Actor 模型的本质是：

• Actor 是独立运行的实体

• Actor 之间只通过消息交互

• Actor 内部状态不可被外部直接访问

• Actor 自行决定如何处理收到的消息

Actor 模型真正解决的是：

如何在不共享状态、不直接调用的前提下，让复杂系统保持自治。

在 DAD 中，Actor 不再只是并发模型，而是领域的最小自治单元。

---

二、传统 DDD 消息化后的真实问题

即便系统已经采用“消息驱动”：

• 消息依然是固定结构

• 接收方必须提前知道结构

• 发送方必须知道对方能处理什么结构

结果是：

领域之间的耦合，从方法签名，转移成了消息结构。

在 AI 时代，这种问题被进一步放大：

• AI 产生的输入天然不稳定

• 表达可能正确，但结构不完整

• 系统无法容忍“语义正确但结构不完美”的请求

---

三、DAD 的核心单元：AI Actor

在 DAD 中，领域的最小自治单元是 AI Actor。

AI Actor 由三个部分组成：

Agent + Mailbox + 领域服务程序

这是一个职责清晰、边界严格的结构。

---

四、AI Actor 的三个组成部分（最终定义）

1️⃣ Agent：AI Actor 的唯一边界

Agent 才是 AI Actor 的物理与逻辑边界。

所有进入 Actor 的信息，必须先经过 Agent。

Agent 的职责是：

（1）语义解析与校验（入口关卡）

• 接收外部消息（JSON / 文本 / 混合）

• 判断：

  • 对方想做什么

  • 信息是否语义完整

  • 是否属于当前 Actor 的职责范围

❌ 不合格的消息：

• 直接返回语义化错误

• 告知问题在哪里、缺什么

• 不会进入领域执行路径

结构正确 ≠ 语义合法

---

（2）意图 → 结构化任务

当语义被确认后，Agent 会：

• 将“意图”转换为结构化任务

• 明确：

  • 任务类型

  • 已确认的数据

  • 执行前置条件

Agent 不决定如何执行，只负责：

把“我理解了”变成“你可以执行了”。

---

（3）执行结果的语义化输出（出口）

领域服务程序执行完成后：

• 返回的是结构化执行结果

• Agent 负责：

  • 解释执行结果

  • 组织语义响应

  • 返回给原消息发送方

Agent 是唯一的语义入口，也是唯一的语义出口。

---

2️⃣ Mailbox：领域服务的任务串行化机制

Mailbox 不是 AI Actor 的边界，也不承担语义职责。

Mailbox 的唯一目的：

保证领域服务任务的顺序性与一致性。

它的特点是：

• FIFO

• 可持久化

• 只存结构化任务

• 不理解任务含义

• 不参与任何业务决策

Mailbox 的存在意味着：

• 领域服务程序只面对确定、可执行的任务

• Actor 内部状态不会被并发破坏

• Actor 可以安全重启并恢复执行

---

3️⃣ 领域服务程序：Actor 的执行体

领域服务程序是：

一个持续运行、由 Mailbox 驱动的 Actor 执行体。

它内部包含：

• 执行循环

• 状态机

• 领域对象代码

• 业务规则

• 状态 / 事件持久化逻辑

领域服务程序的特征非常明确：

• 只接收结构化任务

• 串行执行

• 不解析语义

• 不暴露方法

• 不直接与外部通信

领域对象代码全部存在于领域服务程序内部。

---

五、AI Actor 的完整消息处理流程（最终闭环）

这是 完整且不可省略的 AI Actor 消息生命周期。

---

① 外部消息到达 Agent（Actor 边界）

• 来自用户 Actor

• 来自其他领域 Actor

• 或外部系统

---

② Agent 进行语义解析与校验

Agent 判断：

• 意图是否明确

• 数据是否语义完整

• 是否在 Actor 职责范围内

❌ 不合格 → 立即语义反馈
✅ 合格 → 生成结构化任务

---

③ 结构化任务进入 Mailbox 排队

此时进入 Mailbox 的是：

已被理解、已被确认、可执行的任务

---

④ 领域服务程序从 Mailbox 取任务

• 顺序取出

• 加载当前状态

• 进入状态机执行

---

⑤ 领域对象代码执行任务

• 执行业务规则

• 推进状态

• 产生状态变化 / 领域事件

---

⑥ 状态 / 事件持久化

• 记录任务

• 记录执行结果

• 记录状态演进

---

⑦ 领域服务程序返回结构化执行结果给 Agent

结果是：

• 无语义包装

• 无协议假设

• 完全确定性的

---

⑧ Agent 将结果转为语义消息并返回对方

• 解释发生了什么

• 描述当前状态

• 告知后续可执行意图

---

六、DAD 相比传统 DDD 的本质变化

传统 DDD	DAD
方法调用	语义消息
DTO 契约	意图驱动
聚合根	AI Actor
应用层编排	Actor 自治
状态快照	状态演进
结构耦合	语义解耦

---

七、总结

DAD 不是给 DDD 加 AI，
而是承认：在 AI 时代，系统必须先“理解”，再“执行”。

AI Actor 用清晰的三段结构保证这一点：

• Agent：唯一边界，负责理解与表达

• Mailbox：串行化机制，保障一致性

• 领域服务程序：确定性执行体

没有直接调用，没有结构耦合，只有被理解后的意图驱动执行。

这，才是 AI 时代的领域驱动设计：DAD。