需求评审,让产品一步步讲,白板上画状态机流转.这样才能跟上思路. 目前只有prd, 衣服,细节,字段一大堆. 但是我们前期讨论流程(牵扯出实体关系)的时候根本就没有关注到具体细节字段,皮肤.
0. 产品先画流程图和基本状态action前置. (prd评审不需要说一堆的文档,外皮).
0.开发重点理出状态机+实体关系. (实体关系隐含在业务流程中,比如大单中的小单超时后,能否再发一单.) 业务状态流转状态机一定要明确
0.1 状态有大状态和小状态. ( 有时候需要考虑后台业务去考虑前台状态的流转. 不然后台查询非常的蛋疼,可能还要进行排序.)
0.2 前台产品关注的大状态不一定能满足后台产品的小状态.这个在实际设计状态值是需要统一考虑. 或者把前台库和后台库设计分开,后台同步数据时自己去归一某些值.
0. 测试要细化各种case,然后进行流程组合.
1. 明确产品需求和几个模块读取.
2. 整理用例图时要加上前置条件
3. 修改费用列表. 和乘客支付有一个并发控制. 之前在支付系统中设置一个支付中状态,一旦支付中就无法调账. 改成支付中且一段时间后未支付进行并发控制.抛弃cas锁.
直接调用order,发mq给支付系统.
4. 一笔订单付多次,需要进行并发控制.记录当前支付的pay和金额. 不对的走自动退款. 需要人力点击.
5. 一笔订单多次支付, 这个支付不仅仅是不同渠道的,是一次支付金额(相当于子交易). 这个流程多了一个实体,这个改变是非常大的. 这个需求埋的很深,第一次还车单要失败后,第一次发单.
用例图就不用多说了,用例说明的一个例子:
用例名称 | daijia_user_xxx |
---|---|
简单描述 | 简要介绍该用例的作用和目的 |
参与者/触发者 | 说明主要执行者和辅助执行者。 |
前置条件 |
执行用例之前系统/执行者必须所处的状态。 |
流程/流程图 |
主流程: 次要流程: |
后置条件 | 用例执行完毕后系统可能处于的一组状态。 |
其他说明 |
领域.
1.订单分成三张表.
发单表,接单result表,.. 按流程分开.
支付领域.
1. 不要用共用表的原则,非核心表采用 extend扩展关链表.
2. 各个业务各自的表.不要揉和到一起,即时很像. (类似业务上的分表,hibernate里面的各种组合关系)
3. 父子帐户不要放置在一张表上.
帐户表都需要要有userId 和type, applicationId. 这样便于一个对象实体的所有帐户在一起.