目录一、分模块设计与开发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默认jar2.在子工程的pom.xml文件中配置继承关系。3.在父工程中配置各个工程共有的依赖子工程会自动继承父工程的依赖。继承的版本锁定现在有这样一个场景子工程中只有三个工程用到了jwt这个依赖如果将这个依赖直接放到父工程中pojo、utils同样会继承这个依赖对项目的性能是有损害的。那么只能在子工程中一个一个的进行导入那么该如何统一管理各个依赖的版本呢使用dependencyManagement来统一管理依赖版本。只需要在父工程中管理一个版本在子工程中就不用声明依赖的版本了实现了版本在父工程进行统一的管理。2.2 聚合聚合解决的是项目打包的问题。当你把项目拆分成 5 个模块后如果需要打包部署难道要手动进 5 个文件夹分别执行mvn clean package吗聚合就是为了解决这个问题。在父工程的pom.xml中通过modules标签将所有子模块罗列出来。效果你只需要在父工程执行一次mvn installMaven 就会自动算出各个子模块的依赖先后顺序并帮你把所有子模块全部编译打包好。2.3 继承和聚合的联系和区别联系继承与聚合都属于设计型模块打包方式都为pom常将两种关系制作到同一个pom文件中。区别:1.继承用于简化依赖配置、统一管理依赖版本是在子工程中配置继承关系2.聚合用于快速构建项目是在父工程(聚合工程)中配置聚合的模块
