跳到正文

DDD 领域驱动设计 · 导读 ​

一句话:DDD(Domain-Driven Design)用「边界 + 模型」承接业务复杂度:先把业务切成可以独立演进的限界上下文,再把每个边界内的规则放进聚合。它换来的是模型和团队的可维护性,代价是前期建模投入和跨边界的一致性设计。

这套文档只讲机制、产出物和落地动作,不按题库组织。示例以 Java 17+ 编写,框架示例标注 Spring Boot 3.x。

读之前需要什么 ​

前置能力具体检查不满足时先补
面向对象能说清封装、多态、组合优于继承Java 基础语法
业务系统经验见过 Service 膨胀、改一处崩一片先读一个真实项目的分层代码
Java 17能读 record、Optional、StreamJava 8–17 新特性
测试能跑 JUnit 5,理解断言与夹具JUnit 5 用户指南
数据库理解本地事务、唯一索引、乐观锁MySQL 事务与锁

不需要先学微服务。限界上下文是逻辑边界,和部署单元是两件事,05 篇再讨论落地。

阅读顺序 ​

顺序文档回答的问题读完应产出前置
101-战略设计业务怎么切、边界从哪来、上下文怎么协作一页上下文画布 + 一张映射表无
203-建模方法怎么从业务事实推导模型,而不是照表建类一条事件时间轴 + 术语表初稿01
302-战术设计实体、值对象、聚合、仓储、领域服务、领域事件各装什么一个带不变量和乐观锁的聚合 + 测试01、03
404-工程落地依赖方向怎么画、CQRS 和事件溯源何时用包结构 + 一条 ArchUnit 规则02
505-DDD与微服务上下文怎么落到服务和库、跨边界一致性怎么做库隔离决策表 + Outbox 链路02、04
606-生产踩坑落地变形长什么样、怎么用证据定位一份团队自查记录01–05
799-生产检查清单上线前、运行中、故障时各查什么勾选后的清单全部

建议节奏:第 1 周读 01、03,完成一次 2 小时事件风暴;第 2 周读 02、04,把聚合和依赖规则跑通;第 3 周读 05、06,用一个真实跨边界流程做 Outbox 验证。

验收标准 ​

读完不等于学会。下面每一条都能用命令或产物验证:

验收项判据
边界说得清能指出每个限界上下文的 owner、模型、数据归属;同一术语在两个上下文有不同定义时,能说出翻译发生在哪
聚合守得住mvn -q test -Dtest=OrderAggregateTest 通过;重复支付、空订单支付、超量添加都抛异常
并发有方案仓储 UPDATE ... WHERE version = ? 影响行数为 0 时抛乐观锁异常;重试次数和退避策略写进代码
依赖没走反ArchUnit 规则通过:domain 包不依赖 Spring、MyBatis、infrastructure、adapter
事件不丢状态变更与 Outbox 写入在同一本地事务;中继任务能查到未发送记录并补发
坑能定位面对「锁等待」「事件积压」「模型漂移」,能给出证据查询和判断阈值,而不是只给结论

目录结构 ​

text
28_DDD领域驱动设计/
├── 00-DDD学习路线.md                 ← 本页,只做导航
├── 01-战略设计.md                    ← 子域、限界上下文、上下文映射
├── 02-战术设计.md                    ← 六类构件、聚合不变量、并发
├── 03-建模方法.md                    ← 事件风暴、统一语言、规格模式
├── 04-工程落地.md                    ← 分层、六边形、CQRS、事件溯源
├── 05-DDD与微服务.md                 ← 服务拆分、库隔离、最终一致性
├── 06-DDD生产踩坑.md                 ← 现象、证据、根因、处置
└── 99-生产检查清单.md                ← 可勾选的执行清单

与其他主题的衔接 ​

初稿 2026-10 | 最后修订 2026-10

把一门技术讲透到既懂也会用