本文为稀土技能社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！
Hello，这儿是爱 Coding，爱 Hiphop，爱喝点小酒的 AKA 柏炎。
本篇是手把手建立根底架构专栏的第二篇。
在第一篇：《从零到一建立根底架构(1)-玩转maven依靠版本办理》中给咱们介绍在根底架构建立的进程，咱们怎样使用Maven在的依靠传递与版本操控来主张起一个一致的版本操控工程。
本文将为咱们详细介绍怎样区分工程内的Maven模块，开发纵享丝滑。
一、为什么咱们要区分Maven模块
咱们通过Idea的Springboot脚手架新建一个Springboot工程的时分，项目默许的初始化结构便是单模块结构。
咱们运用单模块进行MVC的规范进行开发的时分十分的简略粗犷，在单模块下面建立Service包、Mapper包、Contoller包就能够开端开发了。
Demo、小型东西类型、小型线上旁系事务支撑性等独立性强的运用运用单模块的项目结构便是短平快。
项目结构简略，开发方便。
可是一旦你的运用事务逻辑杂乱起来，咱们需求将一个运用拆成两个或许多个运用。在布置的时分也多个运用布置。将原先的一把梭哈结构，变成多点开花。
这个时分咱们就需求将原有的单模块结构进行拆分，我看过有的简略粗犷的拆分，多个事务运用还是在一个工程下面，将各个运用的通用逻辑独立一个上层Maven公共包。
这种办法的话在打包布置上将原先的project从一个包变成了两个包，可是在写代码的时分本质上还是在大的父级project下的。
随着事务越来越杂乱，服务需求不断的增多，咱们不行能让父级project下的子project无限的添加。咱们需求将各个子project都独立出来。
现在projectA跟projectB是相互独立的，事务相互独立，开发也相互独立。
看上去现已是独立的事务团队独立开发的形态了，可是咱们细细一看，发现上层所依靠的东西包被CV了一份到各个project里边，那些所共用的东西类、逻辑、常量、装备类等都需求CV一份。
这不是麻瓜是什么？
既然这部分的Maven依靠具有可复用性，那咱们直接把他抽一个东西工程不就得了吗？
一切事务工程都依靠这个工程，那根底一些东西类都不需求独自界说了。
二、怎样区分Common Frame模块
友情提示：clone common frame demo项目到本地结合看更好哦
你需求先clone common-dependency
然后履行mvn clean install 将 common-dependency包打到你本地库房
否则你拉下来common-frame工程后会报找不到
<parent> <groupId>com.baiyan</groupId> <artifactId>common-dependency</artifactId> <version>1.0.0-SNAPSHOT</version> </parent>
原先咱们关于common frame的概念更多认为这是一个东西包，里边界说一些东西类，常量。
咱们会将一切的共有部分都认为是单体工程，只不过它的定位是给支撑事务工程进行事务开发而已。
那么咱们怎样来区分Common工程的Maven模块呢？
事务模块区分没有一个严格的业界规范，也没有说一定要依照怎样规划。
微服务架构体系下，以openFeign作为rpc结构的运用，我主张包区分为以下几个模块
| Maven模块 | 模块界说 | 特别说明 |
|---|---|---|
| api | 界说微服务供给者的接口界说，将openFeign相关的接口界说，所必须的交互实体，枚举等界说在此处 | 单体服务可去除此包 |
| base | 与事务无关的东西类与通用装备办理 | |
| rpc | api包的openFeign界说完成，这儿假如嫌麻烦api包跟rpc包能够合并，我习惯分隔，接口结构更加明晰 | 单体服务可去除此包 |
| service | 事务处理，这个包比较大，里边的逻辑会比较多 | |
| interaction | 用户交互层，controller，MqListener，openFeign接口完成等本运用与外部交互的办法界说 | |
| start | 启动包，装备文件界说，日志办理界说等大局处理装备界说 |
模块这样区分之后，其实相对而言结构现已比较明晰了。
咱们将Common工程区分为以上几个模块，相当于定了一个事务模块区分的规范，即为一个脚手架。后续事务模块也依照这个Maven的分包规范进行区分模块，假如有需求依靠Common包所供给的的一些规范功用，能够别离依靠对应的Common-Model。
比如微服务运用咱们需求运用一致的openFeign异常处理、序列化战略等，咱们只需直接引入Common工程的rpc的Maven依靠即可，通用的装备不用再各个服务里边重复界说。
这儿有的小伙伴会有疑问，比如common包中有的主动注入的装备我需求，有的主动注入的装备我不需求这个怎样办？
咱们能够使用Spring所供给的@ConditionalOnProperty注解来操控装备的加载与否。
各个模块都有自己独立对应的Common包，装备也都是可插拔的。
PS: 关于主动注入的三方starter包不太了解的，可参阅：手把手教你怎样编写springboot中starter
三、总结
本文围绕Maven的多模块为咱们介绍如下几个知识点：
- 单体模块在事务日益杂乱时的局限性。
- 单项目，单公共模块，多事务模块下工程膨胀的局限性。
- 抽离Common-Frame结构并区分多模块制定事务模块区分规范，让事务工程能够专心做事务相关逻辑，共有逻辑都交给Common工程处理。
最后，咱们把第一节版本办理的依靠串起来一下，看一下依靠结构是怎样样的。
四、联络我
假如你觉得文章写得不错，点赞评论+关注，么么哒~
微信：baiyan_lou
我的第一本小册《浅显易懂DDD》现已在上线，欢迎咱们试读~
DDD的微信群我也现已建好了，由于文章内不能放二维码，咱们能够加我微信,备注DDD沟通，我拉你进群，欢迎沟通共同进步。
