简介领域驱动设计(DDD)是复杂业务系统建模的经典方法论这份精简版教程以InfoQ中文站免费发放的《领域驱动设计精简版》为底本面向中高级开发者、架构师以及希望提升业务建模能力的团队。内容聚焦业务模型提炼、通用语言构建、聚合设计、限界上下文与事件风暴等核心实践并结合实际项目分析DDD落地难点与应对策略能帮助读者快速建立从业务洞察到代码实现的一致映射。资源包共1个文件为PDF格式压缩包大小1.27MB便于离线研读与团队分享。该资源已吸引483人学习适合作为入门到进阶的DDD参考读物尤其适合在微服务与中台设计场景中借鉴其建模思路。1. 为什么 DDD 教程很多落地的项目却很少——先从「领域」说起如果你在团队里推过领域驱动设计大概率见过这样的场面架构师讲了一小时聚合和值对象业务方全程沉默开发听完回去还是照着数据库表写 Service。我拆过的十几份 DDD 教程里九成都有同样的问题——不是内容不对而是顺序不对。教材一上来就讲战术设计把聚合、实体、事件满天飞地铺开但读者连「这个限界上下文到底怎么划」都没想明白后面全是空中楼阁。这份教程的讲法不太一样。它把战略设计放在最前面先解决「业务边界画在哪、语言怎么统一」再落到代码层面的聚合与六边形架构。换句话说它默认你知道 DDD 不是一套类库而是一种组织业务复杂度的思维框架。适合谁适合那些已经写过两年以上业务系统、被 if-else 堆到想重构、但每次重构都被需求变化扇耳光的后端工程师。不适合从来没写过业务模型、指望看教程就写出完美架构的人——那类人看完会收获一个更精致的空中楼阁。2. 战略设计限界上下文与通用语言先于代码的建模2.1 事件风暴让业务专家和技术团队用同一张图说话DDD 的战略设计很少是坐在会议室里拍脑袋拍出来的。教程里给的标准动作是事件风暴Event Storming一种让业务专家、产品经理、开发坐在一起贴便签纸的建模方法。核心思路是先别讨论表和字段先把业务里「已经发生的事」全部列出来。事件风暴的标准流程是这样的第一步请业务专家在橙色便签上写出所有领域事件比如「订单已提交」「库存已扣减」「支付已完成」。第二步对每个事件追问「什么操作触发了它」把触发动作写在蓝色便签上比如「提交订单」「确认支付」。第三步把事件和动作连成时间轴找出哪些动作必须在一个事务里完成——这些就是聚合的雏形。第四步把关系紧密的聚合归成一个组这个组就是限界上下文。领域事件橙色订单已提交 - 订单已确认 - 库存已锁定 - 支付已完成 触发命令蓝色提交订单 - 确认订单 - 锁定库存 - 确认支付 聚合分组订单上下文订单 订单项 支付状态这一张贴便签纸的流程价值不在于产出多么标准的 UML 图而在于让业务专家和技术团队第一次用同一套词汇描述系统。你会发现业务专家说的「订单」和开发理解的「订单」经常不是一回事——前者可能包含售后和退货后者只是数据库里一张 order 表。这个差距如果不通过事件风暴暴露出来后面写多少代码都是在错误的地基上盖楼。2.2 限界上下文不是模块划分是业务边界限界上下文Bounded Context是 DDD 里最容易被误解的概念。很多团队把它当成「模块划分」的同义词按技术分层拆——controller 包、service 包、dao 包然后说「我们有三个限界上下文」。这是错的。限界上下文的划分依据是业务语义的完整性不是代码的组织方式。判断标准很简单同一个名词在不同的业务场景里含义和规则是否一致如果「客户」在销售场景里有信用额度、在售后场景里有保修等级这两个场景就应该有各自的限界上下文各自维护自己的「客户」模型互不干扰。教程里给了一个很实用的参考框架——上下文映射Context Mapping它描述的是两个上下文之间的协作方式映射关系英文术语适用场景风险等级防腐层Anti-Corruption Layer集成遗留系统或第三方防止对方模型污染自己中高共享内核Shared Kernel两个团队共享一小部分模型频繁协同中客户-供应商Customer-Supplier上游团队主导下游按上游约定开发中开放主机服务Open Host Service对多个下游提供统一协议接口低防腐层是实战里用得最多的关系。接一个老系统时老系统的「订单」字段冗余、状态混乱你不能把它的模型直接拿进新系统里用。正确做法是在两个限界上下文之间加一层 adapter把老模型的字段翻译成新模型能理解的语言。这个思想直接引导出了后面的六边形架构所以务必理解透。2.3 通用语言词典怎么建怎么维持通用语言Ubiquitous Language听起来是概念性的话题但它其实是最容易执行的。教程给的方案是建一本「业务词汇表」每个限界上下文一份记录名词定义、状态流转、业务规则。这本词典不是给开发自嗨的是给业务方确认的。建词典有一个关键动作——把数据库字段名从词典里剔除出去。字段名是技术实现细节比如 order_status 是 TINYINT 还是 VARCHAR业务方不关心。词典里只写业务概念订单Order客户提交购买请求后生成的业务凭证。 状态OrderStatus待支付Pending- 已确认Confirmed- 已发货Shipped- 已完成Completed其中已发货状态下允许取消取消后进入已关闭Closed。 规则一个订单最多包含 20 个订单项下单后 30 分钟未支付自动关闭。维持通用语言比建立它更难难点在于代码审查时要较真。我见过最典型的翻车场景是代码变量名用 orderInfo注释里写「订单信息」数据库表叫 t_oms_order三方接口文档里叫 purchase order——四个名字对应同一个业务概念。维护通用语言的唯一办法就是在 code review 阶段硬性要求变量名、方法名与词汇表一致不一致就打回。这很痛苦但项目越往后走它省下的沟通成本越大。3. 战术设计聚合、实体、值对象与领域事件怎么落到代码3.1 聚合边界用不变量反推不用数据库表关系反推进入战术设计后第一个要拿下的概念是聚合Aggregate。新手最容易犯的错误是拿数据库外键关系定义聚合边界——订单表关联订单项表所以它们在一个聚合里用户表关联订单表所以它们也是同一个聚合。这么想就错了因为聚合的划分依据是业务事务边界不是数据关联。判断聚合边界的方法是在事件风暴里找「不变量」Invariant。比如一个订单的总额必须等于所有订单项金额之和这个约束必须在订单聚合内部保证但「下单后扣库存」这个约束跨订单和库存两个聚合聚合内部无法独立保证所以要拆开用领域事件或最终一致性处理。public class Order { private OrderId id; private ListOrderItem items; private OrderStatus status; // 聚合根所有外部操作必须通过 Order 的方法进入 public void addItem(ProductId productId, Money price, int quantity) { if (items.size() 20) { throw new BusinessException(单个订单最多包含20个订单项); } items.add(new OrderItem(productId, price, quantity)); recalculateTotal(); } public void confirm() { if (status ! OrderStatus.PENDING) { throw new BusinessException(只有待支付订单才能确认); } this.status OrderStatus.CONFIRMED; // 领域事件由聚合根发布外部订阅 registerEvent(new OrderConfirmedEvent(id)); } private void recalculateTotal() { // 不变量总额始终等于订单项金额之和 this.total items.stream().map(OrderItem::subtotal).reduce(Money.ZERO, Money::add); } }这段代码里有三个点值得留意。第一OrderItem作为订单聚合内部对象没有对外暴露 setter所有修改路径都经过聚合根确保不变量不被绕过。第二confirm()方法的状态判断是「数据自校验」它把业务规则内聚在领域对象里而不是散落在 Service 层。第三registerEvent是领域事件的发布接口事件不直接发到消息队列而是先注册到聚合内部等事务提交后再统一发布。这是避免「事件发了但事务回滚了」的经典做法。3.2 实体与值对象可变标识 vs 全量属性实体Entity和值对象Value Object的区分是 DDD 的入门必考但很多人理解成「表里有主键就是实体」。这个说法在大多数场景下对但没说到根上。核心区别是实体有标识且标识不变但属性可变值对象没有标识由全部属性共同定义且一旦创建就不应该变。举例来说账号是实体——账号 ID 不变但密码和昵称可以改。用户地址是值对象——你把「北京市朝阳区」改成「北京市海淀区」它不是同一个地址变了一个属性而是变成了一个新的地址对象。这个区分直接影响代码怎么写。// 实体id 唯一且不变属性可变 public class Account { private AccountId id; // 稳定标识 private String nickname; // 可修改 public void changeNickname(String newNickname) { this.nickname newNickname; } } // 值对象无标识属性不可变 public class Address { public final String province; public final String city; public final String detail; public Address(String province, String city, String detail) { this.province province; this.city city; this.detail detail; } // 不提供任何修改方法需要新地址就 new 一个 }值对象不可变的意义在于它可以被安全共享。一个家庭住址可以被多个订单引用如果它是可变的一个订单改了地址别的订单全受影响。把它设计成不可变后共享就不会产生副作用。实战里有一个血泪经验所有金额、价格、数量都应该设计成值对象而不是裸的 BigDecimal——否则你没法阻止任何地方对金额做加减乘除以外的操作。这个约束在代码审查阶段靠人盯建议用单元测试覆盖核心金额操作的权限。3.3 领域事件与事件发布时机事务内外发布策略领域事件Domain Event是 DDD 从战术设计通往分布式系统的桥梁。它记录的是「已经发生的事实」比如OrderConfirmedEvent、PaymentReceivedEvent。事件的命名要用过去时因为它描述的是已完成的事情不是待办的任务——「订单已确认」是事件「确认订单」是命令两者容易混。教程里值得照抄的是一组事件发布时机的规则。我把它整理成一张表按事务边界区分场景发布时机一致性类型实现方式同一数据库同一条事务事务提交前强一致在聚合根方法内注册事务提交后统一发送多个服务各自持有数据库本地事务提交后最终一致事务日志表 消息队列或 CDC变更数据捕获跨系统集成不共享数据接口调用返回后最终一致消息队列 重试机制实现上有一个很隐蔽的坑在事务执行到一半时直接发消息。比如订单确认方法里调了kafkaTemplate.send()再提交事务如果消息发送成功但事务回滚了下游系统会消费到一条「订单已确认」的事件但订单实际并没有确认成功。这是分布式系统里最经典的「幽灵事件」问题。Service public class OrderApplicationService { Transactional public void confirmOrder(OrderId orderId) { Order order orderRepository.findById(orderId); order.confirm(); // 从聚合中取出已注册的事件在事务提交后再发布 ListDomainEvent events order.getRegisteredEvents(); // 用 TransactionSynchronizationManager 注册回调 TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() { Override public void afterCommit() { events.forEach(eventPublisher::publish); } }); } }这个方案的要点是把事件收集和事件发送分离order.confirm()只负责把事件注册到内存列表里事务提交成功后afterCommit回调才真正发送。这样即使发送失败导致下游未收到本地事务也不受影响可以通过后续的补偿机制重发。教程里用的正是这种「事务同步管理器注册回调」的方式它是 Java 生态里最标准的解法比在聚合根里直接注入 MQ 客户端干净得多。4. 六边形架构让领域模型不被框架拖着走4.1 端口与适配器依赖方向决定架构优劣六边形架构Hexagonal Architecture又叫端口与适配器架构Ports and Adapters是 Alistair Cockburn 提出的一种应用架构。它和 DDD 几乎是天然搭档——因为 DDD 的战术设计产出的领域模型需要一个不被数据库、消息队列、Web 框架污染的「净土」六边形架构正好提供这个隔离层。核心思想是把应用逻辑放在六边形的中心周边通过端口Port对外暴露能力、对内接收数据。端口是接口适配器Adapter是具体实现。比如订单服务需要一个「保存订单」的能力这是一个出站端口Output Port由 repository 接口定义而数据库实现的JdbcOrderRepository就是适配器。Web 入口是入站端口Input PortREST Controller 是它的适配器。这套架构的价值在于依赖方向领域层不依赖基础设施层基础设施层反过来依赖领域层定义的接口。结果是你可以先用内存实现跑通全部业务逻辑再替换成 MySQL、MongoDB、或者一个远程 RPC 服务领域代码一行不改。教程里给了一张很直观的对比——传统分层架构的依赖是从上到下改数据库要动 Service 层六边形架构的依赖是从外到内替换适配器不动内核。4.2 把 Spring 推到适配器层领域层零框架依赖Java 生态里做 DDD 六边形架构最常见的技术栈是 Spring Boot。但要注意Spring 的Service、Repository、Transactional这些注解应该出现在适配器层和用例层不应该出现在领域层。领域层就应该是干净的 POJO顶多用一下 Lombok 的Getter。// 领域层纯 Java不 import 任何 Spring 类 public class Order { private OrderId id; private OrderStatus status; public void confirm() { if (status ! OrderStatus.PENDING) { throw new BusinessException(只有待支付订单才能确认); } this.status OrderStatus.CONFIRMED; } } // 应用层编排用例事务边界在这里 Service public class ConfirmOrderUseCase { private final OrderRepository orderRepository; // 构造器注入不用 Autowired 字段注入 Transactional public void confirm(OrderId orderId) { Order order orderRepository.findById(orderId); order.confirm(); orderRepository.save(order); } } // 基础设施层实现端口 Repository public class JdbcOrderRepository implements OrderRepository { // 实现 findById、save 等方法处理 ORM 映射细节 }上面三段代码展示了六边形架构的分层节奏。领域层的Order不 import Spring它的状态流转逻辑是可以脱离框架运行的单测目标。应用层的ConfirmOrderUseCase是唯一带Transactional的地方——事务边界的粒度由用例决定一个用例一个事务。基础设施层的JdbcOrderRepository处理 MyBatis/JPA 的映射细节领域层完全不知道数据库的存在。从代码审查的角度识别分层有没有被破坏有一个简单方法看 import 语句。如果领域层的文件里出现了org.springframework或者com.baomidou.mybatisplus说明分层已经被破坏了。这不是死板的洁癖而是有实际代价的——一旦领域层绑定了框架你就没法在单元测试里用纯内存的对象快速验证业务规则每次都要起 Spring 容器。5. 避坑与常见问题伪 DDD 的四个典型危险信号5.1 现象Service 层巨胖领域对象全成了 getter/setter 容器这是「贫血模型」的典型症状实体类只有数据库字段对应的 getter 和 setter所有业务逻辑都堆在OrderServiceImpl里一个方法几百行充斥着if (order.getStatus() 2)这样的魔法数字判断。团队嘴上说在做 DDD代码本质上是「面向数据库编程」。原因数据库表设计的惯性太强建模时先想表结构再反向生成实体类。业务逻辑没有内聚到领域对象上而是散落在过程式的 Service 里。解决在代码审查时强制检查「实体是否包含业务方法」。实体里如果没有任何业务行为的判断逻辑基本可以判定为贫血模型。先重构出一个私有状态流转方法把 if 判断移入实体再逐步把相关逻辑从 Service 迁入。5.2 现象所有业务都用 CQRS读操作也走聚合和事件CQRS命令查询职责分离是 DDD 社区里流行的高级模式但不是万能药。有的团队把聚合的查询和写入彻底分开读操作单独建表、走物化视图、用事件溯源重建状态复杂度翻了三倍。对于一个只有几千日活的内部管理系统这种设计带来的全是运维成本。原因把 CQRS 当成 DDD 的「标配」而不是「可选件」。CQRS 只有在读写竞争激烈、读写模型差异巨大时才值得引入。解决优先用「读写同源」即查询直接走聚合的查询方法。当确实出现查询模型和业务模型严重不一致时再引入只读的投影表用事件更新投影。不要一上来就搞事件溯源先把传统的 repository 查询跑通。5.3 现象领域事件在事务中间发送下游消费到「幽灵事件」这个坑在 3.3 里提过但它值得单独列为一条。现象是本地事务回滚了但消息队列里的事件已经发送出去下游服务消费后更新了状态导致两个服务的数据永久不一致。原因把messageProducer.send()写在了事务方法内部、commit 之前。解决严格按照「聚合内注册事件 → 事务提交 → afterCommit 发布事件」的流程。如果用的不是 Spring 的事务同步机制可以换成事务发件箱Transactional Outbox模式把事件写进本地事务表由单独的后台任务扫描发布发布成功后删除或标记为已发送。5.4 现象限界上下文划分过细一个订单拆成五个微服务这种现象在微服务改造项目里很常见按 DDD 方法论把订单、支付、库存、物流、售后各拆成一个上下文每个上下文独立部署结果一次简单的下单操作要在五个服务之间做分布式事务出了问题查日志查到怀疑人生。原因把限界上下文等同于微服务部署边界。限界上下文是一个逻辑边界它可以对应一个模块、一个 Java package不一定对应一个独立部署单元。在团队不大、流量不高的情况下把多个边界清晰的上下文放在同一个应用里、通过模块隔离是成本最低的方案。解决先按上下文划模块保持代码层面的隔离清晰等到某个上下文的性能特征、团队归属或发布频率确实需要独立时再拆成微服务。记住一个原则微服务应该是限界上下文的物理实现选项之一而不是必然结果。6. 把 DDD 落到团队协作事件风暴 上下文映射图的一个最小可行流程前面几章讲的都是理论和代码模式这一章给一个有手就能落地的协作流程。我在团队里跑过一次最小可行的事件风暴全程约两个半小时适合一个 30 人以下的业务线做首次 DDD 建模。流程分四步。第一步30 分钟请业务方列出完整的生命周期事件从创建到归档全部用过去时写在橙色便签上——「订单已创建」「合同已签署」「发票已开具」。其中「合同已签署」牵扯法务审批和财务记账这就是两个上下文之间的交互点。第二步40 分钟对每个事件追问触发命令和前置条件把异常分支也覆盖到比如「支付已超时」「审批已驳回」。第三步30 分钟把事件聚类成多个聚合再归并成限界上下文为每个上下文分配一个负责人。第四步50 分钟画上下文映射图标出上下文之间的协作方式——是防腐层还是共享内核各自的数据流向是什么。整个流程的产出物有三样一张事件时间轴、一张限界上下文清单、一张上下文映射图。这三样比任何架构设计文档都实际因为它们直接决定了后面的表结构、接口划分和团队分工。我自己的习惯是每到一个新业务线先强制自己完整走一遍这个流程哪怕业务看起来很简单。有一次给一个内部工具系统建模团队觉得「这业务太简单了不需要 DDD」结果事件风暴一跑发现「客户」在外勤和财务两个场景里完全是两个概念统一模型根本走不通——这个发现让团队少走了一个月的弯路。从那以后我每次接到新需求第一件事不是开数据库表设计会议而是召集业务方和相关研发把事件风暴和上下文映射的草图画出来。这能让团队把注意力放在业务规则上而不是实现细节上真正做到让代码跟着业务走。希望帮到你。本文还有配套的精品资源点击获取