背景
MVC架构的传统开发是基于数据库表的贫血模型。贫血模型最大的问题是数据对象很容易被替代。比如一个很复杂的工程，现在要加一个用户信息的简单查询。虽然工程中已经有一个UserDTO，但是由于service过于复杂，导致新接手的开发人员不愿意去看这个service而是创建一个UserSimpleDTO直接去查表。
service中有可能会涉及到权限，限定，等条件而新写的接口很容易被忽略。这种情况很容易会出现UserDTO和UserSimpleDTO的查询结果不一致。
而DDD架构太过于复杂学习成本高，不容易落地。
DDD简化版
目录分层：
Adapter： 定义对外的接口，http和rpc
Application： 应用服务，实现具体的需求
Domain：领域服务，封装领域的实体，将应用服务和仓储服务串联
Infrastructure: 基础服务，负责持久层或第三方服务的接入。
DO对象：数据对象,对应的是数据库表的映射或rpc的映射
Domain对象：领域对象，封装领域内的实体,行为和规则。
BO对象： 业务对象，是根据业务而形成的多个领域的聚合。
DTO对象：数据传输对象，前端或rpc需要的数据对象。
如何应用
我们以一个具体的业务场景来举例：
- 产品需求需要查询所有的用户信息
MVC:
//从数据库里拿到持久层对象
UserPO userPo = userDao.list();
UserDTO userDTO = UserConvert.toDTO(userPO);
DDBD:
//从数据库里拿到领域对象
User user = userDao.list();
//领域对象转化为需要的业务对象
UserBO userBO = UserAppConvert.toBO(user);
//将bo转化为dto
UserDTO userDTO = UserAdapterConvert.toDTO(userBO)
2. 产品现在需要查询所有用户信息和他的部门信息
MVC:
第一种：
//从数据库里拿到持久层对象
UserDeptPO userDeptPO = userDeptdao.list();
UserDeptDTO userDeptDTO = UserConvert.toDTO(userDeptPO);
第二种：
//查询user
UserPO = userPO = userDAO.list();
//查询部门
DeptDTO DeptDTO = deptService.list();
UserDeptDTO userDeptDTO = UserDeptConvert.toDTO(userPO,deptDTO)
DDBD:
//从数据库里拿到领域对象
User user = userDao.list();
//领域对象转化为需要的业务对象
UserBO userBO = UserAppConvert.toBO(user);
//组装部门信息
userAppAssembler.assembleDept();
//将bo转化为dto
UserDeptDTO userDeptDTO = UserAdapterConvert.toDTO(userBO)
从上面的案例可以发现使用MVC开发时，当产品需求发生变动相当于service重新开发，而且复用很差。
而DDBD能很好的服用，只需要根据产品的需求调用组装方法获得需要的参数。
