大家可能对银行的交易系统充满敬畏之情，一听说是银行的IT人员，立马想当然地认为这是个很厉害的人物，那我们今天就来对银行的交易系统做一个初步探讨。国内一家大型集团（全球500强之一）计划建立全国一卡通计划，每个员工配备一张IC卡，该卡基本上就是万能的，门禁系统用它，办公系统使用它作为认证，你想打开自己的邮箱，没有它就甭想了,它还可以用来进行消费，比如到食堂吃饭，到园区内的商店消费等等，甚至洗澡、理发、借书、买书等等都可以用它，只要这张卡内有余额，在集团内部就是一张借记卡（当然还有一些内部的补助通过该卡发放，合理避税嘛）。我们要讲解的就是一卡通项目联机交易子系统, 类似于银行的交易系统，可以说它是交易系统的mini版吧。

该项目还是具有一定的挑战性，集团公司的架构分为三层：总部、省级分部、市级机构，业务要求是一卡通推广到全国，一名员工从北京出差到了上海，凭一卡通他能在北京做的事情在上海同样能完成。对于联机交易子项目，异地分支机构与总部之间的通信采用了MQ（Message Queue，消息队列）传递消息，也就是我们观察者模式的BOSS版，与目前的通过POS机刷信用卡基本上是一个道理。

联机交易子系统有一个非常重要的子模块（Module）——扣款子模块。这个模块太重要了!从业务上来说，扣款失败就代表着所有的商业交易关闭，这是不允许发生的；从技术上来说，扣款的异常处理、事务处理、鲁棒性都是不容忽视的，特别是饭点时间，并发量是很恐怖的，这对我们架构师提出了很高的要求。

我们详细分析一下扣款子模块，每个员工都有一张IC卡，他的IC卡上有以下两种金额。

　　1.固定金额

固定金额是指员工不能提现的金额，即使你的固定金额有10万元，你也只能干瞪眼看着，不能提取现金，那这部分金额有来做什么呢？只能用来特定消费，什么特定消费？员工日常必需的消费，例如食堂内吃饭、理发、健身等活动。

2.自由金额

自由金额是可以提现的，当然也可以用于消费。每个月初，总部都会为每个员工的IC卡中打入固定数量的金额，然后提倡大家在集团内的商店消费。

在实际的系统开发中，架构设计的是一张IC卡绑定两个账户：固定账户和自由账号，本书为了简化描述还是使用固定金额和自由金额。既然有消费，系统肯定要扣款处理，系统内有两套扣款规则。

1.扣款策略一

该类型的扣款会对IC卡上的两个金额都会产生影响，计算公式如下：

IC卡固定余额 = IC卡现有固定余额 – 交易金额 / 2

IC卡自由余额 = IC卡现有自由金额 - 交易金额 / 2

也就是说，该类型的的消费分别在固定金额和自由金额上各扣除一半。它适用于什么消费场景呢？固定消费场景，例如吃饭、理发等情况下的扣款，为什么要这么做呢？为了防止乱请客的情况，你请别人吃饭，好，你自己也要出一半，你乐意呀。

2.扣款策略二

全部从自由金额的上扣除，由于集团内的各种消费、服务非常齐全，而且比市面价格稍低，员工还是很乐意到这里消费的，而且很多员工本身就住在集团附近，基本上就是公司即家，家即公司。

今天要讲的重点就是这两种消费的扣款策略，该怎么设计？先想清楚了再回答，你要知道这种联机交易，日后允许你大规模变更的可能性基本上是零，所以系统设计的时候要做到可拆卸（Pluggable）的架构，避免日后维护的大量开支。

很明显，这是一个策略模式的实际应用，但是你还记得策略模式是有缺陷的吗？它的具体策略必须暴露出去，而且还要由上层模块初始化，这不合适，与迪米特原则有冲突，高层次模块对低层次的模块应该仅仅处在接触的层次上，而不应该是耦合的关系，否则，维护的工作量就会非常大。问题提出了，那我们就应该想办法来修改这个缺陷，正好工厂方法模式可以帮我们产生指定的对象，但是问题又来了，工厂方法模式要指定一个类，它才能产生对象，怎么办？引入一个配置文件进行映射，避免系统僵化情况的发生，我们以枚举类完成该任务。

还有一个问题，一个交易的扣款模式是固定的，根据其交易编号而定，那我们怎么把交易编号与扣款策略对应起来呢？采用状态模式或责任链模式都可以，如果采用状态则认为交易编号就是一个交易对象的状态，对于一笔确定的交易（一个已经生成了的对象），它的状态不会发生从一个状态过渡到另一个状态的情况，也就是说它的状态只有一个，执行完毕后即结束，不存在多状态的问题；如果采用责任链模式，则可以以交易编码作为链中的判断依据，由每个执行节点进行判断，返回相应的扣款模式。但是在实际中，采用了关系型数据库存储扣款规则与交易编码的对应关系，为了简化该部分的讲义，我们在下面的设计中使用了条件判断语句来代替。

还有，我们分析了这么多，这么复杂的扣款模块总要进行一个封装吧，你不能让上层的业务模块直接深入到我们模块的内部吧，于是门面模式又摆在了眼前。

分析完毕，我们要先画出类图，挑柿子就选软的捏，那我们做设计也遵循一下这个原则，先选最简单的业务，然后画出类图，那我们先定义交易中使用到的两个类:IC卡类和交易类。

每个IC卡有三个属性，分别是IC卡号码、固定金额、自由金额，然后通过getter/setter方法来访问。

细心的读者可能注意到，你的金额怎么都是整数类型呀，这不对呀，应该是double类型或者BigDecimal类型呀。是，一般非银行的交易系统，比如超市的收银系统，系统内都是存放的int整数类型，在显示的时候才转换为货币类型。

交易信息Trade类，负责记录每一笔交易，它是由监听程序监听MQ队列而产生的，有两个属性：交易编号和交易金额，其中的交易编号对整个交易非常重要，18位字符（在银行的交易系统中，这里可不是字符串，一般是十进制数组或二进制数字，要考虑系统的性能，数字运算可比字符运算快得多），包括POS机编号、商户编号、校验码等等，我们这里暂时用不到，就不多做介绍，我们只要知道它是一个非常有用的编码就成。交易金额为整数类型，实际金额放大100倍即可。

我们回顾一下，我们在该案例中使用了几个模式：

　　1.策略模式

负责对扣款策略进行封装，保证两个策略是可以自由切换的，而且日后增加扣款策略也是非常简单容易的。

2. 工厂方法模式

修正策略模式必须对外暴露具体策略的问题，由工厂方法模式直接产生一个具体策略对象，而其他模块则不需要依赖具体的策略。

　　3.门面模式

负责对复杂的扣款系统进行封装，封装的结果就是避免高层模块深入子系统内部，同时提供系统的高内聚、低耦合的特性。

我们主要使用了这三个模式，好处是什么呢？灵活，稳定，我们可以设想一下，可能有哪些业务变化？

　　4.扣款策略变更

这个没问题，增加一个新扣款策略，三步就可以完成：实现IDeduction接口，增加StrategyMan配置项，扩展扣款策略的利用（也就是门面模式的的getDeductionType方法，在实际的项目中这里只需要增加数据库的配置项），那减少一个策略呢？简单，修改扣款策略的利用，那变更一个扣款策略呢？也简单，扩展一个实现类口可以了。

5.变更扣款策略的利用规则

也简单，我们的系统不想大修改，还记得我们提出的状态模式吗？这个就是为策略的利用服务的，变更它就能满足你的要求，想把IC卡也纳入策略利用的规则，也简单，不复杂。其实这个变更还真发生了，系统投产后，业务提出考虑退休人员的情况，退休人员的IC卡与普通在职员工一样，但是它的扣款不仅仅是根据交易编码，还要根据IC卡对象，系统的变更做法是增加一个扣款策略，同时扩展扣款利用策略，也就是数据库的配置项，在getDeductionType中新扩展了一个功能：根据IC卡号，确认是否是退休人员，是退休人员，则使用新的扣款策略，非常简单的扩展。

这就是一个mini版的金融交易系统，没啥复杂的，剩下的问题就开始考虑系统的鲁棒性吧，这才是难点。在项目中快乐路径是最容易实现的，一旦融入悲伤路径，系统的复杂性就大大提高，所以呀，才有需求分析时要先要描述一个成功场景，然后再一步一步地增加扩展场景的迭代分析模式，否则一上来就考虑一堆的扩展场景，这会让你思维混乱、手足无措，直接进入郁闷假死状态。