大佬们，帮忙看看这个设计合理吗

[WillingXyz]

日常开发中，经常从数据库或 ES 中查询数据，比如 NewsDO，DO 里的字段和数据库或 es 是一一对应的。

但是，我们在返回给前端，或者作为 service 方法提供给其他方法使用时，经常需要组装数据。

例如 NewsDO 里只有 createUserId，topicId ...等等

但返回给前端时，或者作为方法返回值时，需要再次查询数据库或 es 把 id 转换成对象。

比如，createUserId 转换成 createUserVo，topicId 转换为 topicVo...等等。

但是这些转换方法比较乱，当后续别人做类似转换的时候，经常重写类似的代码，不好复用。

所以，我想把转换相关代码放到一个类中，比如 NewsConvert，其中部分字段结合 Mapstruct 转换。 比如，方法 NewsVo toNewsVo(NewsDO newsDo)，填充的数据调用其他 service 获取

大佬们，觉得合理吗？（因为和架构、组长讨论，他们觉得不太合理）

[AlkTTT]

我觉得应该看实际情况吧，如果你写了通用装换方法，有些字段的值不能提供出去的话，怎么排除呢？

[WillingXyz]

@AlkTTT 会有多个 vo

[AlkTTT]

比如查询订单信息，业务场景是只可以看到订单金额，不能看回扣，扣税等信息，但它们存储是放在一起的；
你这种通用转换就不能做

[StarainX]

合理

根据不同的权限和业务场景转换成不同的 VO

[pelloz]

你的说明不太清楚，我根据自己的经验提供一些建议。
一般后端准备好的数据需要一次转换为 VO 再提供给前端，这个转换可以写公共方法，但是建议只提供转换的接口，不要封装死转换的具体实现。
原因是，相对后端业务，前端需求变化较快，需要转化的字段变化规律不太好总结，变化的业务很可能将你封装的类变成屎山或者以后不明白你良苦用心的调用方直接绕过你这个封装类自行实现。
你可以做一点微小的优化，通过接口将转换的实现集中在一个固定的包下面，后续排 BUG 也方便一些。

[AlkTTT]

@WillingXyz vo 多了，更不能用了。
一个项目组内的成员对项目很少能做到全知，他们在维护过程中，不可能再仔细了解一个 vo 是干嘛的，有存在拿来主义的可能。

[WillingXyz]

@AlkTTT 如果只有一个 Vo，它就要包括所有字段，然后 Service A 和 B 方法都返回这个 Vo，但调用方不知道哪个字段有值。
比如上面 NewsVo 的例子，它里面的 topicVo 有没有值取决于 A 和 B 实现有没有给它赋值。这样对调用方来说是不是太不友好，每次调用还要去看下实现？

[anthow]

提供一个对应的领域服务来做这个事