@Wahson
2019-05-07T01:25:11.000000Z
字数 2463
阅读 649
领域开发总结
1. 问题背景
1. 那些年踩过的坑
- 主档的坑
- 物流信息不存在导致无法订购
- 价格、税率维护不正确导致的坑
- 同一天同一城市的同一个商品发生变价，导致当天不同时间采购价格不一致
- 同一天寄库商品基本订购单位发生变化，导致订购时计算数量不一致，同时影响仓库拣货
- 上线初期主档价格税率问题经常变动，已产生未结账的订购单经常需要修数据
- 初期订购时价格取值逻辑含糊，主档，订购，财务，大数据取数口径不一致
- 9月初刷订购数据问题，价格、金额
- 主档接口问题，定义上的不规范，不严谨，进行了一次大调整，导致所有下游都需要调整
- 最大的坑在于出现问题数据的时候，出现一个解决一个，而不是迅速通过技术手段，全量检查问题，排查问题，批量修复。而且缺少措施检测数据，提前检查问题，缺少工具来辅助重复的修复工作。这一块上面浪费了很多人力物力。
业务的坑
- 业务不确定性，功能的反复调整，比如价格取值问题（调拨单，转移单），一直到上线一段时间后，才最终确定下来，导致一大堆历史数据需要修复
采购自身的坑
- 接口重复性严重
- 字段定义不统一，dao，dto，数据库同一字段定义类型，是否可选不一致，如状态字段dto定义的可选枚举，数据库定义为必填，在字段为空时以枚举默认值写入，导致写入与写出时值不一致。
- 上线新功能后，忽略了对历史数据的兼容处理（新版退货计划增加上报动作触发单据下发仓库，老版本的逻辑是到了退货计划过期后才推送，上线时刚好有生效中的退货计划，到时很多上线前提交的退货单没有推送仓库）
- 请求重复提交问题（添加购物车，门店验收）
- api不兼容问题导致灰度上线失败
- 重复的表结构设计，配送单和采购单一定程度上重复了，导致业务代码复杂性增加，查询接口复杂性增加
- 不变量处理不统一，比如叫货单中应 订购倍数 + 补丁倍数 + 审核倍数 = 总倍数，部分单据处理违背了这个关系，后面极有可能有栽坑
2. 事故回顾
- SQL删数据事故
- 叫货单单店当天重复问题
- 强配单重复导入问题
- 强配单重复生成问题
- 供应商平台数据过滤问题
- 频繁FullGC问题
- 多次死锁问题
- 叫货单提交定时器多线程导致的死锁
- 强配单提交定时器多线程导致的死锁
- 前端重复提交导致的死锁
- 供应商接单死锁
- kafka挂了，导致库存消息丢失问题
- 订购发版，多个关联平台没有同步更新
- 中台程序异常已回滚的寄库订单下发到了仓库
- eywa oom导致无法登陆
- 经由定时器抛出异常，导致没有下发单据，门店缺货
2. 重构-深入领域模型
2.1 业务的重新梳理
从单据模型、流程模型中升华：财务模型
(老模型，老流程复杂性图表说明，流程长且多，重复、不一致问题)
俗话说的好，没有一设计出来就是完美的模型。好的模型不一定是一开始就能够设计出来，是必须经历过，踩过坑，然后从坑里面爬出来的过程中，逐步形成经验总结，最终梳理出来相对满足实际业务需求。 -- 鲁迅
2018年，将近1年的时间里，采购的业务流程经过不断的上线、调整、上线、调整......已经基本打磨成型，下图基本已经涵盖了采购线90%（异常流程并没有在途中展现）的业务流程。
采购系统在Today中台的各个系统里应该是最复杂的，从上面的图可以对采购系统总结出2个词：多、长。采购系统包括了门店的进货、退货、转货，仓库的进货、退货和转货业务，门店进货和退货根据不同的配送方式还分成直纳、寄库、经由等进货方式，每个方式又包含下单、审核、接单、发货、收货等流程。不同的流程有相似的地方，又有各自特殊的处理。此外，图中也仅仅展示了正常的流程，加上异常流程，将会复杂得多。
- 外部依赖，上下游系统关系
- 上帝视角识别相同点
先看看老模型的状态图：
- 配送单状态
- 采购单状态
修正单状态
在我们老的模型里面，我们拆分了采购单和配送单，相应的它们有各自的单据流转。当初设计时考虑的时候一个单有多次配送的情况，但是后来实践证明，实际业务上并没有这种情况，属于过度设计了。而且这两个单据其实是有很多重合的地方。另外从采购单上看，状态待发货->待仓库验收->仓库验收，以及待发货->待门店验收->门店已验收在宏观上看是可以合并起来的：待发货->待验收->已验收。财务模型：数量，变化时间，价格，所有者
- 透过下游库存、盘点推移推动进一步落地，最终形成标准化的财务模型
- 业务不稳定，易变性案例说明， 新模型中是如何应对的
- 案例
- 裁决数量记录方式的多次调整
- 退货单库存扣减时机多次调整
- 总部退货单流程多次变更，先是有审核动作，后来取消了审核，过段时间又要求加上
- 门店叫货流程多次调整，由人为提交到自动提交，由一天多单变为一天一单
- 发货、验收流程调整，接入tms
- 案例
2.2 数据模型大一统
简化的数据模型
统一的状态机：原子化状态机
- 简单化的状态机
这里流程图我在原来的基础上做了一些简化，把一些相似的状态做了合并。说到这里，我们在识别系统状态的过程中，很容易会掉进一个陷阱：设定过多的相似的状态。比方说，在采购订单最初的状态里面，我们设定了有仓库关单、已关单2个状态，其实明眼人应该已经能够感觉到他们是非常相似的2个状态，但是为什么要这样设计呢？
两个主要原因：1. 逻辑处理方便，2. 查询显示方便。
似乎这样设计也无可厚非。但是，从设计的角度，状态集就杂了，增加了对外沟通解释的成本，另外考虑以后需求变化，增加了供应商关单的功能，那么整个模型是否意味着得增加一个状态，久而久之，状态越来越大。在我们的核心模型状态里面，我们希望是相对稳定的。 - 状态简化（状态细节）
2.3 原子方法
2.4 建立在原子方法之上的聚合方法
服务分层
- 领域层
- 业务规则层
