微服务的目录结构一般分为如下几个模块：
当我们做的项目稍微大一点之后，就会经常遇到需要把不同的模块分离出来的时候，比如微信的朋友圈、微信支付、聊天服务等模块，像这种微服务项目一般都会把base、common、前端抽离出来。
common：用于存放一些公用的模块，比如枚举类（成功和失败返回数据），对外公开，pom里面不含任何和业务相关的东西。
base：一个写业务逻辑的包，把项目公用的业务模块抽出来放到项目里，不对外公开。在base的pom文件里包含了所有公用业务逻辑的依赖，在base里引用之后，其他的业务模块就不需要再进入这些依赖了（依赖传递）。
注意在其他业务逻辑的模块里面，都需要引入base：
base依赖于common，因为实现base里面的业务也需要用到common里的枚举等。
在父项目的pom文件里面有一个<dependencyManagement> 标签，像这样：
所有导入的依赖都被放到了<dependencyManagement> 标签里面，
<dependencyManagement> 的作用：
管理依赖版本号，微服务项目如果把所有模块的依赖各自引入，会出现版本冲突的问题，所以<dependencyManagement>充当了一个全局的依赖管理。当某个 Maven 模块需要具体引用某依赖的时候，直接在集合中指定若干个，这样就可以实现整个项目依赖的全局管理，不至于零碎地分布在每个模块中。在此标签元素中声明了所需依赖的版本号等信息，当子项目引入此依赖 jar 包时就需要列出版本号，如果不添加此标签的话子模块的pom文件就会直接继承。
relativePath的作用：
默认值为../pom.xml，会从本地路径中获取parent的pom。
如果是一个空值，表示将始终从仓库(父级的pom文件)中获取，不从本地路径获取。
maven构建jar包时候查找顺序：relativePath元素中的地址–本地仓库–远程仓库
到此这篇关于springboot多项目结构实现的文章就介绍到这了,更多相关springboot多项目结构内容请搜索编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程网！
