20.如何从app业务逻辑提炼api接口

         在app后端的工作中，设计api是一个很考验设计能力的工作。在项目的初始阶段，只知道具体的业务逻辑，那怎么把业务逻辑抽象和提炼，设计出api呢？通过阅读本文，可解答以上疑惑。

         在本文中，是用以前做过的app移客ekeo第一版（以后的业务逻辑改了很多）业务逻辑来举例。移客ekeo是一款以熟人社交和真实聚会为核心的社交工具。移客以解决聚会难题为核心，你可以通过移客快速发起或者参与聚会活动，掌握参加者是否已经出发或者到达。    

         移客ekeo这个app已经停止运营了，如果想要更加了解ekeo的业务逻辑, 可下载app＂微聚＂来研究一下，这两个app在业务逻辑上是比较相近的。

         从业务逻辑到api出炉，分为下面6个阶段：

1.业务逻辑思维导图  

2.功能-业务逻辑导图

3.基本功能模块关系

4.功能模块接口uml（设计出api）

5.在设计稿标注api

6.编写api文档

1.业务逻辑思维导图

整个流程的第一步，就是抽象出业务逻辑。

抽象是什么意思？就是把相同的东西先放在一起，这是抽象的第一步。我们业务流程，就像一条河一样，从头走到脚，里面会有很多一样的东西，我们需要先抽象出来，就好比，一栋楼，就很多三角形，很多圆形，很多正方形，我们先要把这些东西抽象出来。

如果抽象都抽象错了，写接口也没啥用，就是在乱做了。

所以说抽象的第一步，就是我们其实可以通过思维导图的形式把我们相同的业务流程，抽象出来形成一个图表，然后通过关系箭头，表现出来。

1. 我们现在首先是要用思维导图把结构关系列出来，包括里面的功能

2. 我们要把相同的元素整理出来，比如说，都是相同的推送，都是相同的评论，都是图片上传，然后我们用相同的颜色，在1的图上面表明出来。

这样大家至少清楚，我们哪些业务逻辑是一样的，各位亲，这个如果都没搞清楚，你怎么敢确保后面你做的接口是完整的呢？等我们把这一步搞清楚，我们就知道了，一个模块，需要有哪些接口，那个时候，我们再用UML图，把接口和接口关系画出来，那个时候是抽象的第二步。

         根据业务逻辑整理出如下的思维导图：

2.功能-业务逻辑导图

这步的核心是＂把业务逻辑和功能模块呈现的内容结合＂。

功能模块，说简单点，就是支撑业务逻辑的功能模块。就是说，我们现在需要做的，是属于MODULES的这一块。

MVC ，最复杂，其实是M这一块，V 不用说， 很简单，其实就是业务流程，C  也很简单，是功能操作流程，M 怎么分， 如何对应前面的业务流程，很复杂。

“就是把业务逻辑和功能模块呈现的内容结合”什么意思？就是你写了一个MODUELS的名字出来，你要能够把业务逻辑里面的东西，和他关联起来。再说简单点，就是一对多，一就是MODULES，多就是业务逻辑，一个MODULES，对应于多个业务逻辑。

先做最上面的一层，尽可能多的进行一对多的分析，然后按照最小独立原则，看这个1，是不是一个最小的系统，按照GOOGLE的设计思想原理，每一个MODULES，都是一个可以独立运行的模块，也就是说，MODULES和MODULES之间是没关系的。

所以，后面的东西越来越复杂鸟。也就是说，你可能会画出ABCDEF 6个MODULES，对应前面的业务逻辑，但是去掉中间任意一个，比如只有ABCDF了，业务逻辑只是相对减少，而不会完全崩溃，这就是最小独立原则。

在思维导图中，其实是2个部分的结合
1. 业务逻辑
2. 功能模块

我们现在需要划分功能模块，依据3个原则：

1.      功能模块和业务逻辑之间的关系

2.      功能模块和功能模块之间还不能有关系

3.      功能模块还要尽可能的一对多（一个功能模块对应多个业务逻辑）

结合还有另外一层的意思,按照人，事来分, 人其实就是一个大模块, 事，就看里面有哪些事, 相同的事，就是一个模块, 人和事之间又会有关系，哪些是关系模块,

功能-业务逻辑导图如下：

3.基本功能模块关系

关系图内部，把对应关系找出来, 现在要做第3个图, 你看我们的步伐是，从业务—》进入功能, 按照人和事来分:

人,有哪些功能模块?

事,有哪些功能模块?

人和事之间的关系,又有哪些模块?

所有的互联网产品，无非就是人和事, 没有更多的东西了，注意：我们现在还不是在做API哦，我们只是在做功能模块哦，千万不要做到API这个层次上面去了，现在还没有到那一步。

事的划分标准，就是以业务逻辑来划分，但是你站在功能的角度来看，你又要把业务逻辑里面，相同的功能，抽象出来，形成功能模块，这样才能满足一对多啊。

事不能理解成用户的行为哦，事就是单纯的事，商家 就是事，他不是用户的行为哦，人就是指用户，事，就是指事物，人和事之间的关系，叫事件，事件是人和事之间的关系。

你 =  用户 = 人

星巴克 =  商家 = 事

不能主动发出请求的，归属于事，你去星巴克喝咖啡  = 事件= 人和事之间的关系，事是事物，不是事件，我给你发短信，你收到了短信是2个事件。

我是人

短信是事物

我发短信是事件

你是人

短信是事物

你接受短信是事件

这个拆分得不好，后面程序就一塌糊涂。

短信的那个事件很经典的，很多人不会拆的，看起来好简单的，不能主动发出请求的，归属于事。如果商家可以主动发出请求，那就是人，没其他的分法了，如果一个东西，具备主动性，他就人，就是用户。

做出的功能模块关系图如下：

4.功能模块接口uml（设计出api）

现在我们只考虑功能模块，做功能模块的UML图，但是只考虑到api的接口, 就是说，我们要设计哪些接口,去解决哪些问题。

接口是基于现在的模块，粗略的模块。

基于现在的模块设计接口，就是要提高耦合度，确保耦合正确。整理这些业务和功能模块，就是确保耦合正确。

耦合是一个很不好做的东西。耦合度太高，不能拆分。太低，又失去了模块化的意义。我其实是想先让你们自己设计一下，看看对照出来的是什么效果。主要困难，其实就是在耦合度的设计上。

         整理出功能模块接口的UML如下：

         上面的图就是所整理处理的api，把这些中文变成英文，就是熟悉的api。

5.编写在线api测试文档

我们网站的api在线测试文档，是使用既是一份在线api文档，也是一个在线测试工具，极大方便沟通和测试。每次客户端程序员觉得某个api有什么问题，我们就是这个在线工具上讨论沟通的。客户端程序员最喜欢这个玩意了^-^。

　　这个api在线测试文档，是使用了Swagger-UI搭建的。Swagger-UI简单而一目了然。它能够纯碎的基于html+javascript实现，只要稍微整合一下便能成为方便的API在线测试工具。项目的设计架构中一直提倡使用TDD（测试驱动）原则来开发，swagger-ui在这方面更是能提供很大帮助。

　　下面是用Swagger-UI搭建的api文档中的一个api的例子，可看到，整个api的提交方式，作用，参数都非常清晰明了。

6.在设计稿标注api

         api整理出来后，对于前端的开发人员来说，还有一个比较大的障碍，他们不知道app在哪个地方调用哪些api，为了方便前端人员，需要在设计稿上标注出哪个地方使用哪个api，如下图所示：

---------------------------------------------------------------------------------------------------------------------------

打开链接  app后端系列文章总目录 总目录 ，能查看本人发表过的所有原创“app后端”文章。