生不逢时的vo、po、dto

案例

某项目采用微服务架构，将系统切分成大量微服务，服务间通过feign调用。
为了方便调用方，无需多个调用方各自去生成客户端代码，API提供方在实现接口的时候同时提出FeignClient定义。
见下图，其中*-service是api实现，*-api则是FeignClient定义。

至于*-model里是什么呢？
是各种vo、dto、entity、mybatis的mapper定义等。
这样它就实现了dto等在客户端、服务端的复用。
毕竟vo、dto、entity这些几乎都是一模一样的字段嘛，“没必要”重复，也“没必要”在客户端和服务端各维护一套。

我的观点

离了个大谱，滑了个大稽。
在十几年前，java web开发就已经提出了vo、po、dto等各种概念了。
但那时微服务还不火热，更多的是单体项目。
单体项目的话，同一个项目下（即使划分了多个Module）代码共享太方便了，导致很多人都觉得vo、po、dto里面属性都差不多甚至一模一样没必要搞那么多。
他们普通觉得区分这么多，虽然确实是解耦了，但是带来的收益还不如成本大。毕竟经常有人乱用。
我也曾经有过这样的观点。

但是，在微服务越来越火的现在，模块划分越来越细（先不讨论划分合不合理），代码共享在互相依赖的情况下，就带来了很大的麻烦了。
这时严格区分vo、po、dto绝对是成本小，收益大。

感觉vo、po、dto等是非常好的解耦设计，但是可惜生不逢时。
大家以前用了，但帮助不大，反而对它产生了一些负面情绪。
现在微服务大火，是它作为防腐层发力的时候了

如果你觉得本文对你有帮助或不错，可略表心意，请我喝一杯冰可乐。 ☕