TingBen 2019-12-27
现在传统的MVC开发基本上都是贫血模型 如以下代码 我们工作中经常使用
////////// Controller+VO(View Object) ////////// public class UserController { private UserService userService; //通过构造函数或者IOC框架注入 public UserVo getUserById(Long userId) { UserBo userBo = userService.getUserById(userId); UserVo userVo = [...convert userBo to userVo...]; return userVo; } } public class UserVo {//省略其他属性、get/set/construct方法 private Long id; private String name; private String cellphone; } ////////// Service+BO(Business Object) ////////// public class UserService { private UserRepository userRepository; //通过构造函数或者IOC框架注入 public UserBo getUserById(Long userId) { UserEntity userEntity = userRepository.getUserById(userId); UserBo userBo = [...convert userEntity to userBo...]; return userBo; } } public class UserBo {//省略其他属性、get/set/construct方法 private Long id; private String name; private String cellphone; } ////////// Repository+Entity ////////// public class UserRepository { public UserEntity getUserById(Long userId) { //... } } public class UserEntity {//省略其他属性、get/set/construct方法 private Long id; private String name; private String cellphone; }
我们将所有业务逻辑都写在servcie里面 将BO和业务逻辑根据service分离开了,这是一种面向过程的风格开发方式
在贫血模型中,数据和业务逻辑被分割到不同的类中。充血模型(Rich Domain Model)正好相反,数据和对应的业务逻辑被封装到同一个类中。因此,这种充血模型满足面向对象的封装特性,是典型的面向对象编程风格
主要用来指导如何解耦业务系统,划分服务模块,定义业务领域模型及其交互 早在2014年就剔除,真正兴起是在微服务兴起的时候.微服务需要根据公司业务对服务进行合理的划分。而ddd正好可以做到指导的作用
实际上DDD也是传统的MVC三层 在service加了一层doman 跟贫血不一样的是 BO除了包含数据 还包含了对应数据的业务处理
贫血模型:重Service 轻Bo 充血模型:轻Service 重Bo
业务复杂的项目应该优先考虑使用DDD开发模式
因为贫血模型 我们是基于业务再service定义个对数据表CRUD的操作,对业务耦合性比较大,无法重用,
而基于ddd则是根据模型定义好要暴露的操作 然后在service根据业务使用这些暴露的操作完成一系列业务,复用性更强 越复杂的系统对重用性要求更强