快的时代写的
思考一个业务系统,物,行为都可以设计 为实体。最重要的是从人角度出发,
行为流程角度:
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 不用枚举值,而应该用枚举类,枚举类维护值,接口内可见,是内部类.