整合⼩程序的WebAPI接⼝层的架构设计
在我前⾯有很多篇随笔介绍了Web API 接⼝层的架构设计，以及对、企业号、⼩程序等模块的分类划分。例如在《》介绍了相关模块的划分，在《》介绍了Web API的架构设计思路。本篇随笔对之前介绍的架构内容进⾏统⼀的调整更新，以便更加⽅便实际项⽬的应⽤开发，以期达到统⼀、重⽤、清晰的⽬的。
1、、企业号、⼩程序模块的划分
我们知道，⽬前企业应⽤，分为、企业号（企业）、⼩程序三种应⽤模式，对于常规的开发来说，我们对每个模式的应⽤都分为了两个不同的部分，⼀个是和业务数据相关的数据管理、⼀个是和API接⼝相关的API管理，两者整合为⼀个完整的应⽤。
、企业号（企业）、⼩程序三种应⽤模式的模块划分如下图所⽰。
业务数据管理模块，⼀般还需要调⽤API接⼝进⾏相关的处理操作，因此他们之间的项⽬引⽤关系如下所⽰
另外，这三种类型的API接⼝也公⽤了⼀些业务对象和实体类，因此把它们抽取出来作为公共项⽬模块，如这三类接⼝项⽬统⼀使⽤了⼀个公共实体类项⽬。
除了这些之外，我们做项⽬，⼀般还涉及到⼀些基础功能模块，如公⽤类库，以及附件管理、通讯录管理、权限管理模块等内容，我们可以把后者⼏个模块放在⼀起，组成基础模块。
企业号申请
2、基于的Web API 架构设计
随着基于JSON格式的Web API的⼴泛应⽤，越来越多的企业采⽤Web API接⼝服务层，作为统⼀接⼝的核⼼所在，也成为Web API核⼼层。基于JSON格式的接⼝，可以⼴泛地、跨平台的应⽤于IOS、安卓等移动端，也可以应⽤在常规的Web业务系统，Winform业务系统、应⽤、⼩程序等⽅⽅⾯⾯，因此企业内部形成⾃⼰是的⼀套Web API标准和详细的⽂档⾮常重要，⼀旦完善了，就可以供各个业务
场景使⽤，这些业务可以外包给其他软件公司或者团队，各⾃分离开发，⽽⾃⼰内部则只需要花费精⼒来统⼀维护Web API核⼼层和提⾼整个核⼼层的功能接⼝稳定、缓存处理等⽅⾯事情即可。其他业务团队开发的系统只需要遵循整个⼤接⼝平台的统⼀规划，完成各⾃的功能需求即可，不会造成数据库的不⼀致，更不会让某家公司掌握核⼼的技术资源，尾⼤不掉的尴尬情形。
基于上⾯的分析，我们企业最终围绕着Web API核⼼层做了不同的业务应⽤，如下图所⽰。
再进⼀步详细各个模块的分层，我们可以细化为下⾯的架构设计图，所有模块均围绕着Web API 接⼝层进⾏扩展，底层的数据存储对上层的应⽤是完全透明，我们可以根据需要拆分各种业务数据库，以及使⽤我们认为合适的数据库。
其中我们在Web API接⼝层上还看到⼀个消息交互的模块，这个模块我们为了⽅便域名端⼝的处理，和Web API 是统⼀放在⼀起的，它负责和腾讯服务器进⾏消息的交互处理，从⽽实现各种消息推送处理。
的服务器架起了客户⼿机和开发者服务器的⼀个桥梁，通过消息的传递和响应，实现了与⽤户的交互操作，下⾯是它的消息流程图。通过对这⼏类业务应⽤的模块分析，我们就可以建⽴相关的项⽬了，来分别对这些数据和API进⾏管理，如我们根据这些分类，在Visual Studio的项⽬管理中看到的项⽬如下所⽰。
其中由于我们这⾥的Web API 是⼀个统⼀的出⼝，因此会整合很多Web API控制器，以提供所有业务的接⼝，因此对Web API 控制器的管理就显得很重要，这⾥建议引⼊Area区域进⾏管理控制器类，这种各个模块就能够很好分门别类的进⾏管理了。
如下图所⽰是我们的Web API项⽬的控制器Area区域分类，把、企业号、⼩程序、基础框架、第三⽅接⼝、CRM等内容进⾏不同的划分。