bo dto java vo_Java-实际开发中，将同样属性的不同-DTO-类优雅映射的最佳实践

业务中使用依赖方 DTO 类所带来的问题

我负责的系统所依赖的部分服务接口需要重构，把对应的接口从 A 服务迁移到了 B 服务，虽然入参出参格式都一样，但包路径完全变了。而原有的 A 服务仍然有接口依赖，所以我必须要兼容两种【类名一样结构几乎一样！】但【包路径完全不同！】的出入参。
但由于我这边的系统代码结构中业务逻辑一直使用了 A 服务提供的 SDK 中的 DTO 定义来做业务参数，这时候就僵硬起来了。。该怎么办呢？

要不自定义一个 BO 吧！

基于目前代码结构来看，自己系统的业务代码中严重依赖了第三方服务 SDK 的定义类，使得自身与第三方服务形成了强耦合的关系(万一人家更新 SDK 中的 BO 定义，自己岂不是得全改？！)。所以第一个想到的就是：不要用人家的 BO 了，我们自定义一个吧！

这样无论人家的 SDK 怎么变，我们只需要在转换器中做好映射处理，就可以完美解决强耦合问题了，prefect！
正当这时候定睛一看(兔美酱的眼神突然犀利了起来)，这样会涉及到大量的业务逻辑改动(所有使用到对应 BO 的地方都要改成新的)！而双十一大促快到了，这时候做大改动出问题的话无疑是【捡了芝麻丢了西瓜】呀。
自定义 Self.BO 改动太大，风险太高，那么只能先保证原业务逻辑还是使用 A.BO 类，让 B.BO 自行去兼容了。。T.T

如何优雅降级而后续可扩展？

虽然双十一前需要使用降级方案，但是考虑扩展性，后续还是需要解耦的。所以决定使用以下方案：

转化器还是要做，但不是转化成自定义 SELF.BO 类，而是转成 A.BO，这样做我们后续就可以把转化器逻辑，与主业务的 BO 包换回 SELF.BO，