一.需求場(chǎng)景
1.需求: 公司客戶(hù)希望通過(guò)預(yù)算配置進(jìn)行下單時(shí)的預(yù)算管控
2.場(chǎng)景: 客戶(hù)公司的員工購(gòu)買(mǎi)我司產(chǎn)品時(shí), 下單是否被允許取決于配置
3.配置顆粒度
(1)時(shí)間范圍
(2)維度: 部門(mén) 職級(jí)
(3)產(chǎn)品線(xiàn)
4.舉個(gè)例子, 假設(shè)我公司有(A, B, C)三條產(chǎn)品線(xiàn), 每條產(chǎn)品線(xiàn)售賣(mài)兩種產(chǎn)品
A: a1 a2 B: b1 b2 C: c1 c2
| 公司 | 時(shí)間范圍 | 維度 | 產(chǎn)品(集合) | 產(chǎn)品總預(yù)算 |
|---|---|---|---|---|
| 阿里巴巴 | 2022.01-2022.02 | 部門(mén)(淘寶bu) | a1, b1 | 1000W |
翻譯: 阿里巴巴集團(tuán)的淘寶bu的所有員工在2022.01-2022.02期間訂購(gòu)我司的
a1, b1產(chǎn)品共享預(yù)算是1000W, 若預(yù)算用光了, 該部門(mén)下單時(shí)會(huì)進(jìn)行攔截
二.難點(diǎn)(父子部門(mén)預(yù)算校驗(yàn))
2.1 流程如下:
(1)補(bǔ)充一點(diǎn): 雖然說(shuō)理論上配置時(shí)不會(huì)存在父 >= 子, 即使存在了, 在進(jìn)行支付時(shí), 可能匹配到多條符合規(guī)則的預(yù)算配置, anyone其中一個(gè)預(yù)算配置預(yù)算不足, 也會(huì)攔截, 這是個(gè)兜底方案
(2)當(dāng)新增配置時(shí), 為保證庫(kù)表數(shù)據(jù)的整潔度, 合理性, 需要校驗(yàn)父部門(mén)的預(yù)算 >= 子部門(mén)的預(yù)算
2.2 核心
構(gòu)造N叉樹(shù)
(1)校驗(yàn)接口獲取orgList是否合法, root只有一個(gè)
(2)自頂向下構(gòu)造N叉樹(shù)
尋找直屬父節(jié)點(diǎn) + 所有子節(jié)點(diǎn)
(1)遞歸 + 前序遍歷 參考: 力扣
(2)遞歸防止死循環(huán)兜底:
--理論上接口返回的節(jié)點(diǎn)數(shù)據(jù)不會(huì)變成圖, 也就是葉子節(jié)點(diǎn)不會(huì)指向根節(jié)點(diǎn)
--如果發(fā)生了, 那么就死循環(huán)了!!!為了CPU被打爆, 最壞情況下一個(gè)父部門(mén)只有一個(gè)子部門(mén), 則相當(dāng)于樹(shù) -> 鏈表, 那么遞歸深度maxDeep = orgList.size(), 我們必須跳出遞歸
