从零到一搭建基础架构(2)-如何构建基础架构模块划分

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框架的应用，我建议包划分为以下几个模块

模块这样划分之后，其实相对而言结构已经比较清晰了。

我们将Common工程划分为以上几个模块，相当于定了一个业务模块划分的标准，即为一个脚手架。后续业务模块也按照这个Maven的分包规范进行划分模块，如果有需要依赖Common包所提供的的一些标准功能，可以分别依赖对应的Common-Model。

比如微服务应用我们需要使用统一的openFeign异常处理、序列化策略等，我们只要直接引入Common工程的rpc的Maven依赖即可，通用的配置不用再各个服务里面重复定义。

这里有的小伙伴会有疑问，比如common包中有的自动注入的配置我需要，有的自动注入的配置我不需要这个怎么办？ 我们可以利用Spring所提供的@ConditionalOnProperty注解来控制配置的加载与否。 各个模块都有自己独立对应的Common包，配置也都是可插拔的。 PS: 关于自动注入的三方starter包不太了解的，可参考：手把手教你如何编写springboot中starter

三、总结

本文围绕Maven的多模块为大家介绍如下几个知识点：

1. 单体模块在业务日益复杂时的局限性。
2. 单项目，单公共模块，多业务模块下工程膨胀的局限性。
3. 抽离Common-Frame框架并划分多模块制定业务模块划分规范，让业务工程可以专注做业务相关逻辑，共有逻辑都交给Common工程处理。

最后，我们把第一节版本管理的依赖串起来一下，看一下依赖结构是怎么样的。

​