领域模型层次划分

业务代码由于需要经过好几层的处理，每层需要封装对应的模型， setter/getter代码量不少，而且基本上字段都是相同的，所以在上层模型中使用BeanMapper.map(obj, Class)方法转换，会消耗些许性能，但代码量减少。
模型对象的作用范围也讨论出来一个规范：
1:上层模型提供转换方法。
2:简单的转换使用BeanMapper转换，复杂的实现BeanConvertor接口，在领域模型中调用BeanConvertor进行转换。这样领域模型的代码会比较清淅，不会显得臃肿。
3:领域边界定义
应用层：Form、Vo
外部服务层(AO层):TO
内部服务层:DTO
数据层:Entity
领域模型对象存放在相应层的模块内， 模块内再细分到java包（package），应用层的领域模型对象内提供转换成外部服务层和内部服务层的方法，内部服务层的领域模型提供转换成数据层模型对象的方法，其中外部服务层需要对外发布服务，所以内部服务层领域模型对象还需要提供转换成外部服务层领域模型的方法，以及外部服务层领域模型成内部服务层领域模型的方法。
具体方法如：
CarrierForm：
CarrierTO toCarrierTO();//Form转To
CarrierVo:
static CarrierVo ofCarrierTO(CarrierTO);//To转Vo
CarrierDTO:
CarrierTO toCarrierTO();//DTO转TO
CarrierDTO ofCarrierTO(CarrierTO);//TO转DTO
Carrier toEntity();//DTO转Entity
CarrierDTO ofEntity(Carrier);//Entity转DTO
可扩展：BeanConvertor通过BeanConvertorFactory这个工厂类创建和获取。

这样设计的优点是每层的模型的作用边界和提供的功能都很清淅，便于理解，当某一层的代码需要调整时，牵扯不会很大，实现代码层次的解耦。

以后有时间再把思路详细的写出来，出一份代码。