Spring Boot项目开发实战销售管理系统——系统设计！

Spring Boot项目开发实战——销售管理系统

在前面的章节中我们详细介绍了Spring Boot各个功能的使用，本章将新建一个销售管理系统项目，演示项目从需求分析到功能分解，再到各个功能的实现过程，最后再使用Docker部署上线的完整过程。本章将从实际开发的角度介绍Spring Boot及其各个组件，让读者对Spring Boot的理解更加深刻。

系统设计

系统设计是在项目初始阶段对项目的整体规划，包括项目需求分析、项目的边界规划、项目开发人员安排、项目时间安排（开发时间、测试时间、交付时间）、项目性能设计、代码规范制定、API规范制定、技术难点预估和调研等。系统设计是进行项目开发的第一步，在进行系统设计时需要完成以下工作：

用思维图列举系统中的所有角色和各个角色之间的关系；

用时序图绘制出所有复杂的工作流程；

用类图定义出满足部分功能的类关系，列举出类属性、方法、抽象层和接口类等，设置类与类之间的关系；

用E-R图设计系统表之间的关系。

系统介绍

上海兮索电力科技发展有限公司是一家从事电气制造和销售的公司，该公司的弱电设备业务遍布全国各地。在日常的运营过程中该公司发现，当前的客户管理、产品管理、客户的跟进、订单管理已不能满足公司发展的需要，一部分日常的烦琐工作需要实现电子化，以提高工作效率，更加方便、快捷地完成对销售任务的跟进和客户的管理。因此需要开发一套销售管理系统，这套销售系统能彻底解决公司在客户管理、产品管理、订单管理等方面的现存问题。因此公司立项开发一个销售管理系统在互联网中运行使用。

本项目是一个功能比较简单的销售管理系统，其主要作用是将销售人员和管理者的日常工作电子化，包括销售员登录管理、客户管理、客户的跟进、产品管理、销售订单管理、销售员的日程管理等功能。销售人员登录系统后可以进行客户管理、客户跟进和销售订单的管理工作。系统要具备权限设置，销售人员只能查看自己的客户和自己的订单，管理人员拥有系统的所有权限，可以查看所有的信息，包括所有销售人员的订单信息和客户信息。根据公司目前的规模，本系统的使用者总人数为30～50人，其中，管理者为5～6人，其他都是普通的销售人员。系统需要在外网中使用，方便销售人员能够随时通过互联网进行工作。

未来，随着公司规模的扩大，系统的使用者可能会达到80人，每个人的客户可能会超过100个，每个客户每个月可能会产生3个左右的订单，每个客户每月可能需要跟进10次，需要系统能满足公司未来3～5年使用业务的需求。

系统功能需求分析

需求分析的目标是将产品的需求功能梳理出来，并且用通俗易懂的文字进行描述，为开发人员和测试人员提供依据。需求分析的基本任务是：准确地回答“系统必须做什么”这个问题，也就是对目标系统提出完整、准确、清晰、具体的要求。

需求分析一般分为以下4步：

（1）获取需求：了解所有用户类型，包括潜在用户类型，以确定整体目标和方向。这一步需要完成以下工作：

对用户进行访谈和调研，对各个角色的需求进行归纳、整理和分析。

业务需求方面，模拟业务场景，对业务逻辑和业务流程进行梳理，整理出业务需求。

（2）根据系统分析需求，完成以下4项工作：

根据业务逻辑和业务流程画出流程图，分析业务需求及业务数据的流动顺序（完成数据流图：Data flow Define；ERD用户用例：use case的绘制）。

挖掘每个需求点的产生原因及实际的作用。

挖掘每个需求点的隐含需求及需求的前置条件。

挖掘每个需求的必要性。

（3）需求确认：整理分析阶段的所有需求，确保需求一致。这一步需要

完成以下工作：

整理不清晰的需求。

分别与对应用户确认以上需求点，保证需求的一致性和清晰性。

（4）编写需求文档：使用自然语言，以通俗易懂的语言展现需求分析，可以添加图形辅助阅读。输出文档包括功能需求和非功能需求，并且最好把原始需求加入需求文档中，作为一个章节单独列出。

整个系统的用户分为两类：第一类是普通的销售人员，第二类是管理员（是一类权限更高的销售人员）。

普通销售人员的权限包括查看产品、创建订单、创建客户、查看客户、创建待办任务等，管理员除了拥有普通销售人员的所有权限之外，还能对系统的用户进行管理，并且管理员能看到所有用户的数据，而普通销售人员只能看到自己创建的用户数据。

普通销售人员在系统中有6个权限，具体如下：

创建产品、修改产品和删除产品：主要是为了与订单模块功能关联使用，订单能够关联具体的产品，公司从而能够知道哪一类产品的销量最好，能够最好地创造利润。

创建客户、修改客户信息和删除客户：对客户信息进行管理。

创建客户的跟进记录、修改跟进记录、删除跟进记录：帮助销售人员跟进客户，与客户经常联系，提高成交率。

创建和删除订单目标：为销售人员设定一段时间内的订单目标额，帮助销售人员制定业绩目标。

创建待办事项和删除待办事项：帮助销售人员安排自己的个人事项，将事项按照轻重缓急进行排序，以便更好地完成销售工作。

修改个人信息和密码：个人信息的个性化。

管理员拥有普通销售人员的所有权限，还可以新增普通销售人员、重置普通销售人员的密码及删除普通销售人员。

系统用例分析

UML的一个重要图示就是用例图，用例图用于描述系统功能的动态视图，其由参与者（Actor）、用例（Use Case）及它们之间的关系构成。要在用例图上显示某个用例，可绘制一个椭圆，然后将用例的名称放在椭圆的中心或椭圆下面的中间位置即可。

用例图中绘制一个参与者（表示一个系统用户），即绘制一个人形符号。参与者和用例之间的关系使用带箭头或者不带箭头的线段来表示，箭头的起始点是对话的主动发起者，箭头所指方是对话的被动接受者。

用例图是系统需求分析结果之一，用例图的主要作用是描述参与者和用例之间的关系，帮助开发人员对系统有可视化的了解。借助于用例图，系统用户、系统分析人员、系统设计人员和领域专家能够以可视化的方式探讨问题，大量减少了交流上的障碍，便于对问题达成共识。用例图可以可视化、方便地表现系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。用例方法完全从外部来定义系统功能，它把需求和设计完全分离开。设计者不用关心功能是如何实现的，对于设计者来说系统是一个黑盒。用例之间还存在一些关系，如包含、扩展、泛化。

任何用例图都不能缺少参与者，任何参与者必须要与用例关联。因此识别用例的最好方法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者。在实际开发中可以通过以下问题来寻找用例：

（1）参与者希望系统能完成什么功能。

（2）参与者是否会读取、创建、修改、删除和存储系统的业务信息，如果是，参与者是如何完成这些操作的。

（3）参与者是否会向系统通知外部的某些事件。

（4）系统中发生的事件是否通知参与者。

（5）是否存在影响系统的外部事件。根据以上系统功能分析，普通用户具有客户管理、产品管理、订单管理、业绩目标管理的权限，管理员具有普通用户的所有权限并且还有用户管理的权限。

整个系统的用例图如图9.1所示。

时序图描述的是系统中对象之间进行交互的先后顺序，在交互过程中建模成消息交换，描述了对象之间期望的信息交换和返回结果，时序图中每条消息表示对象的一个操作或者引起状态机改变的触发事件。

时序图包括4个元素：对象（Actor）、生命线（Lifeline）、控制焦点（Focus of Control）和消息（Message）。对象（Actor）为系统角色，可以是人甚至其他系统或者子系统。对象（Actor）有3种命名方式：

包括对象名和类名；

只显示类名不显示对象名，即表示它是一个匿名对象；

只显示对象名不显示类名。

生命线（Lifeline）在时序图中表示为从对象的图标向下延伸的一条虚线，表示对象存在的时间。控制焦点（Focus of Control）是时序图中表示时间段的符号，用小矩形表示，其代表在这个时间段内对象将执行的相应操作。消息（Message）一般分为同步消息（Synchronous Message）、异步消息（Asynchronous Message）和返回消息（Return Message）。

普通用户创建产品的步骤如下：

（1）单击“创建产品”按钮，跳转到创建产品页面。

（2）用户输入产品信息，单击“保存”按钮保存信息。

（3）服务器收到保存请求后对用户输入的参数进行校验，然后再将其保存到数据库中。

（4）系统将创建成功后的产品列表返回给用户。

根据以上步骤创建时序图，如图9.2所示。

用户登录系统的步骤如下：

（1）用户输入localhost:8085网址，页面跳转到登录页面。

（2）用户输入账号和密码，单击“登录”按钮。

（3）服务器接收到登录请求后对请求参数进行校验，查询用户信息，判断用户是否登录成功。

（4）将登录结果返回给用户，如果密码错误则向用户提示密码错误，如果没有错误，则登录成功。

根据以上分析创建用户登录时序图，如图9.3所示。

　技术栈的选型

这里先声明一点，如果要为公司开发一个自用的系统软件，首先应该做的就是满足当前的功能，以解决实际存在的问题，其次是尽可能地节约成本，降低日常的开发和维护成本，能用开源数据库的就不用收费的数据库。

例如，让一个20人的小公司每年花几千万元买Oracle的数据库许可证，这在国内是不大可能的事情，在满足系统需求的前提下用开源版软件进行开发是一个明智的选择。

1. Spring Boot的选择

本项目采用Spring Boot的2.3.10版本进行开发，这个版本是笔者编写本书时最新的Spring Boot框架，笔者希望读者能够学习到最新版的SpringBoot的相关知识，了解新框架的功能，因此选择这个版本进行学习。

2. JDK的选择

目前在企业级的开发中，常用的JDK版本有两个，分别是JDK 1.8和JDK11。Oracle官方宣布2019年1月之后发布的Oracle Java SE 8公开更新将无法用于商业或生产用途。虽然RedHat、阿里、亚马逊这些大企业有自己的开源定制版JDK 1.8，并且为JDK 1.8提供了安全更新，但是不会再将新的功能添加到JDK 1.8中。因此本书的JDK版本选择JDK 11。

3. 数据库的选择

数据库笔者选择了国内常用的关系型数据库MySQL，没有选择PostgreSQL，是因为没有那么多的数据分析需求和超大数据量的存储需要，至于收费数据库Oracle和SQL Server则不在考虑范围内。

4. ORM框架的选择

数据库的ORM框架笔者选择了国内流行的MyBatis，原因是MyBatis的使用者众多且容易上手。而Hibernate的入门门槛更高，而且它比MyBatis更复杂。相比Hibernate，MyBatis在复杂SQL的执行上有更高的效率，且易于优化。

5. 数据库连接池的选择

数据库连接在网页应用程序中是一种重要且有限的资源。对数据库连接

的管理能够影响整个应用程序的伸缩性和健壮性，进而影响整个程序的性能指标，因此本项目需要一个数据库连接池。数据库连接池负责分配、管理和释放数据库连接，它允许应用程序重复使用一个现有的数据库连接而不是重新建立一个。数据库连接池的可选性非常多，有c3p0、DBCP、Proxool、Druid和HikariCP等。本项目使用阿里巴巴开源的Druid，它集合了c3p0、DBCP、Proxool等连接池的优点，而且还加入了日志监控，可以有效地监控DB池连接和SQL的执行情况。

6. 前后端技术的选择

本项目没有选择做前后端分离，也没有选择使用Vue或者React来实现前端，是因为前端没有很复杂的需求，而且笔者主要是偏向于后端开发，对前端开发工作的熟悉程度只停留在能完成简单功能的层面，所以笔者选择了FreeMaker作为前端的页面引擎。

在页面的样式上，笔者选择了市面上常见的样式模板inspinia v2.8，这样笔者就可以把所有的样式全部集成到本项目中，需要时直接把组件拿过来用，减少了前端开发的工作量，并且样式很好看。

本项目是一个销售管理系统，没有复杂的权限，因此没有使用Shiro或者Spring Security。由于本项目中没有复杂的权限业务，所以设计和开发工作相对来说比较简单，没有引入更多的数据库（Redis）、组件（MQ、ELK）来辅助实现本系统。

JSON在Web开发中是相当常见的数据传输格式，需要对JSON解析并且将对象格式化为JSON数据。市场上的JSON库有很多选择，可以选择使用Gson、FastJson、Jackson、Json-lib，下面分别介绍。

（1）Gson是目前Java领域功能最全的JSON解析神器，当初是应Google公司的内部需求由Google自行研发的。2008年5月公开发布的Gson应用主要有toJson与fromJson两个转换函数，它们无依赖，不需要额外的jar，能够直接在JDK上运行。在使用这种对象转换方式之前，需要先创建对象的类型及成员，然后才能将JSON字符串成功转换成相对应的对象。需要序列化的类中只要有get和set方法，Gson就可以实现复杂类型的JSON到Bean，或Bean到JSON的转换，可以说Gson是JSON解析的“神器”。

（2）Fastjson是一个用Java语言编写的高性能的JSON处理器，由阿里巴巴公司开发。Fastjson没有其他依赖，不需要额外的jar就可以直接在JDK上运行。Fastjson采用独创的算法，将parse的速度提升到极致，超过了所有的JSON库。

（3）Jackson是当前用得比较广泛的Java开源框架，用来序列化和反序列化JSON。Jackson社区相对比较活跃，更新速度也比较快。从GitHub的统计来看，Jackson是最流行的JSON解析器之一，Spring MVC的默认JSON解析器便是Jackson。

（4）json-lib为应用最广泛的JSON解析工具，它的缺点是依赖于很多第三方包，并且对于复杂类型的转换，还存在缺陷。例如一个类里会出现另一个类的list或者map集合，json-lib从JSON到Bean的转换就会出现问题。

json-lib在功能和性能上都不能满足目前互联网化的需求。

综上所述，因为系统中没有复杂对象的JSON转换，所以笔者选择国内常用且最熟悉的JSON解析工具——Fastjson。

Apache提供了众多的commons工具包，其中lang 3包最受欢迎。lang 3是Apache Commons团队发布的工具包，要求JDK版本在1.5以上，相对于lang来说其完全支持Java 5的特性，废除了一些旧的API。lang 3版本无法兼容旧版本，于是为了避免冲突改名为lang 3。在本项目中笔者使用Apache的lang 3包和Google的Guava作为工具类包，以尽可能地减少各种依赖项目。

项目开发完成后，将其打成一个jar包，只需要安装Java的环境和MySQL数据库就可以直接运行起来。

7. 构建工具的选择

本项目使用Maven作为依赖的管理和构建工具，之所以没有使用Gradle，是因为相较于Maven，笔者认为Gradle的优势并不明显，为了项目的易用性和稳固性，笔者选择使用更加熟悉的Maven。

8. 代码规范

本项目中使用阿里巴巴的代码规范指导开发，尽量遵守相关的规范，在命名方式上选择使用驼峰的方式，数据库的设计规范如下：

（1）数据库的表名采用26个英文字母（区分大小写）和0～9的自然数加上下划线“_”组成；命名简洁、明确（长度尽量不能超过30个字符）；例如，可以使用user、sys或log给数据库中的表名加个前缀，方便对同一类型的表进行统一管理；表命名全部使用下划线来分隔并且全部使用小写字母。

（2）可以使用表前缀user_有效让相同关系的表一起显示。

（3）每个表中必须有自增主键和create_time（默认系统时间），表与表之间的相关联字段名称要求尽可能相同。

（4）用尽量少的存储空间来存储一个字段的数据。例如，能使用int就不要使用varchar或char，能用varchar(16)就不要使用varchar(256)。IP地址最好使用int类型，固定长度的类型最好使用char（如邮政编码），能使用tinyint就不要使用smallint或int；最好给每个字段设置一个默认值，并且不要设置为null。

（5）为每个表创建一个主键索引。

（6）少用text类型（尽量使用varchar代替text字段）。

（7）拒绝大SQL语句、大事务和大批量操作。

（8）不在数据库中做运算，CPU计算务必移至业务层。

（9）控制列数量（字段要少而精，字段数建议在20个以内）；平衡范式与冗余（有时在追求查询效率的提升时往往需要在表中设计冗余字段，因而不符合数据可设计范式。强调数据库设计范式能提升数据库的扩展性，但同时会降低数据库的查询效率）。

9. 版本管理

本项目的代码使用Git进行管理，使用Git提交的Message格式为type(scope): subject，其中，type为提交的类型，有以下5种：

feat：新功能开发；

fix：修补Bug；

docs：新增/修改文档；

refactor：重构代码；

test：测试用例。

scope为当前提交的影响范围，即哪个项目下哪一个模块的变动，subject提交的就是具体的变动信息，应尽可能详细。

使用Git进行功能开发时的分支管理有以下几个：

master：Git的默认主分支。

stable：稳定分支，替代master，主要用于版本发布。

develop：日常开发分支，该分支保存开发的最新代码。

feature：具体的功能开发分支，只与develop分支交互。

release：该分支可以认为是stable分支的未测试版。例如，某一期的功能全部开发完成，那么就将develop分支与release分支合并，测试没有问题，到了发布日期就将其与stable分支合并，然后进行发布。

feature-name：个人功能开发分支，个人在功能开发完成后把个人分支与feature分支合并。