一.需求场景
1.需求: 公司客户希望通过预算配置进行下单时的预算管控
2.场景: 客户公司的员工购买我司产品时, 下单是否被允许取决于配置
3.配置颗粒度
(1)时间范围
(2)维度: 部门 职级
(3)产品线
4.举个例子, 假设我公司有(A, B, C)三条产品线, 每条产品线售卖两种产品
A: a1 a2 B: b1 b2 C: c1 c2
| 公司 | 时间范围 | 维度 | 产品(集合) | 产品总预算 |
|---|---|---|---|---|
| 阿里巴巴 | 2022.01-2022.02 | 部门(淘宝bu) | a1, b1 | 1000W |
翻译: 阿里巴巴集团的淘宝bu的所有员工在2022.01-2022.02期间订购我司的
a1, b1产品共享预算是1000W, 若预算用光了, 该部门下单时会进行拦截
二.难点(父子部门预算校验)
2.1 流程如下:
image.png
(1)补充一点: 虽然说理论上配置时不会存在父 >= 子, 即使存在了, 在进行支付时, 可能匹配到多条符合规则的预算配置, anyone其中一个预算配置预算不足, 也会拦截, 这是个兜底方案
(2)当新增配置时, 为保证库表数据的整洁度, 合理性, 需要校验父部门的预算 >= 子部门的预算
2.2 核心
构造N叉树
(1)校验接口获取orgList是否合法, root只有一个
(2)自顶向下构造N叉树
寻找直属父节点 + 所有子节点
(1)递归 + 前序遍历 参考: 力扣
(2)递归防止死循环兜底:
--理论上接口返回的节点数据不会变成图, 也就是叶子节点不会指向根节点
--如果发生了, 那么就死循环了!!!为了CPU被打爆, 最坏情况下一个父部门只有一个子部门, 则相当于树 -> 链表, 那么递归深度maxDeep = orgList.size(), 我们必须跳出递归
