1. 从“玄学”到“工程”我眼中的DDD本质“DDD”这三个字母在技术圈里尤其是最近几年热度一直居高不下。无论是招聘要求里的“熟悉DDD者优先”还是技术分享会上频频出现的“领域驱动设计”都让很多开发者既好奇又困惑。我见过不少团队一提到DDD要么觉得是“大厂专属”、“过度设计”要么就是买几本书、画几张“六边形架构”图然后项目代码该咋写还咋写最后得出结论DDD没啥用净整些虚的。作为一个在多个复杂业务系统中实践过DDD的过来人我想说这种认知偏差太普遍了。DDD从来就不是一个可以直接“安装”的框架也不是一套必须严格遵守的“教条”。它更像是一套思维方式和沟通工具核心目标只有一个让软件的核心逻辑代码能够精准地反映并服务于真实的业务规则领域知识。它解决的是随着业务复杂度提升代码逐渐失控、难以理解、难以演进的“慢性病”。简单来说DDD就是教你如何把业务专家嘴里那些“行话”领域语言变成程序员手里清晰、可维护的代码结构。它不是什么银弹但对于处理业务规则复杂、变化频繁的系统它能帮你把“一团乱麻”理成“清晰脉络”。今天我就结合自己踩过的坑和成功的经验把DDD从“玄学”拉回“工程”聊聊它到底是什么以及到底该怎么用。2. DDD的核心思想拆解不止是分层和实体很多人初学DDD都是从“四层架构”接口层、应用层、领域层、基础设施层或者“实体”、“值对象”、“聚合根”这些战术模式开始的。这没错但这些只是“术”是工具。如果只学这些很容易陷入“为DDD而DDD”的困境。我们必须先理解它的“道”。2.1 统一语言打破沟通的巴别塔这是DDD最核心、也最容易被忽视的基石。在传统开发中产品经理说“用户下单”开发可能理解成“往order表里插一条记录”测试可能理解成“点击提交按钮”。同一个词在不同角色脑海里映射的是完全不同的东西。这种认知偏差是项目后期各种bug和返工的根源。DDD强调项目组所有成员业务、产品、开发、测试必须就核心业务概念建立一套精确的、无歧义的统一语言。这套语言中的每个词都对应着领域模型中的一个核心概念。实操心得统一语言不是开几次会就能定下来的。我们的做法是在项目启动阶段组织“事件风暴”工作坊。把业务专家、产品、核心开发拉到一起用便利贴梳理出所有的业务事件如“订单已创建”、“库存已扣减”、命令如“创建订单”、“支付订单”和核心实体。这个过程本身就是统一语言的过程。最终产出的不仅是一堆便利贴更是一份所有角色都认可的“领域词典”。后续所有的需求讨论、代码命名类名、方法名、变量名、甚至数据库表名都必须严格使用这份词典里的词汇。2.2 战略设计划分清晰的业务疆域当业务非常庞大时你不可能用一个单一的、庞大的模型去描述一切。那样只会让模型变得臃肿、脆弱。战略设计就是用来“分而治之”的。领域你所要解决的整个业务问题空间。比如一个电商系统其领域就包含了商品、订单、库存、营销、支付等。子域将庞大领域按业务功能或职责进行划分。子域分为三类核心子域公司的核心竞争力所在是业务差异化的关键。比如电商的“商品推荐算法”、“个性化营销系统”。这里应该投入最好的资源采用最复杂的领域模型。支撑子域不是核心竞争力但业务运转必不可少。比如电商的“库存管理系统”、“物流跟踪系统”。它们需要被定制开发但不必追求极致模型。通用子域行业通用解决方案没有业务差异性。比如“用户认证”、“权限管理”。这类子域强烈建议直接使用成熟的开源方案或购买SaaS服务不要自己造轮子。限界上下文这是战略设计的核心产出。它定义了一个模型即统一语言的边界。在边界之内一个术语如“产品”有且仅有一种明确的含义跨过边界同一个词可能代表不同的东西。比如在“商品”上下文中“产品”关注的是类目、属性、详情在“订单”上下文中“产品”可能只关心SKU、价格、名称。限界上下文之间的交互通过上下文映射来定义比如采用“防腐层”ACL来隔离外部上下文的模型变化或者采用“发布/订阅”事件进行松耦合通信。避坑指南新手最容易犯的错误是把“限界上下文”等同于“微服务”。虽然它们经常被一起讨论但本质不同。限界上下文是逻辑边界微服务是物理边界。一个限界上下文可以是一个微服务也可以是一个模块在单体架构中甚至多个关系紧密的限界上下文可以放在同一个微服务里。划分限界上下文的首要依据是语言和模型的统一性而不是技术或团队结构。过早地按微服务划分可能导致上下文边界模糊产生混乱的依赖。2.3 战术设计在边界内构建精致模型这是在限界上下文内部我们具体写代码时使用的工具集。这是大家最熟悉的部分但要用好必须理解其设计意图。实体有唯一标识ID和生命周期的事物。比如“用户”、“订单”。它的相等性由ID决定。实体的核心是行为而不仅仅是数据容器。它应该封装自己的业务规则。值对象没有唯一标识通过其属性值来定义的事物。比如“地址”、“金额”。它应该是不可变的。两个所有属性都相同的值对象可以被视为相等。使用值对象可以极大地增强代码的表达能力和安全性比如用Money类封装金额和货币避免直接用BigDecimal。聚合这是战术设计中最关键的概念。聚合是一组相关实体和值对象的集合它有一个聚合根。聚合根是外部访问聚合内所有元素的唯一入口。聚合内部维护强一致性规则聚合之间则通过聚合根的ID进行引用维护最终一致性。为什么需要聚合它定义了数据修改的一致性边界。比如“订单”聚合包含了订单根、订单项、收货地址等。修改订单的任何部分都必须通过订单这个根来进行确保了“订单总金额必须等于所有订单项金额之和”这类规则在聚合内瞬间一致。领域服务当某个操作或业务逻辑无法自然地放在任何一个实体或值对象内部时因为它涉及多个聚合的协调或者是一个无状态的业务操作就将其放在领域服务中。比如“资金转账服务”需要协调“转出账户”和“转入账户”两个聚合。领域事件表示领域中发生的、对其它部分有意义的事情。比如“OrderPlacedEvent订单已创建事件”。它用于实现限界上下文之间的松耦合通信是响应式编程和事件驱动架构的基础。仓储负责聚合的持久化和检索。它抽象了数据访问细节让领域层可以专注于业务逻辑而不关心数据是存在MySQL、Redis还是哪里。仓储接口定义在领域层实现在基础设施层。工厂负责复杂聚合的创建逻辑特别是当创建过程本身包含重要业务规则时。3. DDD的落地实操一个订单创建的完整流程理论说再多不如看一个简化但完整的例子。我们以电商的“创建订单”这个核心流程为例看看DDD思想如何贯穿从需求到代码。3.1 战略设计识别上下文首先我们通过事件风暴识别出“创建订单”涉及的核心上下文订单上下文负责订单的生命周期管理。商品上下文提供商品信息、价格、库存状态。用户上下文提供用户信息、收货地址。支付上下文处理支付流程。这里“订单上下文”是我们的核心子域。“商品上下文”可能是支撑子域如果库存逻辑复杂或通用子域如果只是简单查询。“用户上下文”和“支付上下文”很可能是通用子域由统一平台提供。3.2 战术建模构建订单聚合在“订单上下文”内部我们进行战术建模。识别聚合“订单”显然是一个聚合根。一个订单包含哪些东西订单项OrderItem、收货地址ShippingAddress值对象、价格信息Price值对象。这些都应该被封装在“订单”聚合内部。为什么“订单项”不是独立的聚合因为订单项脱离了订单没有独立存在的意义它的生命周期和业务规则如修改、删除必须严格受订单控制。设计实体与值对象Order(实体聚合根)包含订单ID、状态、用户ID、总金额等。有place(),pay(),cancel()等方法。OrderItem(实体)包含商品SKU、数量、单价、小计等。ShippingAddress(值对象)包含收件人、电话、详细地址等。不可变。Money(值对象)封装金额和货币单位提供安全的加减乘除运算。定义领域事件当订单创建成功时会发布一个OrderPlacedEvent事件里携带订单ID、商品列表、总金额等信息。商品上下文可以订阅这个事件去扣减库存。3.3 代码结构与应用层职责典型的DDD分层代码结构如下- application/ # 应用层 - dto/ # 数据传输对象 (入参/出参) - service/ # 应用服务 - OrderAppService.java # 协调领域层完成用例 - event/ # 应用层事件监听/发布 - domain/ # 领域层 (核心!) - model/ # 领域模型 - Order.java # 聚合根 - OrderItem.java - ShippingAddress.java - Money.java - event/ # 领域事件定义 - OrderPlacedEvent.java - service/ # 领域服务 (如果需要) - repository/ # 仓储接口 - OrderRepository.java - infrastructure/ # 基础设施层 - persistence/ # 持久化实现 - OrderRepositoryImpl.java # 实现领域层的仓储接口 - client/ # 外部服务调用 (如调用商品API) - ProductClient.java - message/ # 消息队列实现 - interfaces/ # 接口层 (或叫adapter层) - web/ # Web控制器 - OrderController.java - rpc/ # RPC接口应用服务OrderAppService的职责 它不包含业务逻辑只是一个协调者和事务管理者。它的典型流程是通过仓储获取聚合或创建新聚合。调用聚合根上的领域方法执行业务操作如order.place(...)。调用仓储保存聚合。发布领域事件如果需要。// OrderAppService.java (应用层) Service Transactional public class OrderAppService { Autowired private OrderRepository orderRepository; Autowired private ProductClient productClient; // 基础设施层客户端 Autowired private ApplicationEventPublisher eventPublisher; public OrderDTO placeOrder(PlaceOrderCommand command) { // 1. 参数校验 (基础校验) // 2. 调用外部防腐层获取商品信息 (避免直接污染领域层) ListProductInfo productInfos productClient.getProductInfos(command.getSkuList()); // 3. 创建订单聚合 (工厂模式) Order order OrderFactory.create( command.getUserId(), command.getAddress(), productInfos, command.getItems() ); // 4. 执行业务逻辑 (调用领域方法) order.place(); // 5. 保存聚合 orderRepository.save(order); // 6. 发布领域事件 (异步解耦) eventPublisher.publishEvent(new OrderPlacedEvent(order.getId(), ...)); // 7. 返回DTO return OrderAssembler.toDTO(order); } }领域对象Order的职责 它封装了核心业务规则和状态变化。// Order.java (领域层 - 聚合根) public class Order extends AggregateRoot { // AggregateRoot 可能是一个标记接口或基类 private OrderId id; private UserId userId; private ShippingAddress address; private ListOrderItem items; private Money totalAmount; private OrderStatus status; // 核心领域行为 public void place() { // 业务规则校验 if (this.status ! null) { throw new IllegalOrderStateException(订单已存在不能重复创建); } if (items.isEmpty()) { throw new EmptyOrderException(订单项不能为空); } // 计算总金额 (这是一个不变条件) this.totalAmount calculateTotal(); // 状态变迁 this.status OrderStatus.CREATED; // 记录领域事件 registerEvent(new OrderPlacedEvent(this.id, this.items, this.totalAmount)); } private Money calculateTotal() { // 调用OrderItem上的方法进行计算确保逻辑内聚 return items.stream() .map(OrderItem::getSubTotal) .reduce(Money.ZERO, Money::add); } // 其他领域方法如 pay(), cancel(), addItem() 等 // 注意所有修改内部状态的方法都应该是“命令式”的并有明确的业务意图。 }3.4 上下文协作防腐层与领域事件订单创建需要商品信息。我们不应该在Order聚合里直接调用商品上下文的API那会造成强耦合和模型污染。正确的做法是在应用服务里通过基础设施层的ProductClient防腐层获取外部数据。将外部数据转换为当前上下文所需的内部模型如ProductInfo值对象。将这个内部模型传递给领域工厂或聚合进行创建。库存扣减则通过领域事件OrderPlacedEvent异步触发。商品上下文监听该事件在自己的事务边界内处理扣减逻辑。这保证了订单上下文和商品上下文的松耦合与各自的数据一致性。4. DDD实践中的常见“坑”与应对策略DDD听起来美好但实践中处处是陷阱。下面是我总结的几个高频问题。4.1 贫血模型与充血模型之辩这是最常见的反模式。贫血模型是指对象只有getter/setter和简单的数据所有业务逻辑都放在所谓的“Service”里。这本质还是面向过程的思维失去了面向对象封装的优势。DDD推崇的是充血模型数据和操作该数据的行为封装在一起。Order不应该只是一个OrderDO数据对象它应该有place(),pay(),cancel()等方法。判断标准很简单当你需要修改一个业务规则时你是去改一个“Service”里的几百行代码还是去修改对应的领域对象内部的一个方法后者显然更清晰、更安全。实操技巧强制自己不要在领域实体里写公共的setter方法。状态的改变必须通过具有业务含义的方法来完成。比如不要order.setStatus(PAID)而是调用order.pay(paymentInfo)在pay()方法内部去校验并修改状态。这强制你思考行为而不仅仅是数据。4.2 聚合设计过大或过小聚合过大把太多实体塞进一个聚合导致每次加载和保存聚合的性能开销巨大且并发修改容易冲突。例如把“用户”和其所有的“订单”放在一个聚合里。聚合过小把本应内聚的实体拆成多个聚合导致无法在单个事务内维护强一致性规则。例如把“订单”和“订单项”拆成两个聚合那么“订单总金额等于所有订单项小计之和”这个规则就难以保证。设计原则不变一致性聚合边界内必须维护的强业务规则。高频一起修改总是一起变化的事物应该放在一起。性能考量聚合不宜过大要评估加载整个聚合的成本。最终一致性是可接受的跨聚合的规则可以通过领域事件和最终一致性来保证。4.3 领域服务滥用领域服务是“最后的选择”。如果能将行为放在实体或值对象内就绝不放领域服务。滥用领域服务会导致“事务脚本”模式回归业务逻辑再次变得分散和难以理解。领域服务应该处理那些涉及多个聚合协调的场景如转账。执行复杂的、无状态的业务计算或策略。与外部系统交互但通常通过应用服务调用防腐层更好。4.4 基础设施层对领域层的“泄露”这是架构整洁性的关键。领域层绝对不能直接依赖基础设施层的具体实现如Spring的Component、MyBatis的Mapper、数据库驱动等。领域层只定义仓储接口OrderRepository具体实现在基础设施层。领域对象也不应该有任何JPA或MyBatis的注解如Entity,Table这些注解属于持久化细节应该通过基础设施层的映射如DO到Entity的转换来处理。4.5 DDD与微服务架构的混淆再次强调先做战略设计划分限界上下文。然后根据团队结构、技术能力、部署复杂度等因素决定哪些限界上下文需要成为独立的微服务。一个微服务可以包含一个或多个关系紧密的限界上下文对应一个或多个聚合。不要一开始就按数据库表或功能模块来划分微服务那会带来分布式事务和网络通信的噩梦却没有得到DDD在模型清晰度上的好处。5. DDD的价值与适用场景不是所有项目都需要经过以上剖析DDD的价值可以总结为三点提升代码可维护性通过清晰的模型边界和丰富的领域对象让代码结构直接反映业务概念新人上手快老代码修改风险低。增强业务响应力当业务规则变化时变更通常被隔离在特定的聚合或限界上下文内影响范围可控。改善团队协作统一语言让业务、产品、开发能高效、无歧义地沟通。但是DDD有显著的学习成本和实践成本。它不是银弹适用于业务逻辑复杂有大量的业务规则、状态流转和校验逻辑。生命周期长项目需要长期迭代和维护。团队规模较大需要清晰的模块边界来协作。对于简单的CRUD管理系统、一次性脚本、或业务逻辑极其稳定的系统引入完整的DDD可能是一种过度设计传统的分层架构或许更高效。我个人最深的体会是DDD最难的不是学会那些模式而是思维模式的转变。从“数据库驱动设计”转向“领域驱动设计”要求开发者从一拿到需求就想着建表转变为先和业务专家深入沟通理解业务术语、规则和流程并用代码将这些概念精准地表达出来。这个过程初期会很痛苦但一旦跨过那个门槛你会发现你写的不仅仅是代码而是对业务本身深刻理解的结晶。这种代码经得起时间的变化也扛得住需求的冲刷。它让软件开发从一种被动的实现变成一种主动的设计和创造。 
长河君 · 2026/8/22 8:43:15 · 阅读 1.2k DDD领域驱动设计：从统一语言到聚合建模的工程实践
1. 从“玄学”到“工程”我眼中的DDD本质“DDD”这三个字母在技术圈里尤其是最近几年热度一直居高不下。无论是招聘要求里的“熟悉DDD者优先”还是技术分享会上频频出现的“领域驱动设计”都让很多开发者既好奇又困惑。我见过不少团队一提到DDD要么觉得是“大厂专属”、“过度设计”要么就是买几本书、画几张“六边形架构”图然后项目代码该咋写还咋写最后得出结论DDD没啥用净整些虚的。作为一个在多个复杂业务系统中实践过DDD的过来人我想说这种认知偏差太普遍了。DDD从来就不是一个可以直接“安装”的框架也不是一套必须严格遵守的“教条”。它更像是一套思维方式和沟通工具核心目标只有一个让软件的核心逻辑代码能够精准地反映并服务于真实的业务规则领域知识。它解决的是随着业务复杂度提升代码逐渐失控、难以理解、难以演进的“慢性病”。简单来说DDD就是教你如何把业务专家嘴里那些“行话”领域语言变成程序员手里清晰、可维护的代码结构。它不是什么银弹但对于处理业务规则复杂、变化频繁的系统它能帮你把“一团乱麻”理成“清晰脉络”。今天我就结合自己踩过的坑和成功的经验把DDD从“玄学”拉回“工程”聊聊它到底是什么以及到底该怎么用。2. DDD的核心思想拆解不止是分层和实体很多人初学DDD都是从“四层架构”接口层、应用层、领域层、基础设施层或者“实体”、“值对象”、“聚合根”这些战术模式开始的。这没错但这些只是“术”是工具。如果只学这些很容易陷入“为DDD而DDD”的困境。我们必须先理解它的“道”。2.1 统一语言打破沟通的巴别塔这是DDD最核心、也最容易被忽视的基石。在传统开发中产品经理说“用户下单”开发可能理解成“往order表里插一条记录”测试可能理解成“点击提交按钮”。同一个词在不同角色脑海里映射的是完全不同的东西。这种认知偏差是项目后期各种bug和返工的根源。DDD强调项目组所有成员业务、产品、开发、测试必须就核心业务概念建立一套精确的、无歧义的统一语言。这套语言中的每个词都对应着领域模型中的一个核心概念。实操心得统一语言不是开几次会就能定下来的。我们的做法是在项目启动阶段组织“事件风暴”工作坊。把业务专家、产品、核心开发拉到一起用便利贴梳理出所有的业务事件如“订单已创建”、“库存已扣减”、命令如“创建订单”、“支付订单”和核心实体。这个过程本身就是统一语言的过程。最终产出的不仅是一堆便利贴更是一份所有角色都认可的“领域词典”。后续所有的需求讨论、代码命名类名、方法名、变量名、甚至数据库表名都必须严格使用这份词典里的词汇。2.2 战略设计划分清晰的业务疆域当业务非常庞大时你不可能用一个单一的、庞大的模型去描述一切。那样只会让模型变得臃肿、脆弱。战略设计就是用来“分而治之”的。领域你所要解决的整个业务问题空间。比如一个电商系统其领域就包含了商品、订单、库存、营销、支付等。子域将庞大领域按业务功能或职责进行划分。子域分为三类核心子域公司的核心竞争力所在是业务差异化的关键。比如电商的“商品推荐算法”、“个性化营销系统”。这里应该投入最好的资源采用最复杂的领域模型。支撑子域不是核心竞争力但业务运转必不可少。比如电商的“库存管理系统”、“物流跟踪系统”。它们需要被定制开发但不必追求极致模型。通用子域行业通用解决方案没有业务差异性。比如“用户认证”、“权限管理”。这类子域强烈建议直接使用成熟的开源方案或购买SaaS服务不要自己造轮子。限界上下文这是战略设计的核心产出。它定义了一个模型即统一语言的边界。在边界之内一个术语如“产品”有且仅有一种明确的含义跨过边界同一个词可能代表不同的东西。比如在“商品”上下文中“产品”关注的是类目、属性、详情在“订单”上下文中“产品”可能只关心SKU、价格、名称。限界上下文之间的交互通过上下文映射来定义比如采用“防腐层”ACL来隔离外部上下文的模型变化或者采用“发布/订阅”事件进行松耦合通信。避坑指南新手最容易犯的错误是把“限界上下文”等同于“微服务”。虽然它们经常被一起讨论但本质不同。限界上下文是逻辑边界微服务是物理边界。一个限界上下文可以是一个微服务也可以是一个模块在单体架构中甚至多个关系紧密的限界上下文可以放在同一个微服务里。划分限界上下文的首要依据是语言和模型的统一性而不是技术或团队结构。过早地按微服务划分可能导致上下文边界模糊产生混乱的依赖。2.3 战术设计在边界内构建精致模型这是在限界上下文内部我们具体写代码时使用的工具集。这是大家最熟悉的部分但要用好必须理解其设计意图。实体有唯一标识ID和生命周期的事物。比如“用户”、“订单”。它的相等性由ID决定。实体的核心是行为而不仅仅是数据容器。它应该封装自己的业务规则。值对象没有唯一标识通过其属性值来定义的事物。比如“地址”、“金额”。它应该是不可变的。两个所有属性都相同的值对象可以被视为相等。使用值对象可以极大地增强代码的表达能力和安全性比如用Money类封装金额和货币避免直接用BigDecimal。聚合这是战术设计中最关键的概念。聚合是一组相关实体和值对象的集合它有一个聚合根。聚合根是外部访问聚合内所有元素的唯一入口。聚合内部维护强一致性规则聚合之间则通过聚合根的ID进行引用维护最终一致性。为什么需要聚合它定义了数据修改的一致性边界。比如“订单”聚合包含了订单根、订单项、收货地址等。修改订单的任何部分都必须通过订单这个根来进行确保了“订单总金额必须等于所有订单项金额之和”这类规则在聚合内瞬间一致。领域服务当某个操作或业务逻辑无法自然地放在任何一个实体或值对象内部时因为它涉及多个聚合的协调或者是一个无状态的业务操作就将其放在领域服务中。比如“资金转账服务”需要协调“转出账户”和“转入账户”两个聚合。领域事件表示领域中发生的、对其它部分有意义的事情。比如“OrderPlacedEvent订单已创建事件”。它用于实现限界上下文之间的松耦合通信是响应式编程和事件驱动架构的基础。仓储负责聚合的持久化和检索。它抽象了数据访问细节让领域层可以专注于业务逻辑而不关心数据是存在MySQL、Redis还是哪里。仓储接口定义在领域层实现在基础设施层。工厂负责复杂聚合的创建逻辑特别是当创建过程本身包含重要业务规则时。3. DDD的落地实操一个订单创建的完整流程理论说再多不如看一个简化但完整的例子。我们以电商的“创建订单”这个核心流程为例看看DDD思想如何贯穿从需求到代码。3.1 战略设计识别上下文首先我们通过事件风暴识别出“创建订单”涉及的核心上下文订单上下文负责订单的生命周期管理。商品上下文提供商品信息、价格、库存状态。用户上下文提供用户信息、收货地址。支付上下文处理支付流程。这里“订单上下文”是我们的核心子域。“商品上下文”可能是支撑子域如果库存逻辑复杂或通用子域如果只是简单查询。“用户上下文”和“支付上下文”很可能是通用子域由统一平台提供。3.2 战术建模构建订单聚合在“订单上下文”内部我们进行战术建模。识别聚合“订单”显然是一个聚合根。一个订单包含哪些东西订单项OrderItem、收货地址ShippingAddress值对象、价格信息Price值对象。这些都应该被封装在“订单”聚合内部。为什么“订单项”不是独立的聚合因为订单项脱离了订单没有独立存在的意义它的生命周期和业务规则如修改、删除必须严格受订单控制。设计实体与值对象Order(实体聚合根)包含订单ID、状态、用户ID、总金额等。有place(),pay(),cancel()等方法。OrderItem(实体)包含商品SKU、数量、单价、小计等。ShippingAddress(值对象)包含收件人、电话、详细地址等。不可变。Money(值对象)封装金额和货币单位提供安全的加减乘除运算。定义领域事件当订单创建成功时会发布一个OrderPlacedEvent事件里携带订单ID、商品列表、总金额等信息。商品上下文可以订阅这个事件去扣减库存。3.3 代码结构与应用层职责典型的DDD分层代码结构如下- application/ # 应用层 - dto/ # 数据传输对象 (入参/出参) - service/ # 应用服务 - OrderAppService.java # 协调领域层完成用例 - event/ # 应用层事件监听/发布 - domain/ # 领域层 (核心!) - model/ # 领域模型 - Order.java # 聚合根 - OrderItem.java - ShippingAddress.java - Money.java - event/ # 领域事件定义 - OrderPlacedEvent.java - service/ # 领域服务 (如果需要) - repository/ # 仓储接口 - OrderRepository.java - infrastructure/ # 基础设施层 - persistence/ # 持久化实现 - OrderRepositoryImpl.java # 实现领域层的仓储接口 - client/ # 外部服务调用 (如调用商品API) - ProductClient.java - message/ # 消息队列实现 - interfaces/ # 接口层 (或叫adapter层) - web/ # Web控制器 - OrderController.java - rpc/ # RPC接口应用服务OrderAppService的职责 它不包含业务逻辑只是一个协调者和事务管理者。它的典型流程是通过仓储获取聚合或创建新聚合。调用聚合根上的领域方法执行业务操作如order.place(...)。调用仓储保存聚合。发布领域事件如果需要。// OrderAppService.java (应用层) Service Transactional public class OrderAppService { Autowired private OrderRepository orderRepository; Autowired private ProductClient productClient; // 基础设施层客户端 Autowired private ApplicationEventPublisher eventPublisher; public OrderDTO placeOrder(PlaceOrderCommand command) { // 1. 参数校验 (基础校验) // 2. 调用外部防腐层获取商品信息 (避免直接污染领域层) ListProductInfo productInfos productClient.getProductInfos(command.getSkuList()); // 3. 创建订单聚合 (工厂模式) Order order OrderFactory.create( command.getUserId(), command.getAddress(), productInfos, command.getItems() ); // 4. 执行业务逻辑 (调用领域方法) order.place(); // 5. 保存聚合 orderRepository.save(order); // 6. 发布领域事件 (异步解耦) eventPublisher.publishEvent(new OrderPlacedEvent(order.getId(), ...)); // 7. 返回DTO return OrderAssembler.toDTO(order); } }领域对象Order的职责 它封装了核心业务规则和状态变化。// Order.java (领域层 - 聚合根) public class Order extends AggregateRoot { // AggregateRoot 可能是一个标记接口或基类 private OrderId id; private UserId userId; private ShippingAddress address; private ListOrderItem items; private Money totalAmount; private OrderStatus status; // 核心领域行为 public void place() { // 业务规则校验 if (this.status ! null) { throw new IllegalOrderStateException(订单已存在不能重复创建); } if (items.isEmpty()) { throw new EmptyOrderException(订单项不能为空); } // 计算总金额 (这是一个不变条件) this.totalAmount calculateTotal(); // 状态变迁 this.status OrderStatus.CREATED; // 记录领域事件 registerEvent(new OrderPlacedEvent(this.id, this.items, this.totalAmount)); } private Money calculateTotal() { // 调用OrderItem上的方法进行计算确保逻辑内聚 return items.stream() .map(OrderItem::getSubTotal) .reduce(Money.ZERO, Money::add); } // 其他领域方法如 pay(), cancel(), addItem() 等 // 注意所有修改内部状态的方法都应该是“命令式”的并有明确的业务意图。 }3.4 上下文协作防腐层与领域事件订单创建需要商品信息。我们不应该在Order聚合里直接调用商品上下文的API那会造成强耦合和模型污染。正确的做法是在应用服务里通过基础设施层的ProductClient防腐层获取外部数据。将外部数据转换为当前上下文所需的内部模型如ProductInfo值对象。将这个内部模型传递给领域工厂或聚合进行创建。库存扣减则通过领域事件OrderPlacedEvent异步触发。商品上下文监听该事件在自己的事务边界内处理扣减逻辑。这保证了订单上下文和商品上下文的松耦合与各自的数据一致性。4. DDD实践中的常见“坑”与应对策略DDD听起来美好但实践中处处是陷阱。下面是我总结的几个高频问题。4.1 贫血模型与充血模型之辩这是最常见的反模式。贫血模型是指对象只有getter/setter和简单的数据所有业务逻辑都放在所谓的“Service”里。这本质还是面向过程的思维失去了面向对象封装的优势。DDD推崇的是充血模型数据和操作该数据的行为封装在一起。Order不应该只是一个OrderDO数据对象它应该有place(),pay(),cancel()等方法。判断标准很简单当你需要修改一个业务规则时你是去改一个“Service”里的几百行代码还是去修改对应的领域对象内部的一个方法后者显然更清晰、更安全。实操技巧强制自己不要在领域实体里写公共的setter方法。状态的改变必须通过具有业务含义的方法来完成。比如不要order.setStatus(PAID)而是调用order.pay(paymentInfo)在pay()方法内部去校验并修改状态。这强制你思考行为而不仅仅是数据。4.2 聚合设计过大或过小聚合过大把太多实体塞进一个聚合导致每次加载和保存聚合的性能开销巨大且并发修改容易冲突。例如把“用户”和其所有的“订单”放在一个聚合里。聚合过小把本应内聚的实体拆成多个聚合导致无法在单个事务内维护强一致性规则。例如把“订单”和“订单项”拆成两个聚合那么“订单总金额等于所有订单项小计之和”这个规则就难以保证。设计原则不变一致性聚合边界内必须维护的强业务规则。高频一起修改总是一起变化的事物应该放在一起。性能考量聚合不宜过大要评估加载整个聚合的成本。最终一致性是可接受的跨聚合的规则可以通过领域事件和最终一致性来保证。4.3 领域服务滥用领域服务是“最后的选择”。如果能将行为放在实体或值对象内就绝不放领域服务。滥用领域服务会导致“事务脚本”模式回归业务逻辑再次变得分散和难以理解。领域服务应该处理那些涉及多个聚合协调的场景如转账。执行复杂的、无状态的业务计算或策略。与外部系统交互但通常通过应用服务调用防腐层更好。4.4 基础设施层对领域层的“泄露”这是架构整洁性的关键。领域层绝对不能直接依赖基础设施层的具体实现如Spring的Component、MyBatis的Mapper、数据库驱动等。领域层只定义仓储接口OrderRepository具体实现在基础设施层。领域对象也不应该有任何JPA或MyBatis的注解如Entity,Table这些注解属于持久化细节应该通过基础设施层的映射如DO到Entity的转换来处理。4.5 DDD与微服务架构的混淆再次强调先做战略设计划分限界上下文。然后根据团队结构、技术能力、部署复杂度等因素决定哪些限界上下文需要成为独立的微服务。一个微服务可以包含一个或多个关系紧密的限界上下文对应一个或多个聚合。不要一开始就按数据库表或功能模块来划分微服务那会带来分布式事务和网络通信的噩梦却没有得到DDD在模型清晰度上的好处。5. DDD的价值与适用场景不是所有项目都需要经过以上剖析DDD的价值可以总结为三点提升代码可维护性通过清晰的模型边界和丰富的领域对象让代码结构直接反映业务概念新人上手快老代码修改风险低。增强业务响应力当业务规则变化时变更通常被隔离在特定的聚合或限界上下文内影响范围可控。改善团队协作统一语言让业务、产品、开发能高效、无歧义地沟通。但是DDD有显著的学习成本和实践成本。它不是银弹适用于业务逻辑复杂有大量的业务规则、状态流转和校验逻辑。生命周期长项目需要长期迭代和维护。团队规模较大需要清晰的模块边界来协作。对于简单的CRUD管理系统、一次性脚本、或业务逻辑极其稳定的系统引入完整的DDD可能是一种过度设计传统的分层架构或许更高效。我个人最深的体会是DDD最难的不是学会那些模式而是思维模式的转变。从“数据库驱动设计”转向“领域驱动设计”要求开发者从一拿到需求就想着建表转变为先和业务专家深入沟通理解业务术语、规则和流程并用代码将这些概念精准地表达出来。这个过程初期会很痛苦但一旦跨过那个门槛你会发现你写的不仅仅是代码而是对业务本身深刻理解的结晶。这种代码经得起时间的变化也扛得住需求的冲刷。它让软件开发从一种被动的实现变成一种主动的设计和创造。