微信支付软件架构重构之旅( 二 ) _微信支付

举个例子：一个普通的转账流程，可能会涉及风控拦截，实名验证，收银台，绑卡，支付成功页等等。如果是基于 MVC 这种架构的话，很快代码会变得难以维护。

文章插图

因此，为了适应微信支付流程多，界面跳转复杂的特点。架构抽象的第一步就是将业务流程抽象为一个独立的角色 UseCase 。同时, 把界面抽象为 UIPage 。一个大的业务流程可以分解为一个个小的业务流程。

文章插图

和刚才基于 MVC 混乱的架构相比：

业务流程的代码能够聚合到 UseCase 中，而不是分散到原来 iOS, 安卓的各个 ViewController，Activity 中。
业务流程和界面得到了复用。
契合微信支付多流程，界面跳转复杂的业务特点。

2. 加入路由机制既然流程得到了抽象，这个时候需要针对业务流程做更深的思考。在开发支付业务流程时，开发者不可绕过的问题有：
1、流程之间，页面之间的流传。

文章插图

比如我们要给一个朋友转账，输入金额，确认支付,触发 Cgi 后。下一个流程是多变的。有可能用户需要去实名，有可能用户要进入一个安全拦截的 WebView，或者是正常拉起收银台。

本文中的名词 CGI 可以理解为一个网络请求，类似HTTP请求。

那么以往在 iOS, 安卓分开实现时，都没有一个统一的处理机制。要么就是通过网络回包的某个字段来判断，要么就是本地维护一些状态来决定下一步走什么流程等等。非常繁琐，易错。
2、特殊流程的处理

文章插图

支付业务流程还有个特殊的地方，那就是在正常流程的中间，往往很多时候要需要插入一些特殊流程。比如有些地方要跳转 Webview, 有些地方要跳转小程序，有些地方要弹窗告知用户风险，或者终止当前流程，等等。我们经常需要在业务代码里面不断重复增加这样的处理。
这些问题，引导我想到，微信支付需要一个路由机制。
首先了解一下路由机制。

文章插图

路由机制的核心思想，就是通过向路由传递数据，然后路由解析数据，并响应。
结合微信支付和网络密切相关的特点。创新地将支付领域模型作为传递的数据。

文章插图

那么怎么建立这个支付领域模型的呢？
建模，就是建立映射。领域知识 + 建模方法 = 领域建模。那么这里的领域知识，就是对支付业务流程的理解。建模方法，我采用了 UML 建模。最终会落地为 Proto 协议供客户端和后台一起使用。

文章插图

首先，微信支付业务特点就是和网络密切相关，流程和页面往往是由 Cgi 串联起来。因此建立模型时，最外层便是网络回包。对于路由机制，这里我们只关心路由数据模型。
路由数据模型由路由类型，还有各个路由类型所需要的信息组合成。
路由类型清晰的定义了要触发的行为。究竟是要开启一个 UseCase，还是要打开一个界面，或者网页，小程序，弹窗等等。
然后就是这些行为所需要的数据。比如打开小程序所需要的参数，弹窗所需要的参数等。

文章插图

建立支付领域模型后，我们路由的解析就变得非常清晰了。路由解析之后，会根据路由类型，触发不同的动作。
比如流程，界面流转，会交给 UseCase 处理。
而特殊流程，比如打开小程序，打开 webview, 弹窗这些行为会统一进行处理。
我们在第一步把业务流程抽象为 UseCase 。第二步则加入了路由机制。
加入路由机制后，支付跨平台的软件架构演进为这个样子。