如何优化Spring Boot核心项目与业务包装项目的架构？

一、组件化打包方式优化 #

放弃FAT-JAR打包方式，改用普通JAR打包核心项目，从根源解决依赖冲突排查难的问题：

• 核心项目的构建配置中（Maven的pom.xml或Gradle的build.gradle），将打包类型设为jar，移除Spring Boot打包插件的可执行JAR生成逻辑（比如Maven中去掉spring-boot-maven-plugin的repackage目标）
• 核心项目仅打包自身源码，依赖通过Maven/Gradle的依赖传递机制由业务项目引入，业务项目依然使用Spring Boot的FAT-JAR打包，负责整合所有依赖并作为启动入口

二、依赖管理与排查策略 #

针对依赖引用混乱的问题，从版本管控和排查工具两方面优化：

• 核心项目明确声明所有依赖的scope：通用基础依赖设为compile，需业务项目提供的依赖（如特定数据库驱动）设为provided，避免不必要的依赖传递
• 核心项目维护依赖版本BOM，业务项目通过导入BOM统一管控所有依赖版本，消除版本不一致导致的冲突
• 日常排查依赖冲突时，使用mvn dependency:tree（Maven）或./gradlew dependencies（Gradle）生成依赖树，快速定位冲突依赖并通过exclusions排除冗余引用

三、Spring Security配置生效方案 #

解决核心Security配置在业务项目不生效的问题，采用可扩展的配置模式：

• 核心项目不直接启用全局Security配置，而是封装基础配置基类（如CoreWebSecurityConfig），实现默认安全规则（比如文件上传接口的权限校验），业务项目通过继承该基类并添加@EnableWebSecurity注解启用配置，同时可重写方法自定义业务专属规则
• 若核心需要强制保留某些安全逻辑，可将核心配置类标记为@Configuration，并通过@ConditionalOnMissingBean注解允许业务项目自定义同名Bean覆盖默认配置
• 确保核心配置被Spring扫描：核心项目通过@ComponentScan指定自身组件路径，或业务项目在启动类中用@Import手动导入核心Security配置类

四、架构分层与源码隔离建议 #

进一步强化核心与业务的隔离，提升维护效率：

• 核心项目拆分为两层：
  • 基础逻辑层：独立于Spring的纯Java类，实现文件上传、代码管理的核心业务逻辑，无框架依赖，便于复用和测试
  • Spring集成层：将基础逻辑封装为Spring的Controller、Service、配置类，提供REST端点和Spring集成能力
• 核心项目定义SPI接口（如FileUploadProcessor），提供默认实现，业务项目可通过实现该接口并标记@Primary替换默认逻辑，无需修改核心源码
• 核心项目严格剔除业务相关配置（如数据库连接、业务参数），仅保留通用功能配置，业务项目负责自身业务配置与扩展

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