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后端”文章。
【作者】曾健生
【QQ】190678908
【app后端qq群】254659220
【微信公众号】 appbackend
【新浪微博】 @newjueqi
【博客】http://blog.csdn.net/newjueqi
版权声明:本文为博主原创文章,未经博主允许不得转载。