多模块Maven项目中Spring Security类的放置位置咨询

结合你现有项目的依赖关系（controller 依赖 service，service 依赖 infrastructure），下面是两种清晰的类放置方案，适配不同复杂度的安全需求：

方案一：新增独立security模块（推荐） #

在项目根目录下新增security包，统一管理所有安全相关代码，避免打乱现有分层结构：

loyalty-service (Root)
|-- controller
|-- service
|-- infrastructure
|-- security  # 新增安全模块
|   |-- config
|   |   |-- SecurityConfig.java  # 核心配置类，配置HttpSecurity、认证管理器等规则
|   |-- authentication
|   |   |-- CustomUserDetailsService.java  # 实现UserDetailsService，调用service层获取用户信息
|   |   |-- CustomAuthenticationProvider.java  # 自定义认证逻辑（按需实现）
|   |-- filter
|   |   |-- JwtAuthenticationFilter.java  # 如JWT校验、自定义请求拦截过滤器
|   |-- handler
|   |   |-- CustomAccessDeniedHandler.java  # 权限拒绝时的处理逻辑
|   |   |-- CustomAuthenticationEntryPoint.java  # 未认证请求的入口处理
|-- ...

• 该模块仅依赖service层，完全符合你现有依赖链的方向，不会引入反向依赖问题。

方案二：嵌入现有分层（适合简单安全逻辑） #

如果你的安全需求比较简单，也可以将类拆分到现有分层中：

• 安全配置类：放到根目录新增的config包下（或已有config包），例如SecurityConfig.java
• 用户认证实现：CustomUserDetailsService可以放到service层，因为它本质是调用业务服务获取用户数据
• 过滤器、处理器：放到根目录下的filter/handler子包，或者归到一个小型的security子包中

关键原则 #

• 严格遵循现有依赖方向：禁止security模块依赖controller层，保持controller→service→infrastructure的依赖链，security仅可依赖service层
• 安全逻辑与业务逻辑解耦：独立模块的方式更便于后续维护、扩展安全功能

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