业务系统中最核心的状态设计,异常 case. (系统设计)

系统设计几方面

1. 具象: 几个角色 -- 用例

2. 具象: 边界模块

3. 具象: 实体模块

4. 抽象: 详细设计后,抽出公用的部分.

5.

Status状态字段的设置和更改

系统设计中最核心的是异常设计.

如何?

有哪些异常

1. 通信失败

2. 实体失败

方法论:

1. 确定一个实体生命周的实体交互图. (可以是实体交互图,也可以是时序图) 先抛弃状态检查等.

2. 确定每个流程中的异常问题.

3. 区分. 明确状态 和 中间状态[不明确状态,例如超时状态][  开锁中, 支付中 ,超时状态] 本质上其实并不需要. 可以查看支付失败的原因,开锁失败的原因.

4. 并发问题. 乘客结束订单,司机抢单成功. 加分布式锁.

5. 保护权衡(分布式事务,抽象总结): 1. 保护资产. ( 先减款,再退钱 ) 2. 保护资产: 等开锁消息回来再结束计费 3. 保护乘客:

举例说明.

评审: 说服别人要明确举出工作中的缺点, 不要直说原则. 业务域就放业务域.   例如业务域不明确,增加一项,或者改变某个逻辑,大家都要改. cos 组合服务太重,

状态设计的需求来源:

1. 业务流程.

参考流程引擎的各种流程 . 垫付的流程更复杂,  1.支付 2.垫付  不仅独立而且共存. 但都会触发 分润. [         各个主体的认知梳理. 乘客,司机 (单流程 key value),客服,财务统计. 各个统计需求真的关注的到底是什么? 原状态流程不变,那么司机要重新对原 status 字段的判断要改. 司机也要改. ]

2. 后台查询诉求

1. 可能全局系统(n 个子系统)的状态, 全流程. 方便 crm 同学查询. 2.将内部系统的 n 个状态聚合成一个状态.  ( 已分润也算已支付.)

3. 统计诉求

对状态进行聚合统计. 新增状态要同步. 状态字典 加上 监控 ,对新增的状态进行监控.

代码级别就只能 review 了? 状态转换表. 不同业务场景下.

新增的 type,status 如何保证业务系统健全.

状态设计是误区.一定要是状态机设计. 相同状态但流程不同. 状态机是实体和流程的统一.

一定要前置状态校验和其他条件校验.

异常考虑: 另外要关注自动流转的状态,要警惕丢失掉对应的流转流程. (例子,代保养中 大单结束)

几种状态设计.

顺序流程:

1.  单系统 一个字段表征 N 个状态( 含 手动,含自动)

2. 分布式系统. 每个系统各一个字段.对应着生命周期扩展表.

顺序流程:

多个主体操作.

例子. 1. 发单, 乘客取消, 多个司机抢单. 2.tcp 状态机 关闭流程.  ack 的和 action 可能组合,

复杂流程:

N 个流程,独立. 有一个成功即走下去.

N 个流程,x 个都成功才能走下去.

N 个流程 x 个成功就能走下去, 但是不妨碍剩下的action 执行.

action 变成了实体, 不再是依附于状态节点. 或者是一个字段来表征也可以.

1. 每个实体都需要有状态

2. 当两个实体不是同时存在的时候,即使1:1也无法用下游实体代替上游实体的状态;

例如 订单行 ad 1:1 先有订单行 后有ad ;

如果只是把 订单行的状态设置在ad上; 那么你无法获取订单行是初始状态的情况( 订单行 left join ad 后 ad.status=null 或者 ad.status=Init 两种情况,这种很难考虑到)

3. 上游的状态是根据上游状态计算出来的,

一个计算技巧就是,当所有下有状态是Audited, 那么上游的Ad是什么状态,利用这个, 再根据 if else的逐位分析法,逐步判断;;

wiz上有详细.

1. status一定要有状态机更改

2. status状态的意义是屏蔽掉复杂业务.

比如说分润状态流转.有些是有三条流水,有些是有四条流水.