SpringBoot微服务：如何用Maven解决跨服务依赖冲突问题？

核心最优方案：拆分服务为API模块与业务核心模块 #

这是最干净、可维护的解决方案，完全规避依赖引入带来的Repository冲突：

• 将Customer服务拆分为两个独立的Maven模块：
  1. customer-api：仅存放对外暴露的内容，包括：
     • 专用DTO类（比如CustomerShopDTO，只包含ShopSystem需要的customerId、cartInfo等字段）
     • OpenFeign客户端接口定义
     • 基础的常量、枚举类
     • 该模块只依赖Spring核心、OpenFeign等基础包，完全不含JPA Repository、数据库驱动、实体类注解（如@Entity）
  2. customer-service：作为独立运行的SpringBoot应用，依赖customer-api，包含所有数据库操作逻辑（JPA Repository、实体类、业务实现）
• ShopSystem仅引入customer-api依赖，既可以获取所需的返回类型，又不会加载到任何Repository相关代码，彻底避免重复创建问题。

示例ShopSystem的pom.xml依赖配置：

<dependency>
    <groupId>com.yourcompany</groupId>
    <artifactId>customer-api</artifactId>
    <version>1.0.0</version>
</dependency>

关于你尝试的「排除依赖包」方式 #

这种方式不推荐，属于治标不治本的方案：

• 手动排除数据库相关包容易遗漏依赖，导致后续出现隐藏的ClassNotFound问题；
• 如果Customer实体类带有JPA注解（如@Entity），即使排除了数据库包，ShopSystem的Spring扫描机制仍会识别这些注解，尝试自动创建Repository，这也是你之前操作无效的原因；
• 依赖结构会变得脆弱，Customer服务版本升级时，可能因为依赖变更导致ShopSystem崩溃。

关于「仅返回customerId」的设计思路 #

从信息隐藏、关注点分离的原则来看，这是合理的，但需要结合业务场景权衡：

• 如果ShopSystem仅需要customerId完成后续逻辑，只返回Integer类型完全符合设计原则；
• 如果需要购物车等额外信息，建议定义专用DTO而非直接返回Customer实体类：既满足业务需求，又避免暴露Customer服务的内部实体结构，同时减少网络传输的冗余字段。

关于parent.pom方案 #

parent.pom的核心作用是统一依赖版本，无法解决Repository重复创建的问题——它依然会将整个Customer服务的依赖引入ShopSystem，因此确实不是解决当前问题的合适方案，无需考虑。

临时应急方案（不推荐长期使用） #

如果暂时无法拆分模块，可以通过限制Spring的扫描范围规避冲突：
在ShopSystem的启动类上，指定仅扫描自身包的Repository，同时排除JPA自动配置（如果ShopSystem本身不需要JPA）：

@SpringBootApplication(
    scanBasePackages = "com.yourcompany.shopsystem",
    exclude = {JpaRepositoriesAutoConfiguration.class}
)
// 若ShopSystem自身需要JPA，单独指定Repository扫描路径
@EnableJpaRepositories(basePackages = "com.yourcompany.shopsystem.repository")
public class ShopSystemApplication {
    public static void main(String[] args) {
        SpringApplication.run(ShopSystemApplication.class, args);
    }
}

该方案仅适合短期过渡，长期来看还是拆分API模块更规范。

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