多模块Maven分层项目中Service层相关DTO逻辑归属如何设计

按DTO使用范围分类处理 #

• 仅Web层使用的DTO：比如你提到的PaginationFilter这类只在控制器层做参数接收、响应包装，不会传递到Service层的DTO，直接放在Web模块内部即可，不需要下沉到其他层。
• 跨Web/Service层使用的业务DTO：比如CreateRoomDTO这类需要作为Service层方法入参、同时被Web层调用时传递的DTO，根据项目规模可选两种归属方案：

方案1：新增公共模块存放（中大型项目推荐） #

单独新增一个无业务逻辑的公共模块（命名可参考common/api-model/dto-base），所有跨层复用的DTO、全局通用枚举、常量都放在这个模块中。
调整后的依赖规则如下：

# 公共模块不依赖任何业务模块，仅作为基础依赖被引用
common <- Service <- Web
Model <- Persistence <- Service <- Web

该方案优势：

• 完全解耦DTO与业务模块，后续新增RPC、定时任务等其他模块时可直接复用公共DTO，不需要重复定义
• 避免Service层混入传输层定义，保持各模块职责单一

方案2：存放在Service模块的API包下（小型项目适用） #

如果项目规模很小，不想新增额外模块，可以把这类跨层DTO统一放到Service模块的独立包下（比如com.xxx.service.api.dto），Web层因为天然依赖Service模块，可以直接引用这些DTO。
注意该方案仅适合单端调用的小型项目，后续如果有不依赖Service的模块需要复用DTO会无法支持。

避坑提醒 #

• 不要把DTO放到Model模块中：Model模块存放的是核心领域实体，属于业务核心层，混入传输层DTO会污染领域模型的职责边界
• DTO仅作为数据载体，不要写入任何业务逻辑，保持纯POJO结构即可

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