业务逻辑全塞在 Service 层项目上线半年后为什么连加个字段都不敢你在面试时肯定听过“高内聚低耦合”。但看看实际的项目代码大部分情况还是从 Controller 接收 DTO传给 ServiceService 里写几百行甚至几千行的if-else和业务逻辑最后调用 Dao 存进数据库。这套 CRUD 模式在项目初期开发极快这也是它能流行这么多年的原因。但等项目上线半年后业务开始加需求了。比如原来只卖普通商品现在要加虚拟商品、组合商品、秒杀商品。原来只用校验库存现在还要算会员折扣、积分抵扣、黑名单拦截。这个时候你的OrderService.createOrder()方法可能已经膨胀到了 800 行。当你接到一个“商品下架时判断如果是组合商品则同时下架子商品”的需求时你打开 Service 层看着里面错综复杂的校验和状态流转心里只剩下一个想法加个字段或者改个if会不会把别的逻辑搞崩这就是典型的发展痛点代码腐化。不敢重构的原因是没有边界。这种把所有状态判断、计算逻辑都堆在 Service 层而实体类Entity只包含get和set方法的写法被称为“贫血模型”Anemic Domain Model。数据和行为是彻底分离的。领域驱动设计DDDDomain-Driven Design给出了一种解法。核心变化是把业务规则收拢回对象本身也就是所谓的“充血模型”。来看一个直观的例子。在传统的贫血模型中我们修改密码通常是这样写的publicvoidchangePassword(LonguserId,StringnewPassword){UseruseruserMapper.selectById(userId);if(user.getStatus()UserStatus.LOCKED){thrownewBizException(账号已锁定);}// 很多很多其他校验...user.setPassword(passwordEncoder.encode(newPassword));userMapper.update(user);}这段代码看起来没问题但User的状态规则散落在各个 Service 里。如果哪天加了一个新状态“待激活”你需要去所有用到 User 的 Service 里把相关判断都加一遍。漏掉一个就是线上 Bug。换成 DDD 的充血模型思路业务逻辑是属于User领域的它应该长这样// User 实体内部publicvoidchangePassword(StringnewPassword,PasswordEncoderencoder){if(this.statusUserStatus.LOCKED){thrownewBizException(账号已锁定无法修改密码);}this.passwordencoder.encode(newPassword);}然后在应用服务层Application Service里代码变成了纯粹的流程编排publicvoidchangePassword(LonguserId,StringnewPassword){UseruseruserRepository.findById(userId);user.changePassword(newPassword,passwordEncoder);userRepository.save(user);}注意到了吗核心业务规则不再由 Service 掌管而是实体类自己维护自己的不变量Invariants。不管有多少个入口需要修改密码校验逻辑永远在实体内部不会散落。这只是 DDD 的冰山一角。更宏观层面上DDD 强调“限界上下文”Bounded Context。在大型系统中用户的概念在登录模块、订单模块、物流模块里是完全不同的。如果不做上下文隔离大家都去修改那张包含了上百个字段的巨大t_user表项目最终必然变成一团乱麻。划清边界让领域对象自己管理自己的状态是 DDD 应对软件复杂度的有效手段。但千万别为了 DDD 而 DDD。如果你只是在写一个简单的后台管理系统每天的需求就是加减几个表单字段用 MVC 加上贫血模型绝对是开发效率最高的。DDD 引入了聚合根、值对象、领域服务等大量新概念它的存在是为了应对复杂的业务变化而不是为了让简单的增删改查变得高端。评估你的项目如果是强业务规则、多状态流转、高复杂度的系统下一次写代码前可以试着先把逻辑放进对象里而不是 Service 里。
