浅谈微服务-POJO

POJO的定义

按照阿里巴巴规范，是DTO，VO，BO等的统称。任何模型不许定义为***POJO。

实际模型

Entity 数据库
DTO 系统间传输对象
BO 业务级大对象, 一般 用于一个复杂对象场景下使用
VO 页面显示对象
Result -> 一种特殊的DTO，用于定义服务间数据传输的包装类

Result

属性一般有：String code; String message; T data; Boolean success;
其中code 和message 不允许显式的声明定义，需要使用枚举类。
Result 提供统一的sucess() 方法。需要判断Boolean 或者 code值，这个视具体接口而定，一般建议使用Boolean 判断, 使用code细分具体场景。
提供统一的创建对象的方法。

VO 包装类也需用Result包装。

传输入参和出参严禁使用Map对象处理，数据库亦如此，因为可读性很弱，且不方便维护，传递过程中，都需要保证key的正确性。

微服务中，DTO 传输对象不能直接使用数据库对象

微服务中，不管是使用SpringCloud 或者使用 RPC, 在传输时，基本输出对象都和数据库一致，但业务发展中，总会需要新字段支撑，那样不利于维护。
比如：现在一个接口返回学生id，后续需要返回用户父母信息，后续改动就较大了。

微服务间传输尽可能的返回其他使用者可能需要的信息

这个主要防止重复造轮子，或者重复修改老接口。
如果新接口需要使用某字段，直接拿来用，迭代就很快。如果某个字段需要调整老接口，或者新增接口，会导致项目越来越臃肿，且后期可能需要修改多个接口。
微服务间，数据尽可能的传递，最终有端服务去决定哪些数据作为VO输出。

对象属性

有个接口如果即有用户信息，又有家长信息，还有其他信息，请将多个维度的信息封装成对象属性。
不然后期维护会导致对象越来越多，且不能清晰标识这个接口具体做哪些事情。虽然接口注释中可以描述，但如果区分清晰，使用者会更加明确结果内容。

明确输出字段

这个弱场景中涉及到，比如两个接口公用一个输出类，但A接口会输出全部信息，B接口为效率考虑，输出部分字段，需要接口中明确。

POJO转化

mapstruct
DozerMap
BeanUtils.copy**
get/set