本章目标

完成项目架构设计和数据库结构设计

重点：全是重点

好的，从上一章，我们已经得出了项目的大致需求，很多程序员到这了这一步可能直接就开干了。要是按照瀑布式的软件开发流程来说，现在到了总体设计阶段。其实，就算你真的开干了，这一步也不可能跳得过去，只不过有经验的程序员瞬间就已经完成了整体设计。

好吧，作为一个有素养的程序员，还是需要用文档的方式，做一下整体设计，作为一个老程序员，越来越发现，写文档是能够非常好的帮助你思考，能够帮助你把一个项目思考的相对比较全面。如果你在跟着我一起做这个项目，虽然我已经做出来整体设计，还是建议你把整体设计的图，自己画一遍，因为你在跟着画的时候，一定会去思考。相信我，这个事情会对你有帮助。

总体设计（架构设计）

很多同学对总体设计没有什么概念，其实早期的时候我也一直很蒙圈。当时那个阶段自己做的都是很小的系统，基本上开发工具里一个Project就搞定了，所以那个时候的总体设计对于我来说无非就是套用一下三层架构、MVC架构之类的，真的没啥搞的。但现在这个项目可以很好地说明什么是总体设计。

以我的经验来说的话可以包含这么几个步骤

1. 技术选型

   这一项不用多说，做软件项目技术选型是一定要做的。做这一步的时候要考虑的主要因素有项目应用场景、典型需求、团队技术能力等等

2. 部署结构设计

   这一步应该主要考虑的是应用场景和模块之间的关系

3. 工程文档结构设计

   这一步很多人没太当回事，我倒是认为做这一步是代码质量最基本的保障。

4. 重、难点需求解决方案选型

   总体设计一般情况下是不考虑具体的需求的，但个别重难点问题不考虑的话可能会影响整体的架构，假如需求中有一条自动对接检测仪器直接上传检测结果数据，那么项目在检测人员那一端用WEB的方式来解决就不太可能了，因为对接仪器设备一定得是C/S模式，B/S大部分情况下是做不到的。

5. 数据库结构设计

在谈论总体设计之前，先要明确项目的概念。“项目”翻译成英文就是Project，在很多开发工具里，开始写代码时都要先创建一个Project，核酸检测平台这个项目来说，用一个Project可能就不太行了。

而实际上，如果一个项目比较复杂，需要多个程序包的时候，很多开发工具也是可以支持的，比如说IDEA，创建完项目之后，你还可以在项目中再创建一个Module(模块)，你可以把独立的程序包放在一个Module中。

为了避免沟通中的障碍，我们先来统一下术语的定义：

• 项目：指整个核酸检测平台
• 模块：指开发工具中的一个程序包。如果我们做前后端分离的话，前端和后端各一个程序包。
• 应用：指部署包，可以指在服务器上的一个部署包，也可以指手机上的一个APP，这个部署包有可能是前端后端在一起的，也可以是前端后端分开的。如果是前后端分开到两个部署包，就是两个应用，如果是一个部署包就是一个应用。

术语定义这一部分是参考很多标准化技术文档的模板，有一段时间不是太理解为什么要有术语定义这东西，也不知道术语定义要写些什么，后来做的项目多了才知道术语定义最大的意义就是消除沟通理解上的障碍，防止说到一个词张三、李四的理解不相同的情况。

很多时候，没有术语定义这一部分项目、工程也能够顺利完工，但不得不说，有这一部分是能够消除一些理解上的偏差的，作为一个靠谱的程序员,提前把工作做到前面，是必备的素养，掌握这个方法还是非常有必要掌握的。

技术选型

下面来进行技术选型，我们来依次思考下面几个问题：

• 整个项目涉及到哪些端？

  答：PC端、手机端

• 手机端采用什么方式访问？

  其实在用的核酸检测平台已经做出了选择，那就是APP，我们来思考这个问题其实就是还原一下架构设计的思路，可选择的方式一般有：APP、H5站点、微信小程序，优缺点对比：

  	优点	缺点
  APP	使用体验好，性能可控。	升级较麻烦，存在IOS、Android跨平台的问题，开发成本最高，但可以通过开发模式降低成本
  H5站点	升级部署很简单，不存在平台差异性，开发成本最低	使用体验差，受手机浏览器体验影响很大
  小程序	不存在平台差异性，开发成本较低	一旦部署，所有人都能够使用，有一定风险。另外平台是以城市为节点部署的，如果发布在小程序端，上线审核方面会有一定麻烦。

  • 就这个项目来说，因为是工作使用，并不适合向公众开放，首先可以排除小程序这种方式。

  • 其次使用H5站点这种方式使用体验极差，同样不适合工作，但作练习项目来说的话倒是不错的选择。

  • 采用APP的话，升级的问题可以做自动升级机制，最大程度减少升级部署的麻烦，另外IOS可以不考虑，因为IOS审核上线比较麻烦，再一个工作手机用APPLE，有点拉仇恨哟。因此从实际出发，采用APP是最合适的方式。

• APP站采用什么技术开发？

  可选择的方式有：NativeApp、WebApp、HybridApp

  	Web App（网页应用）	Hybrid App（混合应用）	Native App（原生应用）
  开发成本	低	中	高
  维护更新	简单	简单	复杂
  体验	差	优	优
  Store或market认可	不认可	认可	认可
  安装	不需要	需要	需要
  跨平台	优	优	差

  就本项目来说，因为是工作使用的APP，涉及到的人群还是比较多的，对于程序的稳定性、可用性要求较高，甚至可能会要求即使服务器挂掉也不能影响核酸采集正常进行，而APP上的业务逻辑并不复杂，因此使用NativeApp的方式可能更好一些，至少也是HybridApp，不建议采用WebApp的方式。

  不过我们作为练手的项目来说的话，可以考虑采用WebApp的方式，甚至为了调试方便，采用H5的方式都是可以的。

• 项目涉及到不同类型的人员，其中采集人员、转运人员、检测机构接收人员应该都要使用APP，他们使用相同的APP，在角色上区分，还是使用不同的APP。

  这个问题关系到部署结构，所以肯定是要考虑到的。

  很多初学者一看到多角色系统，就要上权限控制模块，其实不然，对于本项目来说，业务逻辑不复杂，各角色之间几乎没有共用的功能，对于这种项目，我个人建议直接分开，不要上权限角色控制。从使用入口上自然分开。减少权限控制对业务代码的影响。

• 团队成员能够驾驭哪些技术

  这一点非常重要，任何工程都是要考虑成本问题的，除非你是搞科研，工程和科学完全是两个研究方向，这也是中国会有科学院和工程院之分的原因。选择技术栈的时候建议考虑下面两点：

  • 在满足需求的情况下选择团队比较熟悉的技术
  • 尽量选择经受市场检验的技术

好了，以上是真正做这个项目时，选择技术栈要考虑的因素，现在咱们作为初级开发的练手项目就比较简单了。

• 采集人员端、转运人员、接收人员端采用移动端H5页面，后期可以改造成HybirdApp或WebApp
• 运营人员、上传人员端采集PCWeb应用
• 非功能性需求，做到以下几点
  • 界面整洁大方，无娱乐要素
  • 页面影响速度在1.5秒以内

所以我们的技术栈基本可以出来了：

• 数据库MySql5.7
• 后端：SpringBoot+SSM技术栈，开发工具：Idea2021版
• 前端：VUE技术栈，版本Vue3.0，开发工具：VsCode或HBuilder
  • PC端：elementUI
  • 移动端：Vant（如果想做成APP的话，也可以选择uniapp）

部署结构设计

上一部分已经讲了，不同角色使用的应用独立开，所以我们就要根据不同的角色分别部署他们的应用。

画出部署结构图如下：

之所以这样部署有如下考虑：

• 开发采用前后端分离，前端、后端在部署的时候其实可以部署到一起的，而且也比较简单，之所以选择前后端分开部署其实是有点炫技的嫌疑，因为这样在部署的时候可以用到反向代理技术。而部署到一起的话基本就不需要反向代理了。

• 采集人员前后端独立部署，而转运、接收、上传人员后端并没有独立部署。

  原因是采集人员的并发量相对是比较高的，这样分离可以减少相互之间的影响，如果系统要上分布式的时候大概率会把采集人员的后端服务做扩容，以增大并发量，相比之下转运人员、接收人员、上传人员的使用频次相对都低很多。当然你也可以每一类人员都独立部署

  虽然咱是自己做着玩，但还是尽可能接近实际情况，这样才能学到更多的经验，而不是纯增删改查。

• 运营人员独立部署。

  原因是运营人员站属于权限较高的一类，独立部署减少安全风险，没毛病的。

有的同学看完之后可能会想，有必要这么搞吗？没多少功能的平台呀。

而事实是正在广泛应用的核酸检测平台很有可能就是这么干的。没准人家做了更多的部署节点呢。所以咱这样设计并不算过份。总结下来需要部署三类应用

• 数据库，采用Mysql 5.7
• 前端，采用Vue技术栈，PC搭配ElementUI，移动端搭配Vant
  • 移动端
    • 采集人员端
    • 转运人员端
    • 接收人员端
  • PC端
    • 上传人员端
    • 运营人员端
• 后端
  • 采集人员端
  • 其它人员端
  • 运营人员端

工程文档结构设计

上一步完成了部署结构设计，接下来进行工程文档结构设计。这一步的内容很简单，就是设计项目的文件夹结构。规定哪些内容是项目的工程文件，要受GIT项目的管理，什么内容要放在什么地方。

有可能全网只有我一人把这一步提到和部署结构设计同等的高度，这一步看起来似乎没那么重要，无非就是文件夹怎么起名字，什么代码放在什么地方。

而我在工程实践中发现，对于很多初级程序员来说，起名字这个事情太过随意，往往会给后期带来一些麻烦，还有文档、脚本、代码随意放，会导致工程文件非常混乱。而对于有强迫症的我来说，这是无法忍受的。

不知道有多少次，项目做到一半，修改早期一个命名的问题，一改就是几十个、上百个文档。通常敢于下这个决定往往就是因为那个命名过渡的困扰自己，达到无法忍受的程度。后来在一些项目中有意识的在前期做好工程文档结构设计，发现确实能够避免一些麻烦。

这一步也可以说是项目的开发规范设计。它不同于代码规范，代码规范更多说的是代码怎么写，哪些命名可以用，哪些命名不可以用。往往指的是文件内部的事情，开发规范更多的是约定文件和文件夹之间的关系。

有经验的程序都知道很多时候通过项目的包名、文件夹名、类名就大致能够判断出来这里面代码、文件的作用，而现在的工程都是越来越大，动不动一个项目几十万行代码、上万个文件，没有一个好的文档结构设计真的是挺头疼的。

这一步要有下面几个步骤：

第一步：项目和模块命名

项目中文名为核酸检测平台，翻译为英文是：Nucleic acid testing platform

所以项目的英文代号为：NATPlatform，这个作文整体项目文档的根目录。

数据库名称：nat_db

下是各个模块的命名

• 前端
  • 采集人员：collect_web
  • 转运人员：transfer_web
  • 接收人员：reciever_web
  • 上传人员：uploader_web
  • 运营人员：manager_web
• 后端
  • 采集人员：collector_server
  • 其它人员：other_server(这一个模块在内部的包名依然还是要分开的）
  • 运营人员：manager_server

第二步：约定项目工程文件内容

工程文件内容不仅仅包含代码，还应当包含需要保留下来的文档、原型文档、脚本、测试数据等等。

工程文件通常可以分为下面几类：

1. 代码文件

   1. 前端代码
   2. 后端代码

2. 数据库（MYSQL数据库文件本身不适合作为项目工程文件，但是数据库的建库脚本是可以的）

   1. 建库脚本
   2. 初始化数据脚本
   3. 测试数据脚本

3. 项目文档

   1. 管理文档：立项文件、会议记录等有必要保留下来的文件都可以放进来

   2. 需求文档：原型设计、流程图、需求说明书都属于需求文档，除这些之外还应当包含一些客户方提供的电子文档。

   3. 技术文档：数据库设计文档、接口文档、规范文档等。

      现在的开发中也有很多文档工具，比如swigger、apipost工具等，如何使用swigger这样的工具的话，要说明文档的使用方式。

      像apipost之类的在线软件如果能导出的话，可以导出，如果不能导出，在文件夹里就有一个文档说明这些在线文档的地址、访问权限等。

4. 交付文档

   交付文档不同于项目文档，项目文档是自己保留的，交付文档是最后要交付给客户的文档资料。

5. 配置文档

   这类文档是有一定保密性要求的，项目可能涉及的密码、权限分配数据等。一般不要和其它文档放到一起。

对于咱们这个练手项目来说，交付文档、配置文档应该是不需要的，项目文档的话，应该会有一些，但应该不多。

第三步：设计文档结构

根据上一步的内容，设计出文档结构如下：

-─NATPlatform												项目根目录，也是代码管理的根目录
    ├─db														存放数据库脚本
    │      initData.sql							初始化数据脚本，部署前要生成下基本数据。
    │      initDb.sql								初始化数据库脚本，可以建库建表后生成，每次修改结构后更新该文档
    │      testData.sql							测试数据脚本，有可能一个文件不够，可以增加
    ├─deploy 存放部署包，不需要被GIT管控，项目的模块比较多，配置好生成部署包的路径，在发布的时候比较方便
    │  ├─server								
    │  └─web
    ├─doc														项目文档
    ├─server												后端代码，idea中项目的根目录，下面的几个文件夹是idea中的模块
    │  ├─collector_server						
    │  ├─manager_server
    │  └─other_server
    └─web						    前端代码，vscode/hbuilder的根目录，省去打开多个项目窗口来回切换的麻烦
        ├─collect_web
        ├─manager_web
        ├─reciever_web
        ├─transfer_web
        └─uploader_web

怎么样，是不是挺清晰的，最主要设计的时候还考虑到在开发工具中使用的因素，最大限度的让开发更加便捷。

文档结构设计好并不是一成不变的，如果项目开发过程中发现设计不合理，完全可以调整。

第四步：选择源代码管理工具和平台

源代码管理工具比较常用的就是git\svn\vss，根据各自团队的情况选择就好，我的选择必然得是git。

除了工具，还是要选择一下平台，除非你打算把你的代码就放在自己的电脑上。

平台可常见的有gitee、github、微信开发者平台、阿里开发者平台。当然了，你也可以自己搭建git服务器。

我选择的是微信开发者平台，github网速是个问题，gitee限制太多。微信开发者平台和阿里开发者平台都还是不错的，选择微信开发者平台的原因是微信平台还有集成的git客户端，与微信开发者平台的集成度也比较好。我试用过，用起来还不错。客户端的话根据自己的喜好选择就好。

重难点技术方案选型

这个项目没啥难点，几个关键点的技术方案上一章已经说过了，内容如下：

• 打印条码：lodup，我们是拿来测试的，不太可能有条码打印机，但可以直接打印到A4纸上拿来测试
• 扫码，html5-qrcode或jsqrcode、zxing-js
• EXCEL导入导出，POI或EasyExcel
• 手机验证码，多的是，随便选就可以

数据库设计

学过数据结构课程的同学应该都知道一句话：程序=数据结构+算法。如果你不知道，请你回去把书翻出来认真看一看，非常非常的重要。

在做数据库设计之前，有一点要提到，我们从第一章下载的APP中可以看到，注册采集人员的时候需要选择所在社区，这个功能需要行政区划数据，虽然上海的APP只有上海市的。但人动来造这个数据还是比较坑的。

很多时候我们在做一个系统的时候都需要一些基础数据，就像这个平台中的行政区划数据一样，他不需要运维人员或管理员去维护，但是必须得有这些数据。

行政区划的数据其实就在国家统计局网站（地址：http://www.stats.gov.cn/tjsj/tjbz/tjyqhdmhcxhfdm/2021/index.html）上，有兴趣你可以去写个爬虫下载。但我想大多数人可能比较懒，没关系，我帮你收集好了，写文件的时候，最后更新的是2022年的，需要的同学可以关注我的微信公众号（姚Sir面试间），回复行政区划，就可以下载。

设计的过程不再详说，直接上数据库关系图。如果有不同看法的同学欢迎评论区互动讨论。

至此，我们的总体设计，基本差不多了。我在写这篇文章的时候其实并没有把系统做出来，所以做的过程中没准还会修改数据。如果有修改的话，在后面的文章中再提。

急性子的同学可能要说，两章了一行代码没见到，哈哈，其实做软件项目动手之前多想一想肯定是没坏处的，下一章就该上代码了，我正在整理中，喜欢的同学三连一下不迷路。