Maven高级
目录
一、分模块设计与开发
1.1 为什么需要分模块设计与开发？
1.2 分模块设计
二、继承与聚合
2.1 继承
2.2 聚合
2.3 继承和聚合的联系和区别
一、分模块设计与开发
1.1 为什么需要分模块设计与开发？
在项目初期，我们通常会把所有的代码（Controller、Service、Mapper、POJO 等）塞进同一个大工程里。但随着业务发展，这种“单体架构”会暴露出严重的缺陷：
代码臃肿，编译极慢：修改哪怕一行代码，也需要重新编译和打包整个几百 MB 的项目。
复用性极差：假设你们公司有两个项目（项目 A 面向 C 端用户，项目 B 是后台管理系统），它们都需要用到同一套数据库的实体类（POJO）和工具类（Utils）。如果不分模块，你就只能靠“复制粘贴”代码，一旦数据库字段修改，两边都要改，极易出错。
职责不清晰，容易越权调用：新人容易在代码里随意互相调用，导致架构混乱。
1.2 分模块设计
分模块设计的策略：
- 策略一:按照功能模块拆分，比如:公共组件、商品模块、搜索模块、购物车模块、订单模块等。
- 策略二:按层拆分，比如:公共组件、实体类、控制层、业务层、数据访问层。
- 策略三:按照功能模块+ 层拆分
一个典型的电商项目分模块后，它的目录结构通常是这样的树形结构：
shop-parent (父工程/聚合工程) ├── pom.xml (父 POM，统一管理依赖版本和公共配置) │ ├── shop-pojo (子模块：存放所有实体类) │ └── pom.xml │ ├── shop-common (子模块：存放通用工具类、全局异常处理等) │ └── pom.xml │ ├── shop-mapper (子模块：存放数据库访问层接口与 XML) │ └── pom.xml (依赖 shop-pojo) │ └── shop-service (子模块：存放业务逻辑) └── pom.xml (依赖 shop-mapper, shop-common)二、继承与聚合
2.1 继承
在上面的分模块设计的项目中，每一个子模块都需要引入Lombok依赖，并且要确保这些相同的依赖的版本号是相同的，这个操作是很繁琐的。
如果不统一管理，模块 A 用了 8.0 版本的 MySQL 驱动，模块 B 用了 5.7 版本，项目整合时就会发生可怕的“依赖冲突”。
继承解决了这个问题：
继承允许子模块继承父工程的配置。我们在父工程中统一定义依赖的版本号，子模块只需声明“我要用这个依赖”，而不需要写版本号。
实现：<parent>……</parent>
继承关系的实现：
1.创建maven模块tilas-parent，该工程为父工程，设置打包方式为pom（默认jar）
2.在子工程的pom.xml文件中，配置继承关系。
3.在父工程中配置各个工程共有的依赖（子工程会自动继承父工程的依赖）。
继承的版本锁定：
现在有这样一个场景，子工程中只有三个工程用到了jwt这个依赖，如果将这个依赖直接放到父工程中，pojo、utils同样会继承这个依赖，对项目的性能是有损害的。那么只能在子工程中一个一个的进行导入，那么该如何统一管理各个依赖的版本呢？
使用<dependencyManagement>来统一管理依赖版本。只需要在父工程中管理一个版本，在子工程中就不用声明依赖的版本了，实现了版本在父工程进行统一的管理。
2.2 聚合
聚合解决的是项目打包的问题。当你把项目拆分成 5 个模块后，如果需要打包部署，难道要手动进 5 个文件夹分别执行mvn clean package吗？
聚合就是为了解决这个问题。在父工程的
pom.xml中，通过<modules>标签将所有子模块罗列出来。效果：你只需要在父工程执行一次
mvn install，Maven 就会自动算出各个子模块的依赖先后顺序，并帮你把所有子模块全部编译打包好。
2.3 继承和聚合的联系和区别
联系：继承与聚合都属于设计型模块，打包方式都为pom，常将两种关系制作到同一个pom文件中。
区别:
1.继承用于简化依赖配置、统一管理依赖版本，是在子工程中配置继承关系2.聚合用于快速构建项目，是在父工程(聚合工程)中配置聚合的模块