@(工作) ####介绍 接上篇，上次重构后的设计是，按业务划分，通过交易模式和游戏类别来生成相关的交易业务Service，将相同的业务方法写到抽象父类的方法中，抽象父类对外只暴露业务接口方法，这样保证了业务入口的一致性，防止业务方法被部分调用的错误。不同游戏、不同模式的业务方法写到相关的子类中，保证业务方法的特殊性。
但是由于需要接入营销平台SP系统，SP系统又有各种各样的业务、活动，对交易业务逻辑要求不尽相同，上次重构后的系统要想满足SP系统的多态化交易模式，必须为每个业务处理重新写一整套交易流程，包括下单、支付、发货等，这样会使工作量大增，而且不好维护，同时在工厂中新增一遍实现类，感觉不是很灵活。上周根据这种需求又重新设计了一下交易系统设计。
交易系统还是按业务Business来划分（下单、支付、发货、打款等），但是将原来的业务实现拆分成多个“原子方法”Action，每个Action下可以包含多个子Action；单个业务的实现是将“原子方法”Action进行排序组合，相同业务但不同处理就可以选择不同的Action和组合方式；当新增一种业务处理时，只是新增Action，同时可复用原来的Action，大大减少了代码量，并且增加了灵活性。目前这些Business和Action都是可配置的，可根据业务进行不同配置。 如下图
