从零搭建Spring Boot脚手架（1）：开篇以及技术选型

1. 前言

目前Spring Boot已经成为主流的Java Web开发框架，熟练掌握Spring Boot并能够根据业务来定制Spring Boot成为一个Java开发者的必备技巧，但是总是零零碎碎不够系统，所以萌生了从零搭建一个后端脚手架的想法。并把这个过程中的细节思路和之前的一些文章结合起来展现给大家，希望能够实实在在帮助学习Spring Boot的同学，当然能力有限如果有不足之处还请多多指教。

2. 面向的群体

首先，这个定位不是完全没有接触过Spring Boot的初学者，因为Spring Boot的简单入门并不是特别难，找一些其他大佬的入门教程学习一阵就可以很快的入门；而是面向具有Spring Boot的学习经验和不够熟练的同学们，同时提供一些可以开箱即用的解决方案到实际开发中。

3. 项目结构介绍

其实我不太喜欢那种相互依赖整了好几个模块，DAO、Service、Controller各搞一个层，然后层层依赖。对于单体项目来说这种结构把简单的事情复杂化了，容易导致依赖管理混乱。所以一般的简单项目我都建议采用下面的结构：

项目总体结构

kono-dependencies是一个依赖版本管理的模块，负责kono-app所有的依赖版本、依赖选型的管理。原则上kono-app所有的依赖都应该来自kono-dependencies而且版本从kono-dependencies继承，这样能做到依赖版本的集中控制，使得技术选型和兼容性得到保证。

以Maven为例，kono-dependencies只会包含一个pom.xml，而且打包方式packaging只能是pom。所有的依赖都被dependencyManagement管理。

cn.felord
kono-dependencies
1.0.0.RELEASE

pom


   

这里有一个小技巧，我们把Spring Boot的父依赖加入管理，就等于把项目的Spring Boot所有的官方starter纳入了管理：

    
        
            org.springframework.boot
            spring-boot-starter-parent
            ${springboot.version}
            pom
            import
        
         
    

当然如果有业务需要可以分更多的模块，但是依赖管理一定要清晰、可控。

4. 版本号

版本号的规则也是很有学问的。这里我选用了最容易理解的方式，也是Spring Boot采用的版本号命名风格。

Spring Boot版本号风格

• Major 主版本号，当有非兼容性的变更时，递增主版本号。

• Minor 次版本号，当以可向后兼容的方式增加了功能时，递增次的版本号。

• Patch 补丁版本号，当有向后兼容的 bug 修复时，递增补丁版本号。

• Label 标记，用来区分开发版、快照版、里程碑版、正式发行版。

5. 技术选型

以下都是 Java 技术栈特定场景下的常用选择：

• springboot 基础整合框架

• servlet4 web 标准

• undertow 或者 tomcat web 容器

• spring cache 缓存抽象层

• spring security 安全框架

• json web token 安全框架token技术

• mybatis plus 3 ORM增强

• spring data jpa (选)

• redis 缓存中间件

• mysql 数据库

• mapstruct bean 转换器，编译期使用

• lombok bean 简化工具

• swagger2 文档（开发测试）

• docker 容器技术

在一开始，这里面的一些技术并不会集成进去，随着迭代会在合适的时机加入它们，甚至会加入这里面没有的技术栈。

6. 最后

通过从零搭建脚手架的过程您可以循序渐进的学到如何整合一些功能到项目中，同时还能看到一些实际开发中才能遇到的一些问题以及解决这些问题的思路。同时如果在这个过程中您有好的建议和问题也可以和我进行沟通，感谢持续关注:码农小胖哥，共同提高，我们下一篇见。

往期推荐：

Spring Data R2DBC响应式操作MySQL

请不要再使用判断进行参数校验了

Spring Security 实战干货：从零手写一个验证码登录