用户
移动加权平均已计算
释放业务锁
根据单据查relate信息，接着可以知道mapping信息，就知道stockids
固定的查询条件
校验：重复性，可用库存数目
应对变化的方案选择也是难点，应对变化的常见方案有两种，第一种是将“变化”封装在一个“变化层”，将不变的部分封装在一个独立的“稳定层”。第二种方案是提炼出一个“抽象层”和一个“实现层”。
反思：领域事件没有任何影响，那还叫领域事件吗？库存模块究竟是业务复杂还是技术复杂？
解锁规则
盘点锁相关信息
查询被锁住的库存信息
没有事件
找到relate信息；根据relate中的lockIdKey，根据lockIdKey找到锁信息，以及mapping信息；然后减去释放数目
业务锁已创建
根据粒度聚合
流水已创建
调整商品分类
单据及关联单据信息
根据库存信息释放业务锁
根据单据+库存UnionKey信息
判断是否可以移库
同一个单子：RelateId/RelateItemId
新建库存
粒度规则
释放盘点锁
可用库存数目=在库数目-被业务锁锁住的数目+自己单子锁住的数目
查询可用库存数目
读取库存的规则：FIFO/FILO
查询库存分页列表
影响
库存已创建
库存单据信息
库存信息以及释放信息
规则太复杂，但是死的吧
计算规则
业务锁已释放
依赖
出入库流水单据信息
不考虑锁？就能移动？
商品分类已更新
通过查询库存内数量是否满足参数传入的数目
新建盘点锁
盘点锁已释放
执行库存统计
根据粒度加锁
需要更新的商品分类信息
同一shipperId同一个单子，同一货物，同一类型
盘点锁已创建
关联单据信息
货物粒度，对应特殊的返回值；批次粒度，对应特殊的返回值；编码粒度；支持特殊的聚合方式
检验：重复性
新建出入库流水
读取后新增/更新
业务锁相关信息
新建业务锁
