本文重点但很多初学者接触 DDD 时第一反应是概念太多了领域、子域、限界上下文、聚合、实体、值对象……它们到底是什么关系这一讲的目标很直接用一张图把所有核心概念串起来让你先看到全貌再逐个击破。所以我们先来了解一下。一、一句话认识每个概念先给每个概念一句极简的定义。你不需要现在就完全理解只需要有一个初步印象。战略设计业务视角战略设计回答业务边界在哪里——从业务出发划分领域、子域、限界上下文建立领域模型确定微服务边界。战略设计的概念如下概念一句话定义电商例子领域你要解决的整个业务问题电商业务子域领域拆分后的小业务板块订单、商品、用户、支付、库存、物流核心域公司最核心的竞争力必须自己做订单交易的核心通用域通用能力可以买现成的支付对接支付宝/微信支撑域必需但不是核心可以简做物流跟踪限界上下文语义边界内部术语唯一订单上下文、商品上下文通用语言团队内部统一使用的业务术语订单在订单上下文中就是交易订单战术设计代码视角战术设计回答模型怎么写成代码——将战略设计产出的领域模型逐项落地为可运行的 Java 代码。战术设计中的常用概念如下概念一句话定义代码中的体现聚合一组必须一起保持一致的对象的集合Order.javaOrderItem.java在同一个聚合包中由Order统一管理聚合根聚合的唯一入口业务规则的守护者Order.java含pay()、cancel()方法实体有唯一标识、状态可变的对象Order、OrderItem值对象无标识、不可变、整体替换的对象OrderId、Money、Address领域服务不属于单个实体的业务逻辑DiscountCalculationService.java应用服务编排、协调、事务管理OrderApplicationService.java仓储接口聚合的持久化接口定义领域层OrderRepository.java仓储实现仓储接口的实现基础层OrderRepositoryImpl.java领域事件已经发生的重要业务事实OrderPaidEvent.java二、事件风暴是什么在DDD的实践中事件风暴本身就是战略设计的核心方法而不是一个可选的前置步骤。事件风暴是一种工作坊形式的头脑风暴方法。项目团队——包括领域专家、开发、产品、测试——坐在一起用便利贴把业务流程逐步梳理出来最终形成领域模型。团队通过事件风暴探索业务边界、提取领域概念、划定限界上下文。它的产出直接输入给战术设计。事件风暴产出的领域模型——聚合、实体、值对象、领域事件等——直接作为战术设计的输入指导代码实现。战术设计不需要再做一遍事件风暴。层次事件风暴的角色战略层核心方法团队用事件风暴探索业务、划定边界、产出领域模型战术层输入来源战略设计产出的领域模型直接作为战术设计的输入用建桥来类比事件风暴是建桥的过程——动态的、协作的需要团队围在一起讨论、贴便利贴、争论、收敛。领域模型是桥本身——静态的、结构化的可以被反复查阅和使用。桥的质量取决于建桥的过程。如果事件风暴做得潦草——参与人不全、讨论不充分、概念没有对齐——那么产出的领域模型就是一座不稳固的桥。三、战略与战术的传递关系你可能会有一个疑问战略设计产出了这么多概念战术设计又要实现这些概念——那中间靠什么连接答案是领域模型┌─────────────────────────────────────────────────────────────┐│ 战略设计 ││ 做什么分析业务、划定边界、建立模型 ││ 方法事件风暴 ││ 产出领域模型 │└─────────────────────────────────────────────────────────────┘││ 发现产出▼┌─────────────────────────────────────────────────────────────┐│ 领域模型 ││ 是什么业务概念及其规则的结构化表达 ││ 包含聚合、实体、值对象、领域服务、领域事件、仓储接口 │└─────────────────────────────────────────────────────────────┘││ 输入▼┌─────────────────────────────────────────────────────────────┐│ 战术设计 ││ 做什么将领域模型落地为可运行的代码 ││ 产出Java类 │└─────────────────────────────────────────────────────────────┘一句话总结战略设计把领域模型画在图纸上战术设计把领域模型写在代码里。四、这些概念如何落地为代码宏观从领域到代码的完整路径从领域出发逐级拆分为子域再划定限界上下文。限界上下文决定了微服务的边界。在限界上下文内部建立领域模型包含聚合、实体、值对象、领域服务、领域事件、仓储接口等。领域模型中的每一个概念最终都会映射为微服务领域层中的 Java 类。微观概念到代码的具体映射概念代码中的体现所在包聚合根Order.javadomain/order/实体OrderItem.javadomain/order/值对象OrderId.java、Money.java、Address.javadomain/order/领域服务DiscountCalculationService.javadomain/order/service/仓储接口OrderRepository.javadomain/order/repository/仓储实现OrderRepositoryImpl.javainfrastructure/repository/领域事件OrderPaidEvent.javadomain/order/event/应用服务OrderApplicationService.javaapplication/service/控制器OrderController.javainterfaces/controller/你不需要现在就记住这些只需要知道每一个 DDD 概念最终都会在代码中有一个对应的位置所以我们后面的学习逻辑就是先概念后实现只要跟着这个节奏就好了。五、为什么需要这么多概念你可能会想一个订单系统而已需要这么多概念吗答案是简单的系统不需要复杂的系统非常需要。这些概念本质上是在解决不同层面的问题层面解决的问题对应的概念业务边界这个系统要做什么不做什么领域、子域战略投入哪些必须自己做哪些可以买核心域、通用域、支撑域语义一致团队沟通时不会产生歧义限界上下文、通用语言数据一致性修改订单时订单行不能出错聚合、聚合根业务内聚业务逻辑不要散落各处实体、领域服务技术解耦换数据库不要影响业务代码仓储模式服务解耦微服务之间不要直接依赖领域事件每一个概念都是为了解决一个具体的问题而存在的。当你理解了它解决了什么问题这个概念就不再是抽象的名词而是你工具箱里的一件工具。总结本文的内容呢你只需要先了解你不需要背也不需要记因为当你看完这个专栏的时候你再回过头来就会深刻的理解这些概念了。