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


但是深究下去,会发现真正的原因,是软件架构上存在的问题:

微信支付软件架构重构之旅

文章插图
 
支付旧的架构采用了黑板模式,虽然方便了数据读写 。但是带来的问题和收益完全不成正比:
1.存在公共读写的数据类型 。
安卓传递的数据类型是一个字典,而 iOS 则是一个 Model 对象 。所有的界面,业务逻辑都共用一个数据 。
2.无序的数据流动 。
数据的流动是不可追溯的,数据的修改可以发生在任意使用公共数据的地方 。
那么支付跨平台软件架构,为了杜绝这样的问题 。我是这么做的:
微信支付软件架构重构之旅

文章插图
 
  1. 去掉公共读写的数据类型
  2. 传递值类型(Value Type)的数据, 后面流程修改数据时,不影响前面的流程 。
  3. 单向传递数据,只依赖注入必要数据 。
  4. 如果数据修改需要通知前序流程,使用代理模式通讯 。
规范数据传递后 。对比旧架构:
  1. 从架构上根本解决了困扰微信支付已久的数据污染的问题 。
  2. 数据的流动变为单向,数据流动变得可追溯 。
前面三步,我们抽象了业务流程,加入了路由机制,统一管理网络请求 。
微信支付软件架构重构之旅

文章插图
 
那么规范数据传递后,我们软件架构就演进为这样子 。
微信支付软件架构重构之旅

文章插图
 
总结软件的本质复杂性存在于复杂的业务需求中 。而软件架构的本质就是管理复杂性,因此真正的好的架构,正是在复杂的业务需求中反复提炼和总结归纳而来,解决了真正的业务问题,不是空谈 。
软件架构除了清理历史旧架构的缺陷,是我们业务开发的基石之外 。还能够赋能业务,为业务带来价值 。在建立软件架构的基础上,还围绕着软件架构建立起微信支付的跨平台自动化数据上报机制,防重复支付,安全横切等带来巨大业务收益的能力 。有机会的话,后面也会进一步编写相关文章和大家交流探讨 。
架构是一个不断演进的过程,随着新的支付业务基于跨平台软件架构的不断编写,我也会对这个架构进行持续的更新迭代 。让这个软件架构更贴合微信支付,更加健壮和完整 。




推荐阅读