在进行分布式系统开发时，我们通常会创建多个模块的工程项目。即每一个功能就是一个Spring Boot工程，作为一个个模块，然后这些模块都会有一个父模块，父模块通常没有代码只有一个pom.xml。
今天就来分享一下Spring Boot如何创建一个多模块项目，以创建一个两个子模块的工程为例。
1，创建父模块
在IDEA中，创建一个Spring Boot项目，但是不勾选任何依赖：
创建好之后，将父模块中除了pom.xml文件之外的全部文件删除：
因为父模块只是做一个模块和依赖管理的作用，因此不需要代码。
然后修改这个父模块的pom.xml文件，首先把节点、节点和全部删除：
然后修改版本号为自己定义的（方便后续子模块指定父模块）：
然后修改父模块打包方式为pom，在其中加入如下语句即可：
<packaging>pom</packaging>
好的，到这里父模块修改就完成了！
2，创建子模块
在左边项目树中父模块位置右键新建Spring Boot工程：
然后把子模块不需要的文件也删掉（只留pom.xml和src文件夹）：
修改该子模块的pom.xml文件，首先把子模块中的工件坐标改成和上述父模块一致：
然后删除子模块的groupId节点，因为通常子模块继承父模块，子模块的组id是和父模块的一致的：
ok，到此子模块创建并配置完成！此时这个子模块（工件名module-one）就继承了刚刚的父模块。
然后以这个步骤再创建一个子模块module-two：
最后整个工程就创建完成了！总共两个子模块。
3，在父模块中指定子模块
回到父模块的pom.xml文件，添加modules节点，在其中加入module节点以指定子模块：
需要注意的是，module节点中的内容是子模块工程的文件夹名！所以通常规范起见子模块工程的文件夹名通常和它的组件名一致。
然后在父模块文件夹中执行mvn clean package试试：
可以看见构建打包成功，以及每个模块的构建时间。
到此，多模块项目就创建完成了！
4，子模块之间的互相引用
在多模块项目中，子模块的互相引用也很方便。
比如说上述module-one要调用module-two中的类，就直接把module-two的工件坐标加入到module-one的pom.xml的依赖部分即可！
更新一下Maven工程，就可以在module-one中调用module-two的类了！
不过这个时候运行工程是没有任何问题的，但是打包会出错：虽然module-one依赖了module-two，但是仍然会在打包module-one的时候，提示找不到module-two中的类。
这是由于Spring Boot打包的模式问题，我们打开被依赖模块module-two的pom.xml文件找到最下面节点中，在spring-boot-maven-plugin插件部分中加入下面配置：
<classifier>exec</classifier>
最终如下：
这个时候对父模块打包，就成功了！
5，依赖管理
多模块项目中模块变多了，依赖管理不当也会导致很多莫名其妙的问题。但是如果对每个模块分别管理依赖及其版本，会相当麻烦。
(1) 共用的依赖
假设上述module-one和module-two都需要依赖fastjson2，我们平常并不会依次在module-one和module-two中分别单独加入其依赖，而是直接在父模块pom.xml中指定，和平时一样，在父模块的pom.xml的dependencis节点中加入即可：
这样，子模块中即使是不加入fastjson2依赖，也可以使用这个库了！因为子模块除了可以使用自己的依赖之外，还会向上查找父模块的依赖，也就是说，父模块的依赖是向下继承的，因此对于所有模块都要使用的依赖，我们可以写在父模块中。
所以，两个模块都依赖于
Spring Web话，也可以将两个模块的Spring Web依赖移至父模块。
所以说父模块和子模块中，依赖也有着继承的关系！事实上，父模块的properties也是向下继承的。
(2) 依赖版本管理
假如现在module-one依赖于okhttps的4.0.0版本，而module-two依赖于commons-io的2.11.0版本，显然这时我们不适合再在父模块中加入了，还是各自加入对应依赖。
目前因为只有两个模块，这么做看起来很合理。但是假设现在又多了module-three，module-four等等，它们也是分别依赖于okhttps与commons-io，那么我们又要分别在这两个模块中分别单独加入依赖。
| 摸块 | 依赖 |
module-one和module-three |
okhttps |
module-two和module-four |
commons-io |
可能一开始没有问题，但是后面模块依赖版本需要更新，但是一个个地更新难免会有疏漏，导致部分模块虽然依赖一样但是版本不一致，最后整个系统也出现了莫名其妙地错误，还难以排查。
就假设后面你把module-one的okhttps更新到了4.0.1版本，但是module-three的okhttps仍然是4.0.0版本，这样整个系统就可能出现问题甚至无法启动。
尤其是模块变成十几个甚至上百个了，一个个地手动修改是几乎不可能的，要如何让每个模块使用的依赖版本统一呢？
这时，我们就要借助dependencyManagement标签了！
dependencyManagement用于管理依赖的版本，我们在父模块的pom.xml加入这个标签：
<dependencyManagement><dependencies><dependency><groupId>cn.zhxu</groupId><artifactId>okhttps</artifactId><version>4.0.0</version></dependency><dependency><groupId>commons-io</groupId><artifactId>commons-io</artifactId><version>2.11.0</version></dependency></dependencies></dependencyManagement>
然后，在子模块中，就可以把对应的依赖版本去掉了！
可见这里，子模块中只需要引入对应依赖，而不需要指定版本了！因为子模块会向上查找父模块中dependencyManagement标签中对应依赖的版本。
这样，就起到了统一管理版本的作用，只需要在父模块的dependencyManagement中修改对应依赖版本，子模块中对应依赖都会相应地使用这个版本。
dependencyManagement的注意事项：
dependencyManagement仅用于管理版本，而不会为自己以及子模块导入依赖，因此在dependencyManagement中声明依赖后，对应的子模块仍然需要在dependencies中加入依赖- 在
pom.xml中dependencyManagement和dependencies同级，并且dependencyManagement中也需要有一个dependencies dependencyManagement不仅可以管理子模块的依赖版本，也可以管理自身的依赖版本- 若不想让某个子模块使用父模块
dependencyManagement的版本，那就在这个子模块的dependencies中声明对应版本
(3) 总结
总而言之，对于所有子模块都共用的依赖，我们只需在父模块的dependencies中引入这个依赖即可，而不需要再在子模块pom.xml中引入。
而对于不是所有子模块都需要的依赖，而是部分子模块需要的，又要统一版本管理，这时除了在需要这个依赖的子模块中引入依赖之外，还需要在父模块中的dependencyManagement声明这个依赖及其版本，这时，可以去掉子模块中对应依赖的版本号，使其遵循父模块中声明的版本。
示例仓库地址：
