作者回复: 尽量不要搞很多XXO，一般DTO(数据传输对象)+Entity(数据存储实体)就够了，XXO不在于多，而在于保持风格一致性。

作者回复: 谢谢你的反馈！ 1. 经过和学员交流，Response<T>方式也可以实现基于feign的强类型客户端，后面会再开发一个项目，采用这种方式，供大家参考。 2. 直接复用DMO也可以做到，而且可以减少转换，但是有些复杂场景，将DTO/DMO分开定义，也有好处，课程中也有提到，这样两边比较清晰，可以根据需要灵活裁剪或添加字段，可以减少依赖和判断逻辑。 3. 映射工具的确也是有利有弊的，使用时要了解其弊端，并针对性防范(比如单测)。

作者回复: 网上有对5种mapping框架的性能比对，可以参考一下：https://www.baeldung.com/java-performance-mapping-frameworks

作者回复: BeanUtils只能做简单的一对一的字段映射和克隆，ModelMapper之类是专业的Java Mapping框架，具有很灵活的配置和智能映射能力，常见的专业Mapping框架可以参考：https://www.baeldung.com/java-performance-mapping-frameworks

作者回复: DTO数据传输对象，VO值对象，它们的用途大致类似，主要用于在进程间传递数据，不同程序员习惯称谓不同而已，没有必要太纠结，根据你的习惯选择并且保持一致性即可。

作者回复: 不错，已经做到自动化和精细化阶段，值得借鉴。

作者回复: freemarker和thymeleaf这些模版引擎都差不多，邮件模版的话，可能freemarker更合适一些，个人看法。

作者回复: 这些代码组织方式都是逻辑性的，形成规范保持一致就好，没必要纠结拘泥于形式。

作者回复: 对，项目用了mapstruct(https://github.com/mapstruct/mapstruct)，做DTO和DMO之间的映射。

作者回复: 1. 对，每个服务操作严格有一对Request/Response消息对应，这个是grpc/protobuf的规范做法，可以参考https://github.com/Staffjoy/v2/tree/master/protobuf。之前大厂ebay的trading api(https://developer.ebay.com/devzone/xml/docs/reference/ebay/index.html)，也是采用这种接口风格。这是一种类rpc编程风格，我的staffjoy项目中的微服务虽然是RESTful的，但是沿用了这种类似谷歌grpc的编程风格，目的是实现类似rpc的强类型接口，request/response是会多一点，但是只要规范，不是大问题。 2. 具体要看你怎么实现的，能否贴一个带范型response示例和客户端feign接口示例？