引言
在 AI 被引入业务系统之后，传统领域驱动设计（DDD）面临三个现实问题：
-
领域之间通过结构化消息交互，语义被固化在代码中
-
领域执行过程缺乏可解释、可回放的能力
-
AI 的不确定性无法与领域规则的确定性共存
DAD（Domain Actor Design）是一种面向 AI 时代的领域驱动设计模型，用于解决上述问题。
它以 Actor 模型 作为领域执行单元，并在其内部引入 AI Actor 结构。
一、Actor 模型的基本思想
Actor 模型是一种并发与状态管理模型，其核心思想包括：
-
每个 Actor 拥有独立的私有状态
-
Actor 只通过消息与外界交互
-
Actor 顺序处理消息，不存在并发写状态
-
Actor 可以发送消息、创建新的 Actor
在 DAD 中，Actor 的价值并不在"并发"，而在于：
它天然提供了领域状态隔离、行为顺序化和因果边界。
因此，Actor 被用作 领域行为的最小执行与一致性单元。
二、Domain Actor：领域的执行边界
在 DAD 中，每一个 Domain Actor 表示一个：
-
领域概念
-
或一个长期存在的业务主体（如订单、账户、流程实例）
Domain Actor 负责：
-
持有领域状态
-
顺序接收领域消息
-
驱动状态演化
-
生成领域事件
它取代了传统 DDD 中：
- 聚合根 + 应用服务 + 部分领域服务的混合职责
三、AI Actor 的定义
AI Actor 是 Domain Actor 的一种实现形式，用于承载 AI 参与决策的领域行为。
AI Actor 不是一个"会思考的 Actor"，而是一个具有双层结构的领域执行体。
AI Actor 由两个明确分工的部分组成：
AI Actor ├── Agent（语义与推理层） └── MCP 领域服务（确定性执行层）
这两个部分分别解决不同类型的问题。
四、Agent：语义理解与意图协调层
Agent 是 AI Actor 中负责理解语义的部分。
Agent 承担的职责
Agent 负责：
-
解析来自外部的消息
-
理解消息所表达的业务意图
-
补全上下文信息
-
校验语义合理性
-
将意图转化为可执行请求
-
在不合法或不完整时，明确反馈问题
Agent 解决的问题
Agent 的引入，解决了传统 Actor 与 DDD 中的一个核心问题：
消息是结构化的，但语义是隐式的，导致领域之间在设计期高度耦合。
在 AI Actor 中：
-
消息可以是 JSON
-
但 JSON 不再是固定结构的命令
-
而是携带"意图"的语义输入
领域之间不再依赖共享 DTO 或固定 Schema，
而是通过 语义理解与协商 进行交互。
五、MCP 领域服务：确定性执行层
MCP（Model / Capability / Process）领域服务是 AI Actor 中负责执行的部分。
MCP 的职责
MCP 领域服务负责：
-
定义领域可执行能力
-
执行严格受控的领域操作
-
校验领域规则与约束
-
产生确定性的执行结果
-
生成可持久化的领域事件
Agent 不能直接操作领域状态，只能通过 MCP 调用这些能力。
MCP 解决的问题
MCP 的存在，解决的是：
AI 的不确定性与领域规则确定性之间的冲突。
通过 MCP：
-
AI 的推理被限制在能力边界之外
-
领域模型保持稳定、可测试
-
AI 升级不会破坏领域一致性
六、事件溯源：Domain Actor 的记忆模型
在 DAD 中，Domain Actor 采用 事件溯源 作为核心存储方式。
事件溯源的角色
事件溯源用于：
-
记录收到的消息
-
记录 Agent 的语义理解结果
-
记录 MCP 的执行行为
-
重建 Actor 的历史状态
Domain Actor 的当前状态不是直接存储的，而是通过事件重放得到的。
事件溯源解决的问题
这种存储方式解决了传统状态存储无法解决的问题：
-
领域行为不可解释
-
AI 决策不可回放
-
系统演化不可修正
事件溯源为 AI Actor 提供了：
-
可解释性
-
可审计性
-
可演化性
七、AI Actor 的整体运行结构
综合上述设计，AI Actor 的运行结构如下：
外部消息 ↓ Agent（语义理解与校验） ↓ MCP 领域服务（确定性执行） ↓ 领域事件（事件溯源存储） ↓ Actor 状态演化
每一层职责清晰，边界明确。
结语
DAD 并不是对 DDD 的否定，而是对其执行模型、交互模型和存储模型的系统性升级。
通过：
-
Actor 模型作为领域执行单元
-
Agent 提供语义解耦
-
MCP 保证领域确定性
-
事件溯源提供系统记忆
DAD 为 AI 时代的复杂业务系统，提供了一种可落地、可演化、可解释的领域设计方式。