框架的建设思路和组织结构

在大部分互联网公司中，往往会基于主流java开发框架定制出适合自己公司的统一框架。目的是为了统一大家的编码规范、协议规范、技术栈、业务交互规范等，从而提高大家的工作效率。

就像我们当初使用数据库连接一样，一开始我们使用基本的JDBC API，后来我们使用主流的mybatis,再后来spring boot帮我们封装了mybatis-spring-boot-starter组件。使得我们接入数据库越来越方便。

同样，当我们开发一个后端项目时，也会用到不同的中间件，对应的，springboot也帮我们封装了不同的starter组件。

既然springboot已经如此的完善，那我们在定制企业框架时，就不必重复造轮子，直接基于springboot进行二开即可。

那具体应该怎么做呢？

首先：定版本

主要是jdk、springboot、springcloud的版本。

因为笔者当时最稳定的版本是2.6.11.所以后面的介绍都已springboot2为准，对应的jdk8，spring5.

其次：定技术栈

既然定好springboot+springcloud的基石，其他也就是配套的生态。如下为一些常见的配套工具：

代码分支管理：git

私服：nexus

代码仓库：gitlab

数据库：mysql

mq: rocketMQ

缓存：redis

搜索引擎：ES

当然也有一些类似项目管理，需求管理的工具：比如jira/禅道/TAPD(腾讯出品）

最后：定结构

为了让框架具备足够的稳定性和一定扩展性，需要将框架进行解构，具体怎么做呢？

方法1：按照组件类型拆

比如，可以根据框架的层级结构，将其分为：

frame-web	web处理层
frame-middleware	中间件处理层
frame-infra	基础设施层
frame-constant	静态常量
frame-tool	常见工具类

类似种种。

其实就是将框架按照功能模块拆分。每个模块基于对应的角色分类。比如frame-infra就是框架的核心层，主要做一些最底层的抽象；frame-web则负责处理接口层出入参处理的部分。

方法2：按照组件粒度拆

mybatis-boot-starter
redis-boot-starter
feign-boot-starter
…………

不同的划分方式都有一定的道理。没有绝对的对与错。这就需要我们有自己的建设标准。

我的建议是：取长补短，找到最适合自己公司规模、业务模式的那种。

玩过俄罗斯方块游戏的都知道，不同的方块占据的空间是不一样的，且有些方块通过对应的凹凸槽设计可以紧密合并。

基于这样的思路，我们将框架设计成如下层级：

其中util类粒度最小，主要存放一些场景工具等，比如类似hutool提供的工具组件；

starter类组件，主要提供一些常见的中间件介入客户端，比如mybatis/redis/es等；

而module组件，则主要基于公司业务应用，进行一些定制化组件的封装，其往往基于starter和util类型组件组合而来。此类组件相比而言不会太多。

接下来，我会基于不同组件，展开具体的实战讲解。