2026年4月25日...大约 7 分钟
DDD 能力提升与实践建议：结合微服务与 AI 的探索
DDD 不仅是技术，更是思维方式。本文分享我在 DDD 学习与实践中的能力提升路径，以及如何结合微服务和 AI 实现更大的技术突破。
💡 背景
学习 DDD 已经有一段时间，从最初的概念理解到现在的实践应用，走了不少弯路，也积累了一些经验。
核心问题：
- DDD 概念很多，如何系统学习？
- 微服务架构下如何落地 DDD？
- AI 时代，DDD 有什么新的可能性？
本文目的： 分享我的学习路径、实践建议，以及 AI + DDD 的探索思考。
📚 DDD 能力提升路径
学习曲线概览
┌─────────────────────────────────────────────────────────────┐
│ DDD 学习曲线 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 入门期 │▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓│
│ 理解核心概念 │ 限界上下文、聚合、实体、值对象 │
│ │
│ 成长期 │ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓│
│ 实践应用 │ 战略/战术设计 │
│ │
│ 突破期 │ ▓▓▓▓│
│ AI + DDD │ 智能建模 │
│ │
└─────────────────────────────────────────────────────────────┘第一阶段：概念入门（1-2 周）
目标： 理解 DDD 核心概念，建立通用语言
推荐学习资料：
| 资料 | 类型 | 推荐理由 |
|---|---|---|
| 《领域驱动设计》Eric Evans | 经典书籍 | DDD 之父，必读但难读 |
| 《实现领域驱动设计》Vaughn Vernon | 实践指南 | 配合 Evans 书一起读 |
| 《微服务架构设计模式》Chris Richardson | 微服务+DDD | 实战导向 |
| DDD 官网 (domainlanguage.com) | 网站 | 官方资源 |
核心概念检查清单：
☐ 限界上下文（Bounded Context）
☐ 聚合根（Aggregate Root）
☐ 实体（Entity）
☐ 值对象（Value Object）
☐ 领域服务（Domain Service）
☐ 仓储（Repository）
☐ 工厂（Factory）
☐ 领域事件（Domain Event）
☐ 上下文映射（Context Mapping）学习方法： 不要一次读完，边读边用，遇到问题再回来读。
第二阶段：实践应用（2-4 周）
目标： 在项目中实践 DDD，从战术设计开始
2.1 战术设计实践
从聚合开始：
聚合设计练习：
┌─────────────────────────────────────────────────────────────┐
│ 1. 识别业务不变规则（Invariant） │
│ 2. 找到聚合根 │
│ 3. 定义聚合边界 │
│ 4. 选择聚合内实体和值对象 │
│ 5. 实现仓储接口 │
└─────────────────────────────────────────────────────────────┘代码练习：
// 练习1：设计一个订单聚合
public class OrderAggregate {
private OrderId id;
private CustomerId customerId;
private List<OrderItem> items;
private OrderStatus status;
// 不变规则：已发货的订单不能取消
public void cancel() {
if (this.status == OrderStatus.SHIPPED) {
throw new BusinessException("已发货订单不能取消");
}
this.status = OrderStatus.CANCELLED;
}
}// 练习2：设计一个测试用例聚合
public class TestCaseAggregate {
private TestCaseId id;
private TestCaseName name;
private List<TestStep> steps;
private TestCaseStatus status;
// 不变规则：执行中的用例不能修改
public void addStep(TestStep step) {
if (this.status == TestCaseStatus.EXECUTING) {
throw new BusinessException("执行中不能添加步骤");
}
this.steps.add(step);
}
}2.2 战略设计实践
EventStorming 工作坊：
EventStorming 是快速理解业务领域的好方法：
┌─────────────────────────────────────────────────────────────┐
│ EventStorming 流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 定义领域事件（Domain Event） │
│ └── 用户提交了订单 / 测试用例执行完成 / 报告生成 │
│ │
│ 2. 识别命令（Command） │
│ └── 用户下单 / 执行测试 / 生成报告 │
│ │
│ 3. 发现聚合（Aggregate） │
│ └── 订单聚合 / 测试用例聚合 / 报告聚合 │
│ │
│ 4. 划定限界上下文 │
│ └── 订单上下文 / 执行上下文 / 报告上下文 │
│ │
│ 5. 识别人（Person） │
│ └── 测试工程师 / 开发人员 / 运维 │
│ │
└─────────────────────────────────────────────────────────────┘第三阶段：微服务 + DDD（4-8 周）
目标： 将 DDD 思想应用到微服务架构
3.1 按领域划分服务
传统方式（按层/按技术） DDD 方式（按领域）
┌─────────────────┐ ┌─────────────────┐
│ 用户服务 │ │ 订单服务 │
│ 订单服务 │ │ 支付服务 │
│ 支付服务 │ │ 库存服务 │
│ 库存服务 │ │ 用户服务 │
└─────────────────┘ └─────────────────┘
按功能划分 按业务边界划分3.2 服务拆分决策树
服务拆分决策树：
这个功能需要独立吗？
│
├── 团队独立吗？ ──── 是 ────→ 独立服务
│
├── 变更频率相同吗？ ──── 否 ────→ 独立服务
│
├── 需要不同技术栈吗？ ──── 是 ────→ 独立服务
│
├── 数据一致性要求高吗？
│ └── 高 ────→ 同一服务
│
└── 聚合边界清晰吗？
└── 清晰 ────→ 独立服务3.3 微服务 + DDD 架构示例
┌─────────────────────────────────────────────────────────────┐
│ 微服务 + DDD 架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ API Gateway │ │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ 订单域 │ │ 支付域 │ │ 用户域 │ │ 通知域 │ │
│ │ │ │ │ │ │ │ │ │
│ │ OrderAgg │ │PaymentAgg│ │ UserAgg │ │NotifAgg │ │
│ │ Repository│ │Repository│ │Repository│ │Repository│ │
│ └───────────┘ └───────────┘ └───────────┘ └───────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 消息总线（Event Bus） │ │
│ │ OrderCreated / PaymentCompleted / ... │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘🤖 AI + DDD：新的可能性
AI 如何辅助 DDD
4.1 智能领域建模
传统方式： 人工 EventStorming 工作坊，耗时耗力
AI 辅助方式：
用户输入：
"我有一个电商系统，包含用户下单、支付、发货、退货功能"
AI 输出：
1. 领域事件：OrderPlaced, PaymentCompleted, OrderShipped, OrderReturned
2. 聚合：OrderAggregate, PaymentAggregate, ShippingAggregate
3. 限界上下文：订单上下文、支付上下文、物流上下文
4. 上下文映射：支付上下文 → 订单上下文（客户-供应商）实践工具：
| 工具 | 说明 |
|---|---|
| Claude/GPT | 自然语言 → 领域模型 |
| PlantUML | 生成 UML 图 |
| Mermaid | 生成架构图 |
4.2 AI 代码生成
生成聚合代码：
// 告诉 AI：帮我生成一个测试用例聚合，包含增删改查操作
/**
* AI 生成的测试用例聚合
*/
public class TestCaseAggregate {
private TestCaseId id;
private TestCaseName name;
private List<TestStep> steps;
private TestCaseStatus status;
private LocalDateTime createdAt;
private LocalDateTime updatedAt;
// 工厂方法
public static TestCaseAggregate create(TestCaseName name) {
TestCaseAggregate aggregate = new TestCaseAggregate();
aggregate.id = TestCaseId.generate();
aggregate.name = name;
aggregate.status = TestCaseStatus.DRAFT;
aggregate.steps = new ArrayList<>();
aggregate.createdAt = LocalDateTime.now();
return aggregate;
}
// 业务方法
public void addStep(TestStep step) {
if (this.status == TestCaseStatus.EXECUTING) {
throw new BusinessException("执行中不能添加步骤");
}
this.steps.add(step);
}
public void submit() {
if (this.steps.isEmpty()) {
throw new BusinessException("至少需要一个步骤");
}
this.status = TestCaseStatus.SUBMITTED;
DomainEvents.publish(new TestCaseSubmittedEvent(this.id));
}
}4.3 AI 辅助代码 Review
DDD 规则检查：
AI 检查点：
☐ 聚合根是否封装了所有业务规则？
☐ 聚合间是否通过 ID 而非直接引用？
☐ 值对象是否不可变？
☐ 领域服务是否不持有状态？
☐ 仓储接口是否只属于聚合？AI Review 示例：
AI 提示：
"这个 OrderService 中的 calculateTotal() 方法应该移到 OrderAggregate 中，
因为它操作的是 Order 的内部状态，符合 DDD 战术设计原则。"🎯 实践建议
给 DDD 初学者的建议
┌─────────────────────────────────────────────────────────────┐
│ DDD 实践避坑指南 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ❌ 不要一开始就追求完美 │
│ └── 先用起来，边实践边改进 │
│ │
│ ❌ 不要试图用 DDD 重构整个系统 │
│ └── 从新功能或小模块开始 │
│ │
│ ❌ 不要把 DDD 当成银弹 │
│ └── 简单的 CRUD 不需要 DDD │
│ │
│ ❌ 不要忽视团队共识 │
│ └── DDD 是团队学习方法论，需要统一语言 │
│ │
│ ✅ 从聚合开始 │
│ └── 聚合是 DDD 最核心的概念 │
│ │
│ ✅ 用代码验证设计 │
│ └── 设计好不好，看代码怎么写 │
│ │
│ ✅ 持续重构 │
│ └── 领域模型需要不断演进 │
│ │
└─────────────────────────────────────────────────────────────┘实践路线图
Week 1-2: 概念入门
├── 阅读《实现领域驱动设计》前 5 章
├── 理解聚合、实体、值对象
└── 完成聚合设计练习
Week 3-4: 战术设计
├── 设计 2-3 个聚合
├── 实现仓储接口
└── 编写领域事件
Week 5-6: 战略设计
├── 使用 EventStorming 梳理业务流程
├── 划分限界上下文
└── 设计上下文映射
Week 7-8: 微服务落地
├── 按领域拆分服务
├── 实现服务间通信
└── 搭建基础设施
Week 9-12: AI + DDD
├── 用 AI 辅助建模
├── 用 AI 生成代码
└── 用 AI 做代码 Review📊 能力评估标准
DDD 能力等级
| 等级 | 定义 | 特征 |
|---|---|---|
| L1 入门 | 理解概念 | 知道聚合、实体、值对象的定义 |
| L2 掌握 | 能在项目中实践 | 能够设计聚合，实现领域逻辑 |
| L3 熟练 | 能够指导团队 | 能够组织 EventStorming，推进 DDD 落地 |
| L4 精通 | 能够创新 | 能够结合 AI 等新技术优化 DDD 实践 |
自我评估清单
L1 入门：
☐ 能解释什么是聚合根
☐ 能区分实体和值对象
☐ 能识别限界上下文
L2 掌握：
☐ 能独立设计聚合
☐ 能实现领域服务
☐ 能在项目中落地 DDD
L3 熟练：
☐ 能组织团队进行 EventStorming
☐ 能制定 DDD 编码规范
☐ 能指导团队成员
L4 精通：
☐ 能结合业务特点创新
☐ 能引入 AI 等新技术
☐ 能输出 DDD 方法论💡 总结
核心要点
- DDD 学习曲线陡峭 — 需要耐心和实践
- 从聚合开始 — 聚合是 DDD 最核心的概念
- 边学边用 — 用代码验证设计
- AI 是辅助工具 — 加速 DDD 实践，不能替代思考
- 团队共识是关键 — DDD 是团队学习方法论
AI + DDD 展望
┌─────────────────────────────────────────────────────────────┐
│ AI + DDD 未来趋势 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 🤖 智能建模助手 │
│ └── 用自然语言描述业务，AI 自动生成领域模型 │
│ │
│ 🤖 智能代码生成 │
│ └── 根据领域模型自动生成聚合、实体、仓储代码 │
│ │
│ 🤖 智能代码 Review │
│ └── AI 自动检查 DDD 规则遵循情况 │
│ │
│ 🤖 智能架构推荐 │
│ └── 根据业务特点 AI 推荐服务拆分方案 │
│ │
└─────────────────────────────────────────────────────────────┘你目前在 DDD 的哪个阶段？有什么困惑或心得？ 欢迎交流！
欢迎交流讨论！
相关阅读：
欢迎交流讨论，我的 blog：sunrong.site
贡献者
Sun Rongsunrong1