Maven高级 - 技术栈

一、分模块设计与开发

[1.1 为什么需要分模块设计与开发？](#1.1 为什么需要分模块设计与开发？)

[1.2 分模块设计](#1.2 分模块设计)

二、继承与聚合

[2.1 继承](#2.1 继承)

[2.2 聚合](#2.2 聚合)

[2.3 继承和聚合的联系和区别](#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.聚合用于快速构建项目，是在父工程(聚合工程)中配置聚合的模块