DDD领域驱动设计的初步认识DDD领域驱动设计一直是 Java 后端中讨论度很高的话题。有人觉得它是复杂系统的救星也有人觉得它过度设计。在真正学习 DDD 的各种概念之前更重要的问题其实是DDD 到底解决了什么问题目录传统架构的痛点DDD 是什么DDD 和传统架构的区别什么时候该用 DDD小结传统架构的痛点做 Java 后端开发的同学对三层架构一定不陌生Controller 接收请求Service 处理业务逻辑DAO 操作数据库。这个分层方式清晰直观上手也快很多项目一开始都是这么搭的。但随着业务越来越复杂真正的问题不是 Controller、Service、DAO 三层不够而是业务规则越来越分散。创建订单能不能取消什么时候允许退款库存什么时候扣减积分什么时候发放这些规则到底应该写在哪里有人写在 Controller有人写在 Service还有人放进各种 Util 或 Manager 中。时间一长同一个业务被拆散到多个地方维护越来越困难。根本原因在于传统三层架构按技术职责组织代码而不是按业务能力组织代码。Controller 负责接收请求Service 负责业务处理DAO 负责数据访问。随着业务越来越复杂一个业务会同时分散到多个技术层中业务本身的边界反而越来越模糊。DDD 是什么DDD全称 Domain-Driven Design领域驱动设计。2003 年 Eric Evans 在同名书中提出。让代码的结构反映业务的结构而不是数据库表的结构。换句话说就是先思考业务再思考技术。传统架构下代码的组织方式是按技术分层的Controller 层、Service 层、DAO 层。每个层关心的是技术职责不是业务职责。而 DDD 的思路是反过来先搞清楚业务领域是怎么划分的再按业务领域来组织代码。举个例子。一个电商系统按传统架构分层是这样的controller/ OrderController.java UserController.java ProductController.java service/ OrderService.java UserService.java ProductService.java dao/ OrderDao.java UserDao.java ProductDao.java按 DDD 的思路组织是这样的order/ Order.java OrderService.java ... user/ User.java UserService.java ... product/ Product.java ProductService.java ...在传统架构下一个订单相关的逻辑散落在 Controller、Service、DAO 三个目录里。DDD 下订单相关的所有东西都在 order 包里。修改订单相关功能时大部分代码都会集中在 order 模块而不是在 Controller、Service、DAO 三层之间来回切换。DDD 和传统架构的区别两种架构的核心差异可以从几个维度来看维度传统架构DDD设计中心数据库表领域模型代码组织按技术分层Controller/Service/DAO按业务领域划分order/user/product业务逻辑归属散落在各层内聚到领域对象中Entity 对象数据载体贫血模型封装数据和业务行为充血模型数据库依赖Service 直接依赖 DAO通过 Repository 接口隔离新增功能可能要改三个层只改对应的领域模块传统架构下Service 层是业务逻辑的主要承载者但 Service 本身是一个什么都能往里放的容器。一个 OrderService 可能同时负责订单创建、订单查询、订单取消、订单退款、订单状态流转……职责越来越多代码越来越长。DDD 做的事情是把业务逻辑下沉到领域对象里。Order 实体不只是一个数据容器它维护自己的业务规则例如哪些状态允许取消、哪些订单允许退款、状态如何流转等。Service 层变成一个协调者负责编排领域对象完成业务流程而不是把所有逻辑都扛在自己身上。打个比方。传统架构更像是把所有 Java 文件按类型放到不同文件夹Controller、Service、DAO。DDD 更像是按业务模块整理代码订单相关放一起、用户相关放一起、商品相关放一起。找订单代码时不需要在多个目录之间来回切换。什么时候该用 DDD没有万金油的技术DDD同样需要结合项目实际情况去判断是否需要使用。适合 DDD 的场景业务规则复杂、多变。比如电商系统的订单状态流转、金融系统的风控规则、ERP 系统的业务流程。需要长期维护和迭代。DDD 的前期设计成本较高如果项目做一版就扔了不值得投入。团队规模较大。多人协作时清晰的领域边界能减少代码冲突和沟通成本。不适合 DDD 的场景简单 CRUD 系统。比如后台管理系统的增删改查业务逻辑本身就很简单用传统三层架构足够了。数据驱动型系统。比如数据分析平台核心是数据处理和展示不是业务规则。短期项目或原型验证。DDD 的设计成本在前期短期项目用不上。一个简单的判断标准是当业务复杂度开始超过技术复杂度时就可以考虑引入 DDD。小结DDD 的核心目标是让代码结构与业务结构保持一致把业务规则集中到领域模型中而不是分散在各个技术层。它解决的是复杂业务带来的设计和维护问题而不是性能优化或高并发问题。对于业务简单的系统传统三层架构已经足够但当业务不断演进、规则越来越复杂时DDD 能帮助我们更清晰地组织代码降低维护成本也让团队协作更加顺畅。不过真正开始实践 DDD并不是先设计实体、聚合这些战术模型而是先理解业务、划分边界。只有明确了不同业务的职责范围并建立统一的业务语言后续的模型设计才有基础。下一篇我们就来聊聊 DDD 战略设计中的两个核心概念限界上下文Bounded Context和统一语言Ubiquitous Language。
