系统变的复杂，系统的层次划分越来越细，边界也越来越明确。 然后每一层之间一般都有自己要处理的领域对象，统称为pojo一般在model或者domain包下(类的后缀不能为pojo)。
常见的一些模型类型：
- PO、DO：持久层对象，一般和数据库直接打交道。
- DTO：数据传输对象，系统之间的交互，再服务层提供服务的时候输出到其它系统。
- VO：视图对象，用于前端模型展示。 当然有时候前端也可以看做另外一个系统，使用DTO模型；
- BO：业务逻辑对象，比较少用...
为什么模型要分这么多层？
在复杂一点的业务中，业务建模是非常有必要的，一定要抽象出业务上常用的领域模型，统一技术和非技术同学的语言。
建完模型之后，在技术的系统中，为了方便维护代码，分离关注点，也会进行再次分层，让每一层解决特定的问题。模型的分层是随着系统的分层而来的；试想所有的模型属性在一个对象中，这个对象你看的懂吗？
举个实际的案例：
-
数据层一般用DO
-
现在要透出数据给其他系统，DO中一般都会有创建人，创建时间，修改人，修改时间，当前对象所处的环境等信息； 但是外部的系统需要环境、创建人信息吗？ 很多时候不需要，站在数据安全的角度，一般只透出必要的字段就可以； 这些要输出要外部系统的必要字段，一般定义在DTO中。
-
到前端系统，前端系统展示上所需的逻辑和输出到外部系统的又有点不太一样，前端系统可能要创建人，创建时间，但是不要另外一些东西，或者一些敏感的配置不能透出给前端，这个时候一般也会再定义一个新的对象。
简单说就是当我们的系统要输出能力到外部系统的时候，不同系统要的数据不一样，数据安全要求我们不能透出这么多的数据，一定要做一层处理。 另外给另外一个系统关注的数据，而不是一股脑的全部都给对方，对方处理起来也方便。
模型之间的转换
建议不要用的方式
- 手写get\set； 虽然性能高，但是费劲并且眼花缭乱，一不小心就写错了，难以维护，复用度不高
- BeanUtils，apacha和spring包下都有对应的类，但是底层用到的都是反射，性能比较差，大流量的情况下一般不用
- 直接fastjson，gc会很频繁，而且性能比较差
常用的方式
- cglib的beanCopier，开销在创建BeanCopier，一般在创建类的时候提前创建好一个，在代码运行的时候直接进行copy，性能接近原生。
- mapstruct 性能和原生代码一样，支持复杂的转化场景，实现原理同lombok编译的时候生成对应的代码。
以上从技术分类的角度来看：
- 反射：fastjson，beanutil 都不建议用
- get\set： beancoper通过字节码进行getset，mapstruct编译的时候生成getset。 性能相对较好。
使用方式
个人觉得，如果说对象比较简单的时候，使用BeanCopier就可以了，因为spring的aop依赖cglib，默认情况下就已经引入了对应的包了，不需要额外的依赖直接就可以用。
如果很复杂的模型之间的转换，并且对性能有更极致的要求，考虑使用下MapStruct。
定义对象
UserDO
@Data
public class UserDO {
private Long id;
private String name;
private Integer gender;
private String password;
private Date gmtCreate;
private Date gmtModified;
}
复制代码
UserDTO
@Data
public class UserDTO {
private Long id;
private String name;
private Integer gender;
}
复制代码
BeanCopier
最简单的使用方式
B
