如何从零开始划分并构建基础架构模块？
- 内容介绍
- 文章标签
- 相关推荐
本文共计1491个文字，预计阅读时间需要6分钟。
原文：本文字将为大家详细介绍如何划分工程内的Maven模块，开发分享经验。一、为什么我们要划分Maven模块？我们通过Idea的Springboot脚手架新建一个Springboot工程的时候，项目默认的初始化结构就。
改写后：本文将详细介绍如何划分工程中的Maven模块，并分享开发经验。首先，为何要划分Maven模块？当使用Idea的Springboot脚手架创建Springboot工程时，项目默认的初始结构为。
本文将为大家详细介绍如何划分工程内的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-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包，配置也都是可插拔的。
三、总结
本文围绕Maven的多模块为大家介绍如下几个知识点：
最后，我们把第一节版本管理的依赖串起来一下，看一下依赖结构是怎么样的。
本文共计1491个文字，预计阅读时间需要6分钟。
原文：本文字将为大家详细介绍如何划分工程内的Maven模块，开发分享经验。一、为什么我们要划分Maven模块？我们通过Idea的Springboot脚手架新建一个Springboot工程的时候，项目默认的初始化结构就。
改写后：本文将详细介绍如何划分工程中的Maven模块，并分享开发经验。首先，为何要划分Maven模块？当使用Idea的Springboot脚手架创建Springboot工程时，项目默认的初始结构为。
本文将为大家详细介绍如何划分工程内的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-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包，配置也都是可插拔的。
三、总结
本文围绕Maven的多模块为大家介绍如下几个知识点：
最后，我们把第一节版本管理的依赖串起来一下，看一下依赖结构是怎么样的。