spring boot多模块maven工程拆分核心是聚合与继承机制，按业务域划分模块（如user-service、order-service），父工程为pom类型空壳，统一管理依赖版本；子模块单向依赖，仅web模块含启动类，打包时生成含所有依赖的fat jar。
Spring Boot 中实现多模块 Maven 工程拆分，核心是用好 Maven 的聚合（pom 类型父工程）和继承机制，配合合理的业务边界划分。关键不在“能不能拆”，而在“怎么拆得清楚、管得住、跑得通”。
明确父工程定位：只管结构，不管代码
父模块本质是一个“空壳工程”，不放业务代码，只承担三件事：
- 把
<packaging></packaging>改为pom - 通过
<modules></modules>声明所有子模块路径（如<module>user-service</module>） - 统一管理版本号、依赖版本（用
<dependencymanagement></dependencymanagement>）、插件配置（如spring-boot-maven-plugin）
注意：父工程的 <parent></parent> 仍可继承 spring-boot-starter-parent，以便复用 Spring Boot 默认配置；但子模块不再重复声明该 parent，而是继承父工程本身。
按业务能力划分模块，不是按技术层切
别一上来就分 controller/service/dao 模块——那是单体项目内部包结构，不是模块拆分逻辑。真正可持续的拆分依据是：
-
一个模块对应一个高内聚的业务域，比如
order-service、user-service、payment-core - 每个模块内部再按 MVC 或六边形架构组织包结构（
controller、application、domain、infrastructure等） - 通用能力抽成独立模块，如
common-util、shared-dto、gateway-auth，供其他模块依赖
这样拆出来的模块才能独立开发、测试，甚至未来演进为独立服务。
理清模块间依赖关系：只允许单向、显式引用
Maven 不会自动解决跨模块调用，必须手动声明依赖。规则很明确：
- Web 层模块（如
web-api）可以依赖 Service 模块 - Service 模块可以依赖 Domain 或 Common 模块
- 禁止反向依赖：Domain 模块绝不能依赖 Web 或 Service 模块
- 子模块的
<groupid></groupid>和<version></version>通常省略，直接继承父工程，避免版本错乱
IDEA 中右键子模块 → “Add as Maven Project” 可自动识别并建立依赖索引；编译时 Maven 会从本地仓库解析模块，无需 install 到远程仓库也能正常构建。
启动与打包：只有一个可执行模块
多模块 ≠ 多个启动类。通常只有最上层的 Web 模块（如 app-web）包含 @SpringBootApplication 和 main 方法：
- 该模块的 pom.xml 需显式配置
spring-boot-maven-plugin，并指定<mainclass></mainclass> - 运行时只打这个模块的 jar 包，其他模块作为依赖被自动打包进 fat jar 的
BOOT-INF/lib/目录下 - 若需分离部署（如微服务），则每个业务模块应单独配置为可执行 jar，并各自定义启动类和端口
执行 mvn clean package 在父目录下，Maven 会按依赖顺序依次构建所有模块，最终生成可运行的启动包。
