你这么理解就明白了，这个类 User 仅仅是你的 A 服务为了映射请求结果而本地自定义的一个映射数据结构，这个映射数据结构和 B 服务可以说是没关系的。所以你当然应该放在 A 这里

你很纠结无非是你觉得这个东西似乎是可以复用的，所以纠结放 A 还是放 B，以及是不是要抽出来做个公共依赖。

我很久以前也很纠结这个东西，但是踩了太多坑以后我的想法就变了，高内聚低耦合本质的意义，就是把和一个服务（组件，应用，包，等等等等）相关的代码全部包在一起，不要和外界有牵扯，你有牵扯就会引发修改时的依赖地狱。


Java 这个语言在诞生的时候不管是发明者，业界，都很非常强调设计模式，设计模式中的一个需求来源就是代码复用，但是这是历史；历史上 Java 被开发出来，是希望写基础设施，来取代 C++的位置，基础设施离业务比较远，需求相对稳定，因此比较容易抽象和复用。但是 Java 发展到今天，形势已经变了，就像 Go 为了满足社区里大量写业务的人的需求，不得不加泛型一样，Java 现在和业务靠的非常近，和基础设施相对距离远，而业务又是复杂多变，这就导致抽象和复用变的困难而价值降低，能适应修改变成了硬需求，这种情况下。IOS 那种把一个程序的依赖全部聚合在包的内部的做法，才是最适宜的。

诚然，不抽象和复用，代价就是代码会膨胀，以及相似代码到处 copy 的问题。但是什么事情没有代价，无非是你选哪头而已。以 Java 目前这种更靠近业务的使用环境，项目初期我是完全不赞成去考虑抽象和复用的，至少要等到业务成型并稳定后，再去抽象和考虑复用进行重构