随着需求的不断迭代，项目代码的复杂度也会越来越高，“屎山”也一天一天慢慢的堆积起来，对于游戏业务的账号订单流程也是如此。游戏订单类型由原来的俩种增加到了现在的七种，早就已经到了需要重构的地步。但是由于牵涉流程长、影响范围大、平时需求排期也比较紧张，所以便无法抽出大量的时间去进行重构。因为一开始就设计的不够规范、合理，所以之前整个账号订单流程存在以下主要问题： 1.1 核心代码分布散乱 除了按照原子层、服务层划分之外，还有一个服务用于接收订单mq进行大量的处理操作，订单相关的接口分布于多个类甚至是一些名称与订单毫不相关的类当中。 1.2 缺少设计模式 缺少设计模式，各种节点、不同订单类型的逻辑基本都是通过各种if-else进行处理，耦合度较高，可读性、可扩展性和可维护性都较差，甚至会出现修改一种订单流程反而影响到了其它订单流程的情况。 1.3 影响交付效率 代码分布在多个服务当中，开发一个相关需求时经常需要拉4、5个项目分支。由于容易修改到了其它订单模式的代码，所以在测试的时候往往又需要回归其它模式的订单流程是否有受影响。这些都大大影响了开发测试以及最终交付的效率。...
