待评价列表预订单解耦后的逻辑
2017-01-06 16:20:00 0 举报
待评价列表预订单解耦后,逻辑变得更加清晰和灵活。首先,每个预订单的处理都独立于其他预订单,不再受到其他订单的影响。这使得系统能够更高效地处理大量的预订请求,提高了性能和响应速度。其次,解耦后的系统更容易进行扩展和维护。当需要添加新的功能或修改现有功能时,只需关注特定的预订单模块,而不需要对整个系统进行大规模的改动。此外,解耦还降低了系统的耦合度,减少了潜在的错误和故障风险。最后,解耦后的系统更易于测试和调试。开发人员可以针对单个预订单模块进行单元测试,确保其功能的正确性。总之,待评价列表预订单解耦后的逻辑使得系统更加可扩展、易维护、稳定可靠,并提高了开发效率。
作者其他创作
大纲/内容
N
UGC将“不可评价”给业务订单
修改后订单评价逻辑
1、待评价订单状态传到UGC和订单中心2、业务订单展示评价入口(业务本身无入口无需展示)
待评价订单状态传到订单中心
当前订单评价逻辑
1、业务订单将“评价完成”状态给订单中心2、业务关闭评价及修改评价入口
对于增加时间限制的
Y
1、UGC待评价信息消失2、订单中心展示订单状态
用户评价
用户是否评价
1、业务订单状态改为不可评价2、将“不可评价传给订单中心”
订单中心展示订单状态
订单消费后
订单中心待评价列表展示评价
1、业务将“不可评价”传给UGC和订单中心2、业务关闭评价入口
业务订单判断是否可评价
1、业务订单将“不可评价”状态给订单中心2、业务关闭评价入口
订单中心展示不可评价
UGC判断是否可评价
此处UGC是否需要定义接口,给各个业务订单?
UGC将“评价完成”传给业务订单
UGC待评价列表展示评价
1、订单状态保持待评价用户一直可以评价2、部分业务增加了评价时间限制
0 条评论
下一页