微服务的实体类，是提取成公共模块，还是封装在自己的服务里

[monsterj]

全提出来，会不会太多余了，其他服务又不需要
但不提取出来吧，调用其他服务返回的参数，需要一个实体类接收（另一个服务里有这个实体类），再写一个太重复了吧
还是用到哪个，就提取哪个？

[passerbytiny]

既然你都能感受到多余了，那么就需要设计一个媒体数据读取工具了。接收方，直接按需从 json 中读取数据，不需要反序列化成对象。

另外说明一点，既然是微服务，不是远程调用，那就要解耦的，两个服务之间是不应该存在一模一样的实体的。服务之间通信时传递的应当是契约数据，而不是某个类的对象。

[mortonnex]

我们是多个服务存在多个相同的实体类,其实这个不算重复

[mortonnex]

@passerbytiny

"按需从 json 中读取数据" 这种也可以,但是有一点不足,就是后面维护的人,不知道 jsonObject 里面到底有哪些数据,如果后面要使用到别的数据,那么会有沟通成本

其实这也是不提倡用 map 接收数据的原因,因为实体类更清晰

[p2pCoder]

数据库实体 bean 以及业务相关的 VO 之类不用提取成 公共模块
通信过程中 的 参数 可以封装成 dto，暴露相应的服务 api 包出去就行，这中间涉及序列化。原则上，业务相关的 bean 不应该直接暴露，暴露的应该是调用方需要的 dto 信息
当然如果不是纯粹的微服务，只是业务太复杂需要拆分并且也做不到分库，数据库的 bean 也会暴露出去

这是我这个菜鸡的理解

[monsterj]

@passerbytiny 我不太喜欢 JSON 和 Map 接收，因为这样字段不清晰，后续维护和开发麻烦

[passerbytiny]

@mortonnex #3
沟通需要的是接口文档。
媒体数据读取工具不是用 map 接受数据，而是类似于 json path。如果有多层嵌套数据，多层数据类绝对没有 json path 清晰。

初期可以用数据类加自动反序列化来快速接受数据，后期接口多了并且迭代频繁的时候，数据类就不适合了。

[passerbytiny]

@monsterj #5 假如接口提供方迭代频繁的时候，你会觉得数据类修改起来更麻烦。

[mortonnex]

@passerbytiny 你也许没懂我的意思,算了

[monsterj]

@passerbytiny 各有利弊吧