文档介绍：Mini版银行交易系统设计模式揭秘
大家可能对银行的交易系统充满敬畏之情,一听说是银行的IT人员,立马想当然地认为这是个很厉害的人物,那我们今天就来对银行的交易系统做一个初步探讨。国内一家大型集团(全球500强之一)计划建立全国“一卡通”计划,每个员工配备一张IC卡,该卡基本上就是万能的,门禁系统用它,办公系统使用它作为认证,你想打开自己的邮箱,没有它就甭想了,它还可以用来进行消费,比如到食堂吃饭,到园区内的商店消费等等,甚至洗澡、理发、借书、买书等等都可以用它,只要这张卡内有余额,在集团内部就是一张借记卡(当然还有一些内部的补助通过该卡发放,合理避税嘛)。我们要讲解的就是“一卡通”项目联机交易子系统, 类似于银行的交易系统,可以说它是交易系统的mini版吧。
该项目还是具有一定的挑战性,集团公司的架构分为三层:总部、省级分部、市级机构,业务要求是“一卡通”推广到全国,一名员工从北京出差到了上海,凭一卡通他能在北京做的事情在上海同样能完成。对于联机交易子项目,异地分支机构与总部之间的通信采用了MQ(Message Queue,消息队列)传递消息,也就是我们观察者模式的BOSS版,与目前的通过POS机刷信用卡基本上是一个道理。
联机交易子系统有一个非常重要的子模块(Module)——扣款子模块。这个模块太重要了!从业务上来说,扣款失败就代表着所有的商业交易关闭,这是不允许发生的;从技术上来说,扣款的异常处理、事务处理、鲁棒性都是不容忽视的,特别是饭点时间,并发量是很恐怖的,这对我们架构师提出了很高的要求。
我们详细分析一下扣款子模块,每个员工都有一张IC卡,他的IC卡上有以下两种金额。

固定金额是指员工不能提现的金额,即使你的固定金额有10万元,你也只能干瞪眼看着,不能提取现金,那这部分金额有来做什么呢?只能用来特定消费,什么特定消费?员工日常必需的消费,例如食堂内吃饭、理发、健身等活动。
,
自由金额是可以提现的,当然也可以用于消费。每个月初,总部都会为每个员工的IC卡中打入固定数量的金额,然后提倡大家在集团内的商店消费。
在实际的系统开发中,架构设计的是一张IC卡绑定两个账户:固定账户和自由账号,本书为了简化描述还是使用固定金额和自由金额。既然有消费,系统肯定要扣款处理,系统内有两套扣款规则。

该类型的扣款会对IC卡上的两个金额都会产生影响,计算公式如下:
IC卡固定余额= IC卡现有固定余额–交易金额/ 2
IC卡自由余额= IC卡现有自由金额- 交易金额/ 2
也就是说,该类型的的消费分别在固定金额和自由金额上各扣除一半。它适用于什么消费场景呢?固定消费场景,例如吃饭、理发等情况下的扣款,为什么要这么做呢?为了防止乱请客的情况,你请别人吃饭,好,你自己也要出一半,你乐意呀。

全部从自由金额的上扣除,由于集团内的各种消费、服务非常齐全,而且比市面价格稍低,员工还是很乐意到这里消费的,而且很多员工本身就住在集团附近,基本上就是“公司即家,家即公司”。
今天要讲的重点就是这两种消费的扣款策略,该怎么设计?先想清楚了再回答,你要知道这种联机交易,日后允许你大规模变更的可能性基本上是零,所以系统设计的时候要做到可拆卸(Pluggable)的架构,避免日后维护的大量开支。
很明显,这是一个策略模式的实际应用,但是你还记得策略模式是有缺陷的吗?它的具体策略必须暴露出去,而且还要由上层模块初始化,这不合适,与迪米特原则有冲突,高层次模块对低层次的模块应该仅仅处在“接触”的层次上,而不应该是“耦合”的关系,否则,维护的工作量就会非常大。问题提出了,那我们就应该想办法来修改这个缺陷,正好工厂方法模式可以帮我们产生指定的对象,但是问题又来了,工厂方法模式要指定一个类,它才能产生对象,怎么办?引入一个配置文件进行映射,避免系统僵化情况的发生,我们以枚举类完成该任务。
还有一个问题,一个交易的扣款模式是固定的,根据其交易编号而定,那我们怎么把交易编号与扣款策略对应起来呢?采用状态模式或责任链模式都可以,如果采用状态则认为交易编号就是一个交易对象的状态,对于一笔确定的交易(一个已经生成了的对象),它的状态不会发生从一个状态过渡到另一个状态的情况,也就是说它的状态只有一个,执行完毕后即结束,不存在多状态的问题;如果采用责任链模式,则可以以交易编码作为链中的判断依据,由每个执行节点进行判断,返回相应的扣款模式。但是在实际中,采用了关系型数据库存储扣款规则与交易编码的对应关系,为了简化该部分的讲义,我们在下面的设计中使用了条件判断语句来代替。
还有,我们分析了这么多,这么复杂的扣款模块总要进行一个封装吧,你不能让上层的业务