Java分层架构中跨模块入参数据映射的最佳实践咨询

这种分层独立定义数据契约的思路本质符合低耦合设计原则，但绝非所有场景都必须严格落地，核心要先理清不同层数据模型的定位差异：

• Web层（即你目录里的api包）的TestProjectRequest属于HTTP协议适配层的契约：它的字段定义、校验规则完全对齐对外暴露的HTTP接口参数格式，职责就是接收和校验前端传过来的原始请求数据。
• Service层的入参属于业务域契约：它只需要关心业务逻辑执行需要哪些数据，不需要关心数据来源是HTTP请求、RPC调用、MQ消息消费还是定时任务触发。

如果硬把Web层的Request类直接作为Service层的入参，短期看省了映射代码，但长期会埋下两个隐患：一是Service层会逐步被Web层的逻辑侵入（比如很多人图省事直接把HttpServletRequest传到Service里掏参数），导致业务逻辑和Web容器强绑定，后续要做单元测试、新增非HTTP的调用入口时改造成本极高；二是Web层的参数调整会直接波及业务逻辑，很容易出现改个接口字段把核心业务搞崩的问题。
但反过来，如果所有场景不管三七二十一都给Service层单独建一套和Web层字段完全一致的入参类，纯为了满足“分层独立”的形式要求，那就是典型的过度设计，平白增加大量无意义的重复劳动。

不要走“全复用”或者“全独立映射”两个极端，按场景匹配方案即可：

• 对于迭代快、业务逻辑极薄、没有跨入口复用需求的简单内部CRUD模块：
  直接复用Web层的Request类作为Service入参完全可行，不需要额外建映射类。只要守住一条底线：Service层绝对不能引入任何Web层相关的依赖，比如不能直接操作HttpServletRequest、不能引用Spring Web的绑定注解。如果需要补充请求上下文（比如操作人ID、请求IP），直接在Controller层把数据取出来，塞到Request对象里（可以给这些内部补充的字段加@JsonIgnore注解，避免被前端传参绑定覆盖）再传给Service即可，比新建一个类性价比高得多。
• 对于需要做复杂数据增强、或者业务逻辑会被多个入口（HTTP/RPC/MQ/定时任务）复用的场景：
  采用你提到的独立业务入参类（比如EnrichedTestProjectRequest）的方案，但是不要手写重复的get/set映射逻辑：
  • 用Bean拷贝工具减少重复代码：简单的同名属性复制直接用Spring BeanUtils、MapStruct这类工具，一行代码就能完成转换，几乎没有额外开发成本
  • 通用上下文的增强逻辑不要散落在每个Controller方法里：比如当前登录用户信息、链路追踪ID这类所有接口都可能用到的公共字段，可以通过Spring的参数解析器、Controller切面统一完成注入，不用每个接口都单独写enrichRequest方法
• 对于公共服务模块、中大型项目的核心业务域模块：
  严格执行Service层独立定义入参/出参的规范，这部分映射成本是完全值得的。独立的业务入参相当于给核心业务逻辑加了一层防腐层，后续Web层做接口版本迭代、协议调整，都不会影响核心业务逻辑的稳定性，长期维护成本反而会更低。

• 不要搞形式主义的分层：如果两个层的数据模型字段100%重合、且没有独立演进的需求，就没必要强行拆分类做映射，规范的目的是降低维护成本，不是为了满足教条的设计要求
• 绝对不要把Web层的上下文对象（HttpServletRequest/HttpServletResponse等）传到Service层，一旦这么做，Service层就彻底和Web容器绑定，后续做测试、扩展调用入口都会非常困难
• Service层的业务入参类必须放在对应的service包下，作为Service对外暴露契约的一部分，不能反过来让Service依赖Web层的Request类，否则分层就彻底失去了意义

内容的提问来源于stack exchange，提问作者Johnyb