首页
登录 | 注册

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

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

行为流程角度:

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 不用枚举值,而应该用枚举类,枚举类维护值,接口内可见,是内部类.





2020 jeepxie.net webmaster#jeepxie.net
10 q. 0.008 s.
京ICP备10005923号