在我前面有很多篇随笔介绍了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等内容进行不同的划分。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。