1. 為什么我會(huì)把一個(gè)訂單系統(tǒng)推翻重做舊模型的兩個(gè)死穴前一陣我把一個(gè)后臺(tái)系統(tǒng)的訂單模塊整個(gè)推倒重來(lái)了。原因不是業(yè)務(wù)代碼寫(xiě)得亂而是數(shù)據(jù)模型根本撐不住對(duì)賬和審計(jì)。那套舊方案很常見(jiàn)訂單表一行數(shù)據(jù)上面掛一個(gè)狀態(tài)字段從“待支付”到“已支付”再到“已發(fā)貨”狀態(tài)一變更新一下字段前端的進(jìn)度條跟著走。表面看沒(méi)問(wèn)題可一旦出現(xiàn)部分退款、贈(zèng)品抵扣、壞賬核銷、換貨這行訂單記錄就變成了一堆狀態(tài)來(lái)回橫跳的怪胎。真正壓垮我的場(chǎng)景是這樣的某個(gè)客戶有一筆訂單系統(tǒng)里顯示“已關(guān)閉”財(cái)務(wù)卻堅(jiān)持說(shuō)這筆錢已經(jīng)收到了。兩邊打開(kāi)后臺(tái)一對(duì)訂單狀態(tài)是關(guān)閉但支付流水表里確實(shí)有一筆入賬記錄。這個(gè)“已關(guān)閉”到底是誰(shuí)關(guān)的關(guān)閉之前發(fā)生過(guò)什么當(dāng)時(shí)庫(kù)里的余額為什么和銀行流水對(duì)不上沒(méi)人能從一個(gè)狀態(tài)字段里找出答案只能去翻日志、查操作記錄一個(gè)晚上就這么沒(méi)了。1.1 狀態(tài)字段越長(zhǎng)業(yè)務(wù)真相越模糊狀態(tài)字段本身不是一個(gè)錯(cuò)誤它的問(wèn)題是只能表達(dá)“當(dāng)前在哪”表達(dá)不了“怎么來(lái)的”。一個(gè)訂單從創(chuàng)建到完成中間可能經(jīng)歷了改價(jià)、合并發(fā)貨、部分退款、補(bǔ)發(fā)這一系列過(guò)程才是這筆業(yè)務(wù)真正的樣子。把所有這些過(guò)程壓縮成一個(gè)當(dāng)前狀態(tài)相當(dāng)于把一整部電影縮略成一張海報(bào)鏡頭里的細(xì)節(jié)全丟了。更麻煩的是狀態(tài)還經(jīng)?；ハ嗝堋１热鐐}(cāng)庫(kù)已經(jīng)掃描出庫(kù)物流單也生成了訂單狀態(tài)卻還停在“待發(fā)貨”或者“處理中”。狀態(tài)字段一旦和真實(shí)世界的動(dòng)作脫節(jié)后面所有基于狀態(tài)的統(tǒng)計(jì)、對(duì)賬、報(bào)表都會(huì)失真。我后來(lái)意識(shí)到問(wèn)題不在狀態(tài)機(jī)的定義而在我們根本沒(méi)有一個(gè)穩(wěn)定的數(shù)據(jù)載體去描述“動(dòng)作”本身。1.2 “余額對(duì)不上”是最低成本的失敗方式另一個(gè)讓我下定決心重做的原因是庫(kù)存和資金余額的對(duì)賬。很多系統(tǒng)喜歡在表里直接存一個(gè)“當(dāng)前庫(kù)存”字段、一個(gè)“賬戶余額”字段每次業(yè)務(wù)動(dòng)作發(fā)生時(shí)加減它?？此聘咝?shí)際等于把計(jì)算結(jié)果和業(yè)務(wù)發(fā)生過(guò)程混在了一起。一旦出現(xiàn)并發(fā)超賣、重復(fù)回調(diào)、手工改庫(kù)存余額和真實(shí)情況不一致就成了必然。我記得有一次排查庫(kù)存差異賬上顯示有貨倉(cāng)庫(kù)實(shí)際沒(méi)有。查來(lái)查去最后發(fā)現(xiàn)是有個(gè)測(cè)試操作直接改了庫(kù)存字段的值既沒(méi)有留下業(yè)務(wù)單據(jù)也沒(méi)有關(guān)聯(lián)到任何訂單。所有基于“存量字段”的架構(gòu)都有這個(gè)隱患你能看到差值卻永遠(yuǎn)追不到差值的來(lái)源。1.3 REA的思路不談?dòng)囝~談事件我開(kāi)始尋找一種建模思路能讓業(yè)務(wù)數(shù)據(jù)的來(lái)龍去脈本身成為數(shù)據(jù)結(jié)構(gòu)的一部分。后來(lái)在一個(gè)會(huì)計(jì)信息系統(tǒng)領(lǐng)域的研究資料里看到Resource-Events-Agents模型項(xiàng)目代號(hào)我直接用了REA。它的核心思想概括起來(lái)就一句話不要用“余額”或“當(dāng)前狀態(tài)”作為建模中心而是用“事件”作為建模中心資源從哪來(lái)、到哪去參與者是誰(shuí)、有什么責(zé)任全部繞著事件記錄展開(kāi)。這套思路解決了我上面遇到的兩個(gè)死穴事件記錄了過(guò)程等價(jià)于把電影的關(guān)鍵鏡頭都保留下來(lái)余額不再是一個(gè)被直接修改的字段而是通過(guò)事件記錄聚合計(jì)算出來(lái)的推導(dǎo)值。誰(shuí)改過(guò)余額、在哪一單改的、為什么改在REA模型里都是一條條明確的事件。我把這個(gè)項(xiàng)目的整個(gè)推演過(guò)程、數(shù)據(jù)庫(kù)落地方案、踩過(guò)的坑都整理在這里。如果你也在做訂單、庫(kù)存、財(cái)務(wù)對(duì)賬類系統(tǒng)或者只是覺(jué)得當(dāng)前數(shù)據(jù)模型在面對(duì)業(yè)務(wù)追溯時(shí)使不上勁這套思路值得參考。它并不是銀彈但確實(shí)讓我的系統(tǒng)從“猜謎式查賬”變成了“鏈條式追溯”。2. 資源、事件、參與者三要素的邊界比想象中難劃REA模型聽(tīng)起來(lái)簡(jiǎn)單資源、事件、參與者三個(gè)詞而已。但真正動(dòng)手建模時(shí)邊界劃分比想象中難得多。同一個(gè)東西在不同業(yè)務(wù)階段可能是資源也可能只是描述信息同一個(gè)動(dòng)作可能算事件也可能只是一次普通日志。這部分我不想堆理論直接結(jié)合我做訂單重構(gòu)時(shí)的判斷過(guò)程來(lái)講。2.1 資源重點(diǎn)是“存量”不是“字典”先說(shuō)資源。REA里的資源指的是經(jīng)濟(jì)資源也就是能給企業(yè)帶來(lái)價(jià)值、能在業(yè)務(wù)過(guò)程中被交易、消耗、轉(zhuǎn)換的那些東西。常見(jiàn)的有商品、現(xiàn)金、應(yīng)收賬款、積分、服務(wù)工時(shí)、倉(cāng)庫(kù)庫(kù)存甚至可以是某種必須消耗的物料。判斷一個(gè)實(shí)體能不能當(dāng)資源我有一個(gè)很笨但很有效的檢查辦法問(wèn)自己一句——“它有沒(méi)有存量它能不能在一個(gè)事件里減少又在另一個(gè)事件里增加”如果答案是肯定的它才可能成為資源。比如“商品”有庫(kù)存可以被出庫(kù)減少被入庫(kù)增加所以它是資源?！吧唐访Q”不會(huì)因?yàn)闃I(yè)務(wù)動(dòng)作而變化那它就只是一個(gè)描述屬性。類似地“客戶名單”如果沒(méi)有被消耗或轉(zhuǎn)移也沒(méi)有存量那它就不是資源至少不是這個(gè)模型關(guān)心的資源。這里有個(gè)容易混淆的點(diǎn)主數(shù)據(jù)和資源的關(guān)系。我在項(xiàng)目里一開(kāi)始把“商品表”整個(gè)當(dāng)成資源表后來(lái)發(fā)現(xiàn)不對(duì)勁。商品表里的條碼、名稱、規(guī)格是靜態(tài)主數(shù)據(jù)屬于商品實(shí)體的描述真正會(huì)隨業(yè)務(wù)變化的是“某倉(cāng)某商品的可售庫(kù)存”。所以落地時(shí)我把商品主數(shù)據(jù)和庫(kù)存資源分開(kāi)了商品存描述庫(kù)存作為資源跟著事件走。資源表只記錄“有什么東西可被業(yè)務(wù)增減”不承擔(dān)字典表的職責(zé)。2.2 事件不是所有操作都能成為事件事件是REA最核心的表也是我重新建模時(shí)花時(shí)間最多的部分。它對(duì)應(yīng)的是業(yè)務(wù)過(guò)程中讓資源發(fā)生流入或流出的動(dòng)作。比如“客戶付款”讓現(xiàn)金資源流入“倉(cāng)庫(kù)發(fā)貨”讓商品庫(kù)存流出“采購(gòu)收貨”讓庫(kù)存流入。一個(gè)事件至少要改變一個(gè)資源的數(shù)量這是進(jìn)入事件表的硬門檻。我第一次建模時(shí)犯過(guò)一個(gè)錯(cuò)誤把“用戶點(diǎn)擊下單按鈕”記錄成了一個(gè)事件。點(diǎn)擊只是操作痕跡它并沒(méi)有讓任何經(jīng)濟(jì)資源發(fā)生增減也不會(huì)產(chǎn)生法律義務(wù)。真正的“下單”其實(shí)是一個(gè)承諾事件它讓商家對(duì)客戶產(chǎn)生了一項(xiàng)交付義務(wù)讓客戶產(chǎn)生了一項(xiàng)付款義務(wù)。義務(wù)也是價(jià)值所以它值得建模但它和“點(diǎn)擊”完全是兩層?xùn)|西。區(qū)分事件和日志有一條實(shí)際標(biāo)準(zhǔn)這個(gè)動(dòng)作是否會(huì)引起資源數(shù)量的聯(lián)動(dòng)變化。比如“審核通過(guò)”只是一條管理動(dòng)作不會(huì)直接讓庫(kù)存變少除非審核之后緊跟一個(gè)“出庫(kù)”動(dòng)作。我后來(lái)把這類狀態(tài)變化歸為“事實(shí)”或“步驟記錄”不放進(jìn)經(jīng)濟(jì)事件表避免把事件表和操作日志混在一起。2.3 參與者區(qū)分誰(shuí)擁有、誰(shuí)經(jīng)手、誰(shuí)受益參與者容易理解就是人、部門、組織、系統(tǒng)賬戶這些活躍角色。但做詳細(xì)設(shè)計(jì)時(shí)我發(fā)現(xiàn)參與者內(nèi)部要區(qū)分兩種性質(zhì)誰(shuí)對(duì)事件負(fù)有直接責(zé)任誰(shuí)在事件中擁有或接收資源。舉個(gè)例子“客戶下訂單”這個(gè)事件參與者有客戶和銷售員。客戶是外部參與者他承諾付款銷售員是內(nèi)部參與者他負(fù)責(zé)跟進(jìn)訂單。到了“收款”事件客戶付款財(cái)務(wù)人員確認(rèn)入賬?？蛻羰琴Y源流出方財(cái)務(wù)是資源接收方兩邊的責(zé)任完全不同。如果不區(qū)分這些角色事件表后面連“找哪個(gè)環(huán)節(jié)的人確認(rèn)這筆賬”都做不到。我落地時(shí)用兩張關(guān)聯(lián)表分別處理外部和內(nèi)部參與者的接入比塞進(jìn)一個(gè)字段清楚得多。內(nèi)部參與者常用于權(quán)限和績(jī)效追溯外部參與者用于對(duì)賬和客戶往來(lái)。中間還加了一層“參與角色”的概念同一參與者可以在不同事件里扮演不同角色。前期多花一點(diǎn)時(shí)間理清參與者的角色邊界后面寫(xiě)權(quán)限、報(bào)表、責(zé)任追溯時(shí)會(huì)非常順。3. 一個(gè)訂單業(yè)務(wù)的完整推演從需求清單到REA模型前面講的是概念這一章我直接用一個(gè)簡(jiǎn)化版的訂單業(yè)務(wù)場(chǎng)景走一遍完整建模流程。場(chǎng)景很典型客戶瀏覽商品、下單、倉(cāng)庫(kù)發(fā)貨、客戶付款、財(cái)務(wù)確認(rèn)到賬。里面可能還包含部分退款、發(fā)票開(kāi)具。我會(huì)按照我當(dāng)時(shí)實(shí)際執(zhí)行的四個(gè)步驟來(lái)講每一步的光景大致是先做什么、依據(jù)什么判斷、輸出什么結(jié)果。3.1 第一步先列業(yè)務(wù)動(dòng)作別急著建表我一般不會(huì)一上來(lái)就打開(kāi)數(shù)據(jù)庫(kù)設(shè)計(jì)工具而是先在白板上把業(yè)務(wù)過(guò)程里所有能被稱為“動(dòng)作”的東西列出來(lái)。這個(gè)階段要求先放開(kāi)“表”“字段”“狀態(tài)機(jī)”的概念純從業(yè)務(wù)行為出發(fā)把角色做了什么事、資源發(fā)生了什么變化都寫(xiě)清楚。以訂單場(chǎng)景為例列出來(lái)的動(dòng)作大致有客戶瀏覽商品、客戶提交訂單、系統(tǒng)扣除庫(kù)存、倉(cāng)庫(kù)揀貨、倉(cāng)庫(kù)發(fā)貨、物流配送、客戶確認(rèn)收貨、客戶發(fā)起支付、支付渠道回調(diào)、財(cái)務(wù)確認(rèn)收款、開(kāi)具發(fā)票、申請(qǐng)退款、審批退款、退款完成。這些動(dòng)作可以多列哪怕有一部分后來(lái)會(huì)被淘汰掉。先求全再求準(zhǔn)。列完動(dòng)作后我會(huì)做一次粗篩把那些沒(méi)有引起經(jīng)濟(jì)資源變化、也不產(chǎn)生實(shí)質(zhì)性義務(wù)的動(dòng)作先圈出來(lái)。比如“客戶瀏覽商品”“物流配送”在這個(gè)業(yè)務(wù)里只是支撐信息不是核心經(jīng)濟(jì)事件前者是行為日志后者是服務(wù)過(guò)程記錄。真正具備事件資格的主要是提交訂單、發(fā)貨、收款、退款、開(kāi)票。粗篩后剩下這些再進(jìn)入第二步進(jìn)一步分析它們和資源的關(guān)系。3.2 第二步把動(dòng)作轉(zhuǎn)成“資源流入/流出”事件必須有資源變動(dòng)所以第二步是給候選事件一一配對(duì)資源標(biāo)注流入方向還是流出方向并說(shuō)明對(duì)應(yīng)什么價(jià)值。“客戶提交訂單”這個(gè)動(dòng)作從REA角度屬于承諾事件它不直接讓庫(kù)存減少但建立了一項(xiàng)義務(wù)企業(yè)承諾交付商品客戶承諾交付現(xiàn)金。這個(gè)承諾如果要建?？梢猿橄鬄椤敖桓冻兄Z”和“付款承諾”兩種資源但在第一版我建議不用強(qiáng)建模先把實(shí)際買賣雙方的真實(shí)動(dòng)作梳理清楚?！皞}(cāng)庫(kù)發(fā)貨”是明確的經(jīng)濟(jì)事件商品庫(kù)存這個(gè)資源發(fā)生流出方向?yàn)閛ut與此同時(shí)企業(yè)付出了一項(xiàng)“銷售成本”也是資源流出。很多系統(tǒng)只記錄了庫(kù)存減少忽略了銷售成本結(jié)果后期的毛利分析完全沒(méi)法做。REA的好處在于它會(huì)逼著你去想這個(gè)事件除了庫(kù)存外還動(dòng)了哪些資源?！翱蛻舾犊睢眲t讓現(xiàn)金資源流入方向?yàn)閕n同時(shí)客戶的“應(yīng)付義務(wù)”減少這又是一種資源變化。開(kāi)票事件對(duì)應(yīng)的是“應(yīng)收義務(wù)”的確認(rèn)和稅金的產(chǎn)生。一路梳理下來(lái)事件和資源的映射就能落到表里事件資源變化方向價(jià)值體現(xiàn)提交訂單交付承諾 / 付款承諾流入流出建立雙方義務(wù)倉(cāng)庫(kù)發(fā)貨商品庫(kù)存流出銷售成本客戶付款現(xiàn)金 / 銀行存款流入實(shí)收貨款開(kāi)具發(fā)票應(yīng)收義務(wù) / 稅金流入流出收入確認(rèn)這一步做完業(yè)務(wù)動(dòng)作就有了“經(jīng)濟(jì)后果”?？雌饋?lái)只是在畫(huà)箭頭實(shí)際上是在為后面每個(gè)數(shù)據(jù)表字段提供邏輯依據(jù)。3.3 第三步用參與者掛上責(zé)任鏈資源變化確定后第三步就是把參與者和事件連起來(lái)。我問(wèn)的問(wèn)題通常是這個(gè)事件是哪個(gè)角色觸發(fā)的哪個(gè)角色執(zhí)行哪個(gè)角色負(fù)責(zé)確認(rèn)結(jié)果“提交訂單”是客戶觸發(fā)銷售客服確認(rèn)“倉(cāng)庫(kù)發(fā)貨”是倉(cāng)庫(kù)操作員執(zhí)行倉(cāng)管負(fù)責(zé)人審核“客戶付款”是客戶發(fā)起支付財(cái)務(wù)人員確認(rèn)到賬。不同的事件內(nèi)外部參與者的邊界不一樣。把這些對(duì)應(yīng)關(guān)系整理成一張責(zé)任矩陣后面做權(quán)限、審批流、業(yè)績(jī)歸屬都會(huì)很輕松。這一步容易忽略的是“系統(tǒng)自動(dòng)化參與方”。比如支付回調(diào)其實(shí)是支付渠道這個(gè)外部參與者觸發(fā)的“付款事件”而不是財(cái)務(wù)人員本人。財(cái)務(wù)人員只是后續(xù)審核確認(rèn)。如果模型里不記錄這個(gè)鏈路以后排查“這筆錢到底哪個(gè)環(huán)節(jié)進(jìn)來(lái)的”又會(huì)回到翻日志的老路。REA落地時(shí)我建議把系統(tǒng)、渠道、計(jì)時(shí)任務(wù)也作為特殊參與者統(tǒng)一放進(jìn)參與者表。3.4 第四步用恒等式做一次“體檢”所有元素都畫(huà)完之后我會(huì)做一道很通用的體檢題對(duì)每個(gè)資源把流入總量加起來(lái)減去流出總量應(yīng)該等于這個(gè)資源的“期初存量 期末存量”變化。換句話說(shuō)不能有流入沒(méi)有來(lái)源也不希望有流出沒(méi)有去處。我拿庫(kù)存資源驗(yàn)證采購(gòu)入庫(kù)的流入之和減去銷售出庫(kù)、報(bào)損出庫(kù)、盤虧出庫(kù)的流出之和應(yīng)該等于期末庫(kù)存。如果算出來(lái)不對(duì)就說(shuō)明要么事件清單漏了要么事件關(guān)聯(lián)錯(cuò)了資源方向。這道體檢題的價(jià)值在于它能在寫(xiě)代碼之前就暴露業(yè)務(wù)理解的漏洞而不是等上線之后讓對(duì)賬來(lái)背鍋。我實(shí)際跑下來(lái)最常發(fā)現(xiàn)的問(wèn)題是“退貨”事件方向填反。客戶退貨導(dǎo)致庫(kù)存流入同時(shí)要退款給客戶現(xiàn)金流出。一正一反兩個(gè)資源都要?jiǎng)尤绻r(shí)只記錄了庫(kù)存流入、漏了現(xiàn)金流出恒等式當(dāng)場(chǎng)就能發(fā)現(xiàn)總資產(chǎn)平不了。這就是REA建模比普通ER設(shè)計(jì)有用的地方它能通過(guò)經(jīng)濟(jì)恒等式自檢而不是等數(shù)據(jù)錯(cuò)亂后再修。4. 落地關(guān)系型數(shù)據(jù)庫(kù)表怎么拆余額怎么算模型圖畫(huà)完接下來(lái)是真刀真槍的數(shù)據(jù)庫(kù)設(shè)計(jì)。我之前見(jiàn)過(guò)很多REA相關(guān)的文章都在概念層面打轉(zhuǎn)一到建表就語(yǔ)焉不詳。這邊我把實(shí)際能用的一組表結(jié)構(gòu)分享出來(lái)并把其中的關(guān)鍵設(shè)計(jì)原因講清楚。不需要用特別復(fù)雜的數(shù)據(jù)庫(kù)一套PostgreSQL足夠其他關(guān)系型數(shù)據(jù)庫(kù)可以平移。4.1 核心表結(jié)構(gòu)事件為主資源、參與者為輔我的落地庫(kù)表結(jié)構(gòu)圍繞三張中心表展開(kāi)economic_eventresourceagent再配三張關(guān)聯(lián)表event_resourceevent_agentevent_link。第一張中心表是事件表字段包括事件類型、業(yè)務(wù)時(shí)間、業(yè)務(wù)參考號(hào)等。事件表里不冗余存參與者ID和資源ID統(tǒng)一通過(guò)關(guān)聯(lián)表掛接目的是讓“一個(gè)事件可以涉及多個(gè)資源、多個(gè)參與者”這件事變得自然。比如“倉(cāng)庫(kù)發(fā)貨”事件可能同時(shí)涉及多個(gè)SKU如果每個(gè)SKU的庫(kù)存變化都拆成獨(dú)立事件粒度太碎后期核對(duì)訂單維度就很麻煩。用事件主表和資源明細(xì)關(guān)聯(lián)表一個(gè)發(fā)貨單對(duì)應(yīng)多個(gè)資源變化行才能保持業(yè)務(wù)事件和記錄的1:1關(guān)系。CREATE TABLE economic_event ( id BIGSERIAL PRIMARY KEY, event_type VARCHAR(50) NOT NULL, happened_at TIMESTAMPTZ NOT NULL, recorded_at TIMESTAMPTZ NOT NULL DEFAULT now(), business_ref_no VARCHAR(64) NOT NULL ); CREATE TABLE resource ( id BIGSERIAL PRIMARY KEY, resource_code VARCHAR(50) NOT NULL UNIQUE, resource_type VARCHAR(20) NOT NULL, name VARCHAR(100) NOT NULL ); CREATE TABLE agent ( id BIGSERIAL PRIMARY KEY, agent_code VARCHAR(50) NOT NULL UNIQUE, agent_type VARCHAR(20) NOT NULL, name VARCHAR(100) NOT NULL ); CREATE TABLE event_resource ( event_id BIGINT NOT NULL REFERENCES economic_event(id), resource_id BIGINT NOT NULL REFERENCES resource(id), direction VARCHAR(4) NOT NULL CHECK (direction IN (in, out)), quantity NUMERIC(18,4) NOT NULL, valuation NUMERIC(18,4), PRIMARY KEY (event_id, resource_id, direction) ); CREATE TABLE event_agent ( event_id BIGINT NOT NULL REFERENCES economic_event(id), agent_id BIGINT NOT NULL REFERENCES agent(id), role VARCHAR(50) NOT NULL, PRIMARY KEY (event_id, agent_id, role) );細(xì)心的人會(huì)注意到event_resource表里我加了一個(gè)valuation字段。它存在的原因很簡(jiǎn)單庫(kù)存數(shù)量變化和價(jià)值變化并不總是一回事。比如商品數(shù)量沒(méi)變但單價(jià)調(diào)整了或者因?yàn)閰R率波動(dòng)賬面價(jià)值需要修正。把價(jià)值和數(shù)量分開(kāi)記錄報(bào)表口徑才能靈活調(diào)整。另外我建了一張event_link表專門用來(lái)記錄事件之間的關(guān)系。比如“發(fā)貨事件”和“收款事件”并不相互獨(dú)立它們通過(guò)同一個(gè)訂單發(fā)生關(guān)聯(lián)。用事件關(guān)聯(lián)表可以表達(dá)“這個(gè)收款是用于抵消哪幾個(gè)發(fā)貨”的多對(duì)多關(guān)系。沒(méi)有這張表后面做對(duì)賬時(shí)又要回到“通過(guò)訂單號(hào)反查”的老路等于把事件之間的業(yè)務(wù)聯(lián)系又丟給了應(yīng)用層。4.2 庫(kù)存和余額不靠字段存靠事件聚合算這是REA落地時(shí)最容易引發(fā)爭(zhēng)議的一條因?yàn)樾阅軋F(tuán)隊(duì)通常會(huì)抱怨“每次算庫(kù)存都SUM整個(gè)表數(shù)據(jù)量大怎么辦”我的回答很直接第一事件表是追加式數(shù)據(jù)幾乎不更新可以靠索引優(yōu)化第二可以建立物化視圖或每日匯總表但結(jié)算依據(jù)仍然是事件明細(xì)而不是一個(gè)隨手改的“庫(kù)存字段”。拿庫(kù)存舉例真正的當(dāng)前庫(kù)存是資源表上的一個(gè)推導(dǎo)值不是存儲(chǔ)值。SQL表達(dá)起來(lái)很直白SELECT r.id, r.name, COALESCE(SUM(CASE WHEN er.direction in THEN er.quantity ELSE 0 END), 0) - COALESCE(SUM(CASE WHEN er.direction out THEN er.quantity ELSE 0 END), 0) AS stock_now FROM resource r LEFT JOIN event_resource er ON er.resource_id r.id WHERE r.resource_type INVENTORY GROUP BY r.id, r.name;現(xiàn)實(shí)項(xiàng)目里我實(shí)際更常用“按日匯總”的物化視圖。也就是把事件明細(xì)按資源、按天、按方向先聚合成存量增量表查詢時(shí)只查匯總不用每天掃全量明細(xì)。但這個(gè)匯總表永遠(yuǎn)是“可重建的緩存”它只服務(wù)于性能不服務(wù)于真相。真相留在事件明細(xì)里任何匯總出了偏差都能用明細(xì)重新算出來(lái)?！坝囝~”和“庫(kù)存”一樣屬于事件聚合出的推導(dǎo)值。每個(gè)客戶的應(yīng)收余額等于所有銷售事件產(chǎn)生的應(yīng)收增加減去所有收款事件產(chǎn)生的應(yīng)收減少再減去退款產(chǎn)生的影響。用事件聚合算余額最大的好處是對(duì)賬不再是“兩邊余額比大小”而是“兩邊的事件序列是否一致”。哪怕兩邊余額碰巧相等只要中間少了一條事件也能通過(guò)事件序列比較發(fā)現(xiàn)。4.3 防止重復(fù)入賬業(yè)務(wù)唯一鍵和冪等設(shè)計(jì)事件表是追加式的這帶來(lái)一個(gè)潛在問(wèn)題——重復(fù)寫(xiě)入。比如支付回調(diào)由于網(wǎng)絡(luò)超時(shí)被重試兩次同一個(gè)渠道支付流水就可能被記成兩條收款事件余額就多算了。我的處理辦法是給business_ref_no建唯一索引。這個(gè)字段存放的是業(yè)務(wù)系統(tǒng)里天然的冪等標(biāo)識(shí)支付單號(hào)、發(fā)貨單號(hào)、采購(gòu)入庫(kù)單號(hào)。業(yè)務(wù)上同一筆支付只有一個(gè)支付單號(hào)數(shù)據(jù)庫(kù)層面用唯一約束直接攔住第二次插入比應(yīng)用層判斷更可靠。ALTER TABLE economic_event ADD CONSTRAINT uk_event_business_ref UNIQUE (business_ref_no);還有一個(gè)細(xì)節(jié)業(yè)務(wù)參考號(hào)字段必須由上游業(yè)務(wù)系統(tǒng)生成而不是由事件記錄系統(tǒng)自己生成。原因很簡(jiǎn)單只有上游生成的單號(hào)才能代表“真實(shí)世界的同一筆業(yè)務(wù)”。如果是事件表自己用自增ID做判斷那么同一筆業(yè)務(wù)在兩個(gè)環(huán)境里就會(huì)擁有不同ID冪等約束就形同虛設(shè)。針對(duì)極端并發(fā)場(chǎng)景還可以在event_resource表上加“同一事件同一資源只能有一個(gè)方向的減記”這類約束防止同一張發(fā)貨單不小心關(guān)聯(lián)了同一SKU的兩條流出記錄。這類約束看起來(lái)繁瑣但每一個(gè)都是對(duì)“重復(fù)入賬”這個(gè)坑的主動(dòng)防御。4.4 對(duì)賬不再是對(duì)余額而是對(duì)事件序列傳統(tǒng)對(duì)賬方式系統(tǒng)余額 vs 銀行/倉(cāng)庫(kù)賬面余額兩邊各自算一個(gè)期末數(shù)比較是否相等。REA落地后我把它改成了事件序列比對(duì)。具體做法是把系統(tǒng)內(nèi)的收款事件按業(yè)務(wù)參考號(hào)、金額、時(shí)間導(dǎo)出一份清單把銀行渠道流水也按同樣的口徑導(dǎo)出一份清單然后逐筆匹配。匹配不上的不是“最終余額不對(duì)”而是“中間有一筆差異”定位到具體是哪一筆的時(shí)間點(diǎn)通常很快就能找到原因。這種模式在數(shù)據(jù)庫(kù)層面的表達(dá)是一個(gè)簡(jiǎn)單的“未匹配事件”查詢SELECT e.business_ref_no, e.event_type, e.happened_at, SUM(er.valuation) AS amount FROM economic_event e LEFT JOIN event_resource er ON er.event_id e.id WHERE e.event_type receive_payment AND e.business_ref_no NOT IN ( SELECT matched_ref_no FROM external_statement ) GROUP BY e.business_ref_no, e.event_type, e.happened_at;這個(gè)查詢的假設(shè)是有一條external_statement表格來(lái)記錄銀行流水的匹配狀態(tài)。實(shí)際項(xiàng)目中這部分會(huì)做得更復(fù)雜但核心思路不變對(duì)賬系統(tǒng)變成“找兩邊事件集合的差集”而不是“比較兩個(gè)標(biāo)量余額”。我做了這次改造以后財(cái)務(wù)同事反饋?zhàn)疃嗟囊痪湓捠恰敖K于知道差在哪一筆了”而不是以前那種“數(shù)量對(duì)上就行具體哪筆再說(shuō)”。5. 這模型不是萬(wàn)能藥踩坑記錄與適用邊界REA確實(shí)解決了我上面提到的追溯性和一致性問(wèn)題但它不是毫無(wú)代價(jià)的萬(wàn)能結(jié)構(gòu)。我用下來(lái)大概半年踩過(guò)好幾個(gè)坑也摸出了一些適用邊界。把這些經(jīng)驗(yàn)寫(xiě)出來(lái)是為了讓你別像我一樣在某個(gè)地方反復(fù)權(quán)衡很久才想明白。5.1 最容易失控的是事件粒度事件粒度是我踩得最狠的坑。一開(kāi)始我擔(dān)心事件記錄不夠細(xì)于是把“客戶修改收貨地址”“客服發(fā)起改價(jià)”“運(yùn)營(yíng)添加備注”都做成了事件關(guān)聯(lián)到訂單。結(jié)果模型變得越來(lái)越重滿屏都是“事件”業(yè)務(wù)方卻看不懂任何一條事件的價(jià)值。后來(lái)我把粒度原則收斂成一句話只有會(huì)改變資源數(shù)量或法律義務(wù)的動(dòng)作才被認(rèn)定為經(jīng)濟(jì)事件其他作為操作日志保存關(guān)聯(lián)訂單號(hào)即可。粒度失控還會(huì)拖垮查詢性能。事件表一旦膨脹到上億行實(shí)時(shí)聚合的成本會(huì)顯著上升。我后來(lái)按日、按資源重建物化視圖才把查詢拉回來(lái)。如果你在事件粒度上拿不準(zhǔn)建議先用“是否會(huì)引發(fā)資源增減”判斷再問(wèn)一句“把這個(gè)動(dòng)作從模型中刪掉業(yè)務(wù)追溯會(huì)不會(huì)缺核心證據(jù)”。兩個(gè)問(wèn)題都通過(guò)才值得進(jìn)入事件表。5.2 非經(jīng)濟(jì)動(dòng)作硬塞進(jìn)REA反而失去可讀性不是所有業(yè)務(wù)元素都適合塞進(jìn)REA框架。報(bào)關(guān)單號(hào)、物流軌跡、圖片審核、風(fēng)控規(guī)則命中這些要么是法規(guī)要求要么是流程控制要么是機(jī)器學(xué)習(xí)推斷它們不直接交換經(jīng)濟(jì)資源硬塞進(jìn)去只會(huì)讓模型變得又長(zhǎng)又難懂。我的處理方式是把系統(tǒng)分成兩層經(jīng)濟(jì)核心層和業(yè)務(wù)支撐層。經(jīng)濟(jì)核心層使用REA承載訂單、庫(kù)存、資金、應(yīng)收應(yīng)付業(yè)務(wù)支撐層保存物流軌跡、風(fēng)控記錄、審核步驟通過(guò)事件ID和經(jīng)濟(jì)核心層關(guān)聯(lián)。這兩層共用一套主數(shù)據(jù)但不互相污染。這樣REA模型保持精簡(jiǎn)支撐層的豐富信息也不丟失。5.3 與常規(guī)CRUD開(kāi)發(fā)的思維沖突最后要提醒的是心態(tài)問(wèn)題。習(xí)慣了CRUD開(kāi)發(fā)的同事遇到REA會(huì)有一種強(qiáng)烈的“不舒服”為什么“更新庫(kù)存”不是UPDATE一個(gè)庫(kù)存表而是INSERT一條新事件記錄為什么訂單狀態(tài)變了不直接改狀態(tài)字段而要關(guān)聯(lián)一串事件這種沖突不只是技術(shù)問(wèn)題更是數(shù)據(jù)思維的轉(zhuǎn)變。CRUD的默認(rèn)假設(shè)是“數(shù)據(jù)記錄代表當(dāng)前狀態(tài)”REA的默認(rèn)假設(shè)是“數(shù)據(jù)記錄代表發(fā)生變化的過(guò)程”。如果你所在團(tuán)隊(duì)的成員沒(méi)有這種意識(shí)哪怕表結(jié)構(gòu)設(shè)計(jì)成REA編碼時(shí)他們也會(huì)想方設(shè)法繞過(guò)事件表去存一個(gè)“方便”的狀態(tài)字段最后模型依然會(huì)老化回舊形態(tài)。我的建議是導(dǎo)入REA模型的初期不要急著動(dòng)所有模塊先選一個(gè)對(duì)追溯要求高的模塊試點(diǎn)比如應(yīng)收對(duì)賬或庫(kù)存流水。跑通一輪后再把經(jīng)驗(yàn)遷移到其他模塊。避免一次重構(gòu)范圍過(guò)大否則項(xiàng)目本身就變成了災(zāi)難事件。說(shuō)來(lái)也怪做完這次重構(gòu)后我的感受不是“我掌握了一個(gè)高深的建模方法”而是“我終于敢讓代碼解釋歷史了”。以前每次遇到數(shù)據(jù)不一致都要靠人肉翻日志去猜現(xiàn)在只要順著事件表往下游查該誰(shuí)的責(zé)任、該補(bǔ)哪條記錄一目了然。最后分享一個(gè)小習(xí)慣是我現(xiàn)在建每一張業(yè)務(wù)表之前都會(huì)做的自檢這行記錄能不能回答“誰(shuí)在什么時(shí)間做了什么動(dòng)作導(dǎo)致了哪個(gè)資源的增加或減少”。如果回答不了就回到事件表重新設(shè)計(jì)。這個(gè)習(xí)慣比任何建模工具都管用。