比如现在有一个简单的 Employee 的 POJO 类，因为要数据库操作所以要用 Spring 的 JPA 就得在类里加上 Entity 的注释，但是这样就有 Spring 的 context 了。
现在因为很多其他的微服务都需要这个类，想把这个类拿到不带 Spring 的共用的 package 下面就做不到，不得不维护两个类，一个是带 Spring 的一个是不带给其他微服务用比如 unwrap json 之类的，有没有什么比较好的办法只用维护一个？
分包做依赖具体是怎么操作？就还是一个 pojo 用来跨系统，然后分包再建一个带注解的做 JPA 操作？
不过,如果什么都不做的话, 那就只能程序到 mysql 的那些系统字典表里去查对应的表名,列名和类型, 然后自己去组装一个类, 但是这样对命名规范很严格, 很容易出现映射错误的问题
不过我们公司也是这么干的
对于你的情况，说白了你的程序根本就不是微服务架构，微服务压根就不会用到数据库相关代码共享。如果要共享，也只有协议数据格式（ Http 的内容数据格式，Message Payload 规格）可以共享。
没有准备好 MS，就不要强行往上面靠，微服务架构跟你的所有的框架没太多关系，你的程序并不是用了 Spring Cloud 或者其它什么微服务框架就是微服务架构，很多人只是使用某种框架“碰瓷”微服务而已。
所以，如果 POJO 类是共用的，它就不应该被 A 视作私有的，既然不是私有的，就不能夹杂私货。
如果 A 觉得维持这个干净的 api 太累了，应该搞一个独立的 C 来维护。
整体的意思还是要回到经常谈论的点上：内聚和耦合，你怎么处理这个关系。
解决方法：在能用的 JAR 中通过 Java Interface 定义领域模型，JPA 中只是实现这个 Interface，其它的微服务只看到 Java Interface，在不同微服务之间进行模型传递时，通过一个动态代理的对象工厂创建这个接口的实例。
这样就可以不需要在所有的微服务中看到 JPA 的 Entity 了，它们看到的只有领域模型的 Interface，只不过需要定义好对象传输的协议，和反序列化的逻辑。