策略一：按功能模块拆分#

比如：公共组件、商品模块、搜索模块、购物车模块、订单模块等。拆出来就是：

1
mall-common     公共组件（工具类、常量、统一返回结果等）
2
mall-goods      商品模块
3
mall-search     搜索模块
4
mall-cart       购物车模块
5
mall-order      订单模块

一个业务功能一个模块，最适合”业务边界清晰、各模块相对独立”的项目。

策略二：按层拆分#

比如：公共组件、实体类、控制层、业务层、数据访问层。拆出来就是：

1
mall-common      公共组件
2
mall-pojo        实体类
3
mall-controller  控制层
4
mall-service     业务层
5
mall-mapper      数据访问层

一个技术分层一个模块，也就是把三层架构（Controller / Service / Dao）在工程结构上也切开。

策略三：按功能模块 + 层拆分#

先按功能切，再在每个功能里按层切：

1
mall-common            公共组件
2
mall-goods-controller  商品的控制器
3
mall-goods-service     商品的业务层
4
mall-order-controller  订单的控制器
5
mall-order-service     订单的业务层

粒度最细，模块数量也最多。

三条策略没有”谁对谁错”，只有适不适合当前项目：业务模块之间耦合松就按功能拆；想强制分层规范就按层拆；规模再大就两个一起用。

一、知识回顾（读完直接做下面的实践题）#

1. 一个工程不分模块会遇到的两个问题：不便维护（所有功能堆在一个工程里，改一处牵连全工程、多人协作冲突集中）、难以复用（公共代码只能复制一份出去，原项目改了复制的那份不跟着变）
2. 分模块设计的定义：将一个大项目拆分成若干个子模块，方便项目的管理维护、扩展，也方便模块间的相互引用，资源共享
3. 三条拆分策略：① 按功能模块拆分（公共组件、商品模块、搜索模块、购物车模块、订单模块）；② 按层拆分（公共组件、实体类、控制层、业务层、数据访问层）；③ 按功能模块 + 层拆分
4. 策略一的典型模块名：mall-common、mall-goods、mall-search、mall-cart、mall-order
5. 策略二的典型模块名：mall-common、mall-pojo、mall-controller、mall-service、mall-mapper
6. 策略三的典型模块名：mall-common、mall-goods-controller、mall-goods-service、mall-order-controller、mall-order-service
7. 课程实战拆出的两个模块：tlias-pojo（存放实体类）、tlias-utils（存放相关工具类）
8. 拆完之后怎么让原模块继续用这些类：在原模块的 pom.xml 里加这两个模块的依赖；包名不变，所以 import 语句不用改
9. 注意事项：分模块开发需要先针对模块功能进行设计，再进行编码；不会先将工程开发完毕，然后进行拆分
10. 拆完的验证方式（本机实测）：在父工程上跑一次 mvn clean install -DskipTests，模块按 tlias-parent → tlias-pojo → tlias-utils → tlias-web-management 的顺序全部构建成功，两个被复用的模块各自打出 jar 并进本地仓库

二、裸写题#

• 2-1 给一个商城项目设计拆分方案 一个商城项目，代码里有：商品列表查询、搜索、购物车、下单这几块业务功能，另有一些工具类、常量、统一返回结果对象是各功能都要用的。请：

  1. 写出三条拆分策略的名字，并给每条策略举出一组模块名（用 mall- 前缀）；
  2. 结合这个项目说一句：这个项目更适合哪条策略，为什么。 （练习文件 test_91_分模块设计.txt 里已经给了写作区。）
  提示（先自己想，实在想不出再点开）

  一级 · 思路：先问”拆的切分线画在哪里”——画在业务功能上、画在技术分层上，还是两刀都画 二级 · 方法：三条策略分别是按功能模块拆、按层拆、按功能模块 + 层拆；模块名一般用 项目前缀-功能名 / 项目前缀-层名 三级 · 骨架：策略一 → mall-____（公共组件）+ 各业务模块；策略二 → mall-____（实体类/控制层/业务层/数据访问层各一个）；策略三 → mall-商品-____ / mall-订单-____

  参考答案（做完再点开）

  1. 三条策略与模块名：
     • 策略一：按功能模块拆分 —— mall-common（公共组件）、mall-goods（商品）、mall-search（搜索）、mall-cart（购物车）、mall-order（订单）；
     • 策略二：按层拆分 —— mall-common（公共组件）、mall-pojo（实体类）、mall-controller（控制层）、mall-service（业务层）、mall-mapper（数据访问层）；
     • 策略三：按功能模块 + 层拆分 —— mall-common、mall-goods-controller、mall-goods-service、mall-order-controller、mall-order-service。
  2. 这个项目的业务功能边界清晰（商品/搜索/购物车/订单各自独立、都有各自的数据和接口），**按功能模块拆（策略一）**最贴合；如果团队还想在工程结构上强制”Controller / Service / Mapper 不许互相串”，就在每个功能模块里再按层切一刀，也就是策略三。三条策略没有对错，只有粒度适不适合。

• 2-2 给 tlias 写一份拆分设计 课程里的 tlias 工程现在所有代码都堆在一个模块里：com.itheima 下面有 pojo（实体类）、utils（工具类）、controller、service、mapper、anno、aop、config、exception、filter、interceptor。请写出一份拆分设计：

  1. 要新建哪几个模块？模块名分别是什么？
  2. 每个模块里放什么（把上面这些包分到对应模块里）；
  3. 说明这些模块之间”谁依赖谁”（画一个箭头关系即可），并说明箭头不能反过来的原因。 （练习文件 test_91_分模块设计.txt 里已经给了写作区，拆分前的包结构就在题面里。）
  提示（先自己想，实在想不出再点开）

  一级 · 思路：这次的切分线画在”是不是每个业务都要用”上——实体类和工具类是全项目共用的，业务代码才是某个模块专用的 二级 · 方法：两个新模块分别叫 tlias-pojo（放实体类）、tlias-utils（放工具类）；原来的模块保留业务代码，通过在 pom 里加依赖的方式用上它们 三级 · 骨架：tlias-web-management → tlias-pojo、tlias-web-management → tlias-utils；模块之间不能互相指回去

  参考答案（做完再点开）

  1. 新建 两个模块：tlias-pojo、tlias-utils（原来的 tlias-web-management 保留，它变成”使用者”）。
  2. 分工：
     • tlias-pojo：pojo 包（Emp、Dept、Student、Clazz、Result、PageResult、EmpQueryParam…… 本机实验工程里共 13 个类）；
     • tlias-utils：utils 包（AliyunOSSOperator、AliyunOSSProperties、CurrentHolder、JwtUtils）；
     • tlias-web-management：剩下的 controller、service、mapper、anno、aop、config、exception、filter、interceptor（业务代码都留在这里）。
  3. 依赖方向：tlias-web-management → tlias-pojo、tlias-web-management → tlias-utils（两个新模块之间没有依赖）。箭头不能反过来：tlias-pojo 如果依赖 tlias-web-management，而后者又依赖前者，就形成循环依赖，Maven 无法确定构建顺序、直接报错；而且实体类/工具类本来是全项目通用的，让它们依赖某个具体业务模块，将来别的模块想复用时就被绑死了。

• 2-3 说出”为什么不能先把工程写完再拆” 有人提议：“先按老办法把所有代码写在一个工程里，能跑通了，再花半天把包挪到不同模块里去。“请从设计和代价两个角度说明 PPT 为什么明确反对这种做法（PPT 第 8 页的”注意”）。

  提示（先自己想，实在想不出再点开）

  一级 · 思路：模块划分属于”设计”，设计要在编码之前定；而且事后拆分要动的东西远比”挪包”多 二级 · 方法：从”模块边界/依赖方向要先想清楚”和”事后再拆要改依赖、改配置、重新验证”两方面各说一条 三级 · 骨架：① 设计角度：拆分线 = 模块职责与依赖方向，写完再定就要回头大改；② 代价角度：挪完包还要补依赖、通编译、重测全流程

  参考答案（做完再点开）

  PPT 第 8 页的原话是”分模块开发需要先针对模块功能进行设计，再进行编码。不会先将工程开发完毕，然后进行拆分。“理由是： ① 设计角度：拆模块的本质是决定”系统分成哪几块、每块负责什么、谁依赖谁”。这些是架构决策，编码前定下来，写代码时就知道每个类该放哪个模块、该 import 谁；写完之后再定，就会出现”这个类算 pojo 还是算业务”的扯皮，模块边界也容易切歪。 ② 代价角度：事后拆分不是”挪包”那么简单 —— 实体类、工具类搬出去之后要补依赖（每个使用者模块都得加依赖坐标）、要保证编译通过、原来的三层调用关系与配置（扫描路径、mapper 映射文件位置等）都可能要跟着改，最后整个项目要重新测一遍。本机实验工程里，光是把实体类和工具类搬出去，tlias-web-management 就多了两条依赖、少了两个包。 所以正确顺序是：先做模块设计（画模块和依赖关系）→ 再建空模块 → 再往里写代码。

三、综合题#

• 3-1 照着课程把 tlias 拆成多模块 拿你之前跟着课程写的 Tlias 工程（单模块），完成一次真正的分模块改造，并在练习文件里记录过程：

  1. 设计：写出你要拆的模块与它们的职责，以及模块之间的依赖方向（先写设计，再动手）；
  2. 建模块：新建 tlias-pojo、tlias-utils 两个空的 Maven 模块（先在 IDEA 里建出来，观察它们的结构：pom.xml + src/main + src/test）；
  3. 搬代码：把实体类搬进 tlias-pojo、工具类搬进 tlias-utils（记录各自搬了多少个类）；
  4. 补依赖：在被依赖方（两个新模块）和依赖方（原来的业务模块）的 pom.xml 里把依赖关系补上，写出你加的那两条依赖坐标；
  5. 验证：说出你要执行的那条”清理并构建、跳过测试”的命令，并预测四个模块的构建顺序；
  6. 在文件末尾回答：为什么这条命令能一次性构建四个模块？（一句话，想到什么写什么，下一篇会对答案。） （练习文件 test_91_分模块设计.txt 里按这 6 步给了写作区。）
  提示（先自己想，实在想不出再点开）

  一级 · 思路：整题的顺序就是 PPT 强调的顺序 —— 先设计（模块 + 依赖方向）→ 再建模块 → 再搬代码 → 最后补依赖并构建 二级 · 方法：建模块用 IDEA 的 “New Module → Maven”；补依赖就是在 pom 里写一组 <dependency>（自己项目的模块也照样是依赖）；构建用 mvn clean install -DskipTests（install 会把模块装进本地仓库，后面别的模块才能引用到）；顺序要按”被依赖的先构建”来预测 三级 · 骨架：依赖坐标 <groupId>com.itheima</groupId> <artifactId>tlias-____</artifactId> <version>1.0-SNAPSHOT</version>；命令 mvn ____ install -DskipTests

  参考答案（做完再点开）

  1. 设计：tlias-pojo（实体类，全项目共用）→ 被 tlias-web-management 依赖；tlias-utils（工具类，全项目共用）→ 被 tlias-web-management 依赖；tlias-web-management（业务代码）依赖上面两个。依赖方向是单向的，两个公共模块不依赖任何业务模块。
  2. 建模块：File → New → Module，选 Maven，模块名 tlias-pojo；同样再建 tlias-utils。建好后结构是”一个 pom.xml + src/main、src/test”，此时还没有任何业务代码。
  3. 搬代码：实体类 → tlias-pojo/src/main/java/com/itheima/pojo/（本机实验工程里 13 个）；工具类 → tlias-utils/src/main/java/com/itheima/utils/（4 个：AliyunOSSOperator、AliyunOSSProperties、CurrentHolder、JwtUtils）。包名原样保留，所以 tlias-web-management 里的 import 不用改。
  4. 补依赖（课程代码 tlias-web-management/pom.xml 原文）：

     1
     <!--Tlias-Pojo实体类-->
     2
     <dependency>
     3
         <groupId>com.itheima</groupId>
     4
         <artifactId>tlias-pojo</artifactId>
     5
         <version>1.0-SNAPSHOT</version>
     6
     </dependency>
     7
     
     8
     <dependency>
     9
         <groupId>com.itheima</groupId>
     10
         <artifactId>tlias-utils</artifactId>
     11
         <version>1.0-SNAPSHOT</version>
     12
     </dependency>

     另外，实体类要写 @Data、工具类要用到 OSS/JWT 等库，所以这两个模块自己的 pom.xml 里也要把 lombok、OSS、JJWT 这些依赖写上 —— 每个模块都重复写一遍太麻烦，这正是下一篇要解决的问题。
  5. 验证：命令是 mvn clean install -DskipTests（在父工程/聚合工程上执行）。预测顺序：tlias-parent → tlias-pojo → tlias-utils → tlias-web-management。
  6. 因为它是一个聚合工程：父工程的 <modules> 把几个模块都列了进来，mvn 在它上面执行时会依次构建这些模块，构建顺序由 Maven 按模块间的依赖关系自动决定，不用手动一个个构建。本机实测（Maven 3.9.14 / JDK 17）的输出就是 Building tlias-parent [1/4] → tlias-pojo [2/4] → tlias-utils [3/4] → tlias-web-management [4/4]，最后 BUILD SUCCESS。