领域驱动设计 · AI Agent · DDD 实践 · 2026-08

需求文档回答"系统做什么"，详细设计回答"系统怎么做"。这两个文档之间的鸿沟，传统上需要资深架构师数周的领域建模工作。本文记录我们如何用 Coze AI Agent，以领域驱动设计（DDD）为方法论，把一份逆向出的需求规格说明书转化为完整的详细设计文档。

26 个功能点	4 个聚合根	7 张核心数据表	3 类集成域

---

1. 从需求到设计，鸿沟在哪里

需求规格说明书和详细设计文档之间的差距，不是"写多少字"的问题，而是思维方式的转换：

维度	需求文档	详细设计
核心问题	What — 系统做什么	How — 系统怎么实现
组织方式	按功能点罗列	按领域模型聚合
关系描述	“采购员创建采购申请”	聚合根、实体、值对象、领域服务
行为表达	用自然语言描述流程	状态机、时序图、不变式约束
数据视角	字段清单	聚合边界、事务一致性、仓储

传统上，这个转换依赖架构师的经验：识别聚合根、划定事务边界、定义领域事件、设计状态机……这些决策需要对业务有深度理解，同时又要落到代码层面的细节。

我们面对的备件管理模块有 26 个功能点，覆盖从备件主数据、采购申请、订单、验收入库到库存盘点的完整链路。需求文档已经把"做什么"列清楚了，但要变成开发团队可以直接编码的详细设计，还需要完成领域建模、流程设计和数据设计三层工作。

核心命题：AI 能不能代替架构师完成这个"需求→设计"的转换？不能完全代替，但可以承担 80% 的结构化工作，让人专注于 20% 的关键决策。

---

2. 方法论：以 DDD 为骨架的 AI 辅助设计

我们选择领域驱动设计（Domain-Driven Design）作为详细设计的方法论框架，原因很简单：DDD 提供了一套从需求到代码的结构化桥梁，而这种结构化恰恰是 AI 最擅长处理的。

2.1 DDD 设计要素与 AI 的对应关系

DDD 要素	从需求中如何提取	AI 的角色
限界上下文	需求按业务领域自然分组	自动识别领域边界
聚合根	找"谁是独立存在的主体"	分析实体间的引用关系和生命周期
实体与值对象	有唯一标识的是实体，否则是值对象	根据字段中有无 ID 判断
领域服务	跨聚合的业务逻辑	识别不自然属于任何单一聚合的行为
领域事件	“XX 已完成/已审批”	从状态流转中提取
仓储	每个聚合根需要持久化	自动生成仓储接口
不变式	“库存不能为负”“订单金额=明细之和”	从字段约束和业务规则推导

2.2 设计流水线

📋 需求文档 + 实体代码
        │
        ▼
🔍 识别限界上下文与子域（核心域/支撑域/通用域）
        │
        ▼
🏗️ 划定聚合边界 → 识别聚合根、实体、值对象
        │
        ▼
🔄 提取业务流程 → 时序图 + 状态机
        │
        ▼
📐 数据设计 → 字段类型/约束/索引/关系
        │
        ▼
🔗 跨域集成 → 领域事件 + 防腐层
        │
        ▼
📝 输出详细设计文档（Mermaid 图表 + 表格 + 说明）

---

3. 实战：五步完成备件管理详细设计

第一步：构建领域词汇表

DDD 强调通用语言（Ubiquitous Language）——开发团队和业务方使用同一套术语。我们从需求文档和实体类名中提取核心术语：

备件（SparePart）     —— 可独立管理的物料主数据
备件库存（Stock）     —— 某备件在某库位的当前数量
采购申请（Request）   —— 需求部门提出的采购请求
采购订单（Order）     —— 审批通过后向供应商下达的订单
验收（Acceptance）    —— 到货后的检验与接收
出入库流水（Movement）—— 每笔库存变动的不可变记录
盘点（Stocktake）    —— 账实核对过程

这一步看似简单，但它确立了整个设计的语义基础。后续所有类名、方法名、事件名都围绕这套词汇展开。

第二步：识别聚合根——回答"谁能独立存在"

聚合是 DDD 中最核心也最难把握的概念。我们用一个简单的判断标准：删除它时，哪些东西必须一起删除？那些必须一起删除的对象属于同一个聚合。

从备件管理的实体关系中，识别出四个聚合：

聚合根	包含的实体	聚合边界理由
备件信息（SparePart）	备件基本属性、库存参数、关联编码	备件主数据独立存在，不依赖采购或库存
采购申请（PurchaseRequest）	申请单头、申请明细行、审批记录	明细行不能脱离申请单独立存在
采购订单（PurchaseOrder）	订单头、订单明细行、收货记录	明细行随订单生命周期管理
库存（Stock）	库存余额、出入库流水、批次	流水是不可变的事件记录，余额从流水推导

关键设计决策：出入库流水不是库存聚合的子实体，而是独立的不可变事件记录。 当前库存数量是流水的聚合视图（投影），这样设计的好处是：

• 每笔库存变动都可追溯
• 支持时间旅行查询（任意时间点的库存）
• 天然适配船岸同步（增量同步流水即可）

第三步：设计状态机——从审批字段还原状态流转

代码中的审批字段（Manager1/2/3/4、ApproveNum1/2/3、Status）和 Controller 名称（Approve、Reject、Cancel）共同揭示了状态流转。AI 通过分析这些字段和操作，推导出状态机：

这里的关键是从代码字段反推业务语义：

• Manager1 + AppMemo1 表示一级审批人和意见
• ApproveNum1/2/3 表示明细行级别的多级审批数量
• Status 字段的不同整数值对应不同状态，需要结合 Controller 逻辑确认映射关系

第四步：设计核心流程时序

采购到入库是备件管理最核心的端到端流程。AI 根据 Controller 调用链和 Entity 关系，推导出完整时序：

第五步：跨域集成与防腐设计

备件管理不是孤立的。通过分析 Entity 中的外键字段（DeviceId、CardId、OrderId、VendorId），识别出集成点：

集成域	关联字段	集成方式
设备管理	DevicePartId, DeviceId	备件可关联到设备部位
工单管理	CardId	出库可关联到维修工单
供应商管理	VendorId, ManufacturerId	引用供应商主数据
预算管理	BudgType, FareType	采购费用归入预算科目
工作流引擎	Manager1-4, Status	审批流程由 WF5 驱动

每个集成都设计了防腐层（ACL）——备件管理域不直接依赖外部域的实体，而是通过领域事件和接口解耦。例如：库存低于安全库存时发布 LowStockEvent，由消息订阅方决定是否触发自动请购。

---

4. 关键技术决策

决策一：库存数量用"流水+快照"而非直接更新

传统做法是在库存表上直接 UPDATE quantity = quantity - N。这种方式简单但有三个问题：

1. 并发更新需要悲观锁，船岸同步时冲突严重
2. 无法回答"上个月这个备件在 A 库位有多少"
3. 审计困难，不知道每笔变动的原因

我们选择事件溯源风格：出入库流水作为事实记录只追加不修改，当前库存数量是流水的物化视图。船岸同步时只需要同步增量流水，岸基系统重放即可得到一致状态。

决策二：乐观锁处理船岸并发

船端可能离线数周，期间产生大量出入库流水。重新联网后同步时，岸基可能已经发生了变化。设计中采用：

• 每条流水带客户端生成的幂等 ID
• 库存快照带版本号（Ver 字段）
• 同步时检测版本冲突，冲突流水进入对账队列人工处理

决策三：多币种与汇率

代码中 CurrencyId、Rate、LocalCurrency、TotalRMB 等字段说明系统支持多币种。设计中把"金额"建模为值对象，包含金额、币种和汇率，避免不同币种直接比较导致的错误。

决策四：批次追溯

TrendCode（批次号）、InOutDate、Vendor 等字段支持批次级追溯。库存按 (PartsId, LocationId, TrendCode) 三元组维护，出库时按 FIFO 或指定批次扣减。

---

5. AI 做了什么，人做了什么

这是最关键的部分——诚实评估 AI 在详细设计中的边界：

AI 自动完成的（约 80%）

• ✅ 从实体类字段自动生成字段设计表（名称、类型、可空、说明）
• ✅ 从 Controller 名称推导功能清单和操作列表
• ✅ 从字段命名模式识别实体关系（XxxId → 关联）
• ✅ 从审批字段推导状态机框架
• ✅ 从外键字段识别跨域集成点
• ✅ 生成 Mermaid 时序图、类图、状态机代码
• ✅ 按 DDD 模式组织文档结构
• ✅ 自动补充仓储接口和 DTO 定义

需要人决策的（约 20%）

• ⚠️ 聚合边界划定：AI 会给出建议，但"库存流水是否独立为聚合"这种决策需要理解业务后判断
• ⚠️ 状态值的精确映射：代码中 Status=1/2/3 具体对应什么状态，需要结合 Service 逻辑确认
• ⚠️ 不变式与业务规则：如"重要备件必须 100% 检验"这类规则不在字段定义中，需要业务知识
• ⚠️ 并发策略选型：乐观锁还是悲观锁，取决于实际并发量和冲突概率
• ⚠️ 性能权衡：事件溯源的重放成本、快照刷新频率等
• ⚠️ 设计模式选择：哪些用领域服务、哪些用领域事件、哪些直接放在聚合方法中

打个比方：AI 是一个熟练的绘图员，能根据你的草图快速画出精确的施工图；但"这座桥应该选什么结构、承重多少"，仍然需要工程师决定。

---

6. 产出物与使用方式

最终生成的详细设计文档包含：

1. 领域概述：限界上下文图、子域划分、通用语言词汇表
2. 领域模型：4 个聚合的完整类图、实体与值对象定义
3. 流程设计：3 个核心流程的 Mermaid 时序图、2 个状态机图
4. 数据设计：7 张核心表的字段详细设计（含类型、约束、索引建议）
5. 应用服务：接口定义、命令/查询 DTO
6. 仓储设计：仓储接口与查询规格
7. 跨域集成：5 个集成域的领域事件和防腐层设计
8. 非功能设计：船岸同步、并发控制、多币种、批次追溯
9. 设计决策记录：4 个关键技术选型的理由和权衡

开发团队拿到这份文档后，可以：

• 后端工程师按聚合划分和接口定义直接开始编码
• 前端工程师按状态机和时序图理解页面流转
• DBA 按字段设计表创建数据库表
• 测试工程师按状态流转和不变式编写测试用例

---

7. 方法论可复用性

这套"需求→详细设计"的方法不仅适用于备件管理，也适用于其他业务模块。核心条件是：

适用于：

• 有结构化的需求文档或代码实体可作为输入
• 采用规范的架构模式（MVC/分层/微服务）
• 需求边界相对清晰，不需要从零探索业务
• 团队认可 DDD 或类似的领域建模思想

不适用于：

• 业务模式本身不明确、需要大量探索的新产品
• 命名混乱、无结构化输入的遗留系统（需要先做需求逆向）
• 强算法/强性能的系统模块（AI 不擅长性能建模）

---

结语

从需求到详细设计，AI 最大的价值不是"替你做决定"，而是把架构师从重复性的结构化工作中解放出来。

字段表、接口定义、Mermaid 图、文档组织——这些工作 AI 可以在几分钟内完成，而且格式统一、不会遗漏。而架构师可以把精力集中在真正需要经验和判断力的地方：聚合边界是否合理、并发策略是否恰当、业务规则是否完整。

这不是"AI 取代架构师"的故事，而是"AI 让一个架构师能做十个模块的详细设计"的故事。