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工程处理。
最后，我们把第一节版本管理的依赖串起来一下，看一下依赖结构是怎么样的。
