这里写目录标题

• • 公司开发常用的 mvc 三层架构
  • 那为什么公司大都是基于贫血模型设计的业务呢？

小时候妈妈说我贫血 ，长大了才知道我真的贫血

公司开发常用的 mvc 三层架构

M 表示model，V 表示 view ，C 表示controller ，从项目来说 分为三层，展示层、逻辑层、数据层， repository负责数据访问，service负责业务逻辑，controller负责暴露接口。

通常来说代码时这么写的

// 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;
}

一部分项目为了简单 不区分 entity、bo 和vo ，比如公司内部比较简单的单体应用等，对于扁平快的要求也可以理解。

UserBo 是一个纯粹的数据结构，只包含数据，不包含任何业务逻辑。
业务逻辑集中在 UserService 中。我们通过 UserService 来操作 UserBo。换句话说，Service 层的数据和业务逻辑，被分割为 BO 和 Service 两个类中。
像 UserBo 这样，只包含数据，不包含业务逻辑的类，就叫作贫血模型（Anemic Domain Model）。
同理，UserEntity、UserVo 都是基于贫血模型设计的。这种贫血模型将数据与操作分离，破坏了面向对象的封装特性，是一种典型的面向过程的编程风格。

也即是说，我们大部分的项目几乎都是贫血模型设计开发的。

那充血模型呢，和ddd（领域驱动设计）有关系，他也是包含三层，不同的是 ，他的service层包含service和domin两部分，domain是基于充血模型开发的，包含数据和业务逻辑，service层反而比较单薄， 轻service 重domian

那为什么公司大都是基于贫血模型设计的业务呢？

原因有如下
一、大部分情况业务比较简单，都是 基于sql 操作crud，没有什么太复杂的业务逻辑，即使是按照充血模型设计，也看起来比较单薄
二、充血模型设计有难度，需要开发前设好，不像贫血模型，面向过程变成，定义好数据，有什么功能，再添加，很多时候需求也不不断来的
三、思维固化，学习成本高
四、互联网各种层出不穷的需求变动，短命的项目生存周期

那么我们可以分析出什么业务适合充血模型
1、业务比较复杂，比如各种利息计算模型，还款模型复杂的金融系统
2、对人员要求比较高，需要实现梳理清楚所有的业务，定义领域模型所包含的属性和方法

ddd更像一个多方面的方法论，涉及团队沟通，需求分析，业务建模，设计，编码，业务根据场景选择性应用，追求极致ddd成本很高，对团队成员的能力要求也很高。而且ddd的价值体现在中后期，比如代码可维护性，bug率，复用程度等。对于大部分互联网短平快的需求，而且生命周期较短的功能，还不如CRUD来得直接。只有业务发展趋向稳定，更关注产品质量时，ddd才能开始体现价值。

综上所述，对应中小公司，和大公司中的小团队，最有应用价值的还是基于贫血模型开发的mvc模式
所以，DDD并不是银弹，还是要根据实际情况采用合适的开发模式

当然，对于个人来说，还是很希望能够参与DDD开发的项目。