重构，可扩展设计可操作方案。

快的时代写的

思考一个业务系统，物，行为都可以设计 为实体。最重要的是从人角度出发，

行为流程角度：

1. 流程

2.不同类型同一个流程点

实现：不同类型就是不同的策略，可能输入的参数都不同。通过接口来规范。 通过filed来接受属性。避免了context类的出现

每次执行时 new 对象，赋值参数，然后 execute。

数据库实体关系角度：

   1. 要尽量的抽象，不要把上层，前面业务id放入到下游。如果表进行了组合，切记使用外键id关联，查找也要通过这个，切不可用unique去限制，也可以限制，日后可放开。

例如：订单id支付记录上，另外tradeId和orderId不要设置1对1关系。

           有些支付并不是针对orderId的。

    实体表要尽量组合。 例如pay，可以和order对应的表组合成给pay支付的。可以降低上层开发量。

    如果只需要主表数据，hibernate自动帮你路由到对应表。对上层业务来说更通用了。不然新增加一个业务就要新增加DO，DAO，这个会降低业务可扩展性。

    表组合有利于业务下层 ，但会增加查询次数。

 2。实体关系如果一定要unique，那么最好是泛华的，不要具体业务。 

层级和 类型:

    1. 底层的类型肯定更少,比如 (支付,退款,xxx . 然后才是渠道,子渠道.)

    一个支付对应着上层的N 个 业务Type .提供查询接口, trans_id + bizType. 更好的方法是. 将 biz_type 和 trans_id 捆绑上.

    这样直接存储,查询也更方便.

    对应业务也知道给支付的流水号是啥.

   2.     bizType 不用枚举值,而应该用枚举类,枚举类维护值,接口内可见,是内部类.