1. 為什么我會(huì)把一個(gè)訂單系統(tǒng)推翻重做舊模型的兩個(gè)死穴前一陣我把一個(gè)后臺(tái)系統(tǒng)的訂單模塊整個(gè)推倒重來了。原因不是業(yè)務(wù)代碼寫得亂而是數(shù)據(jù)模型根本撐不住對(duì)賬和審計(jì)。那套舊方案很常見訂單表一行數(shù)據(jù)上面掛一個(gè)狀態(tài)字段從“待支付”到“已支付”再到“已發(fā)貨”狀態(tài)一變更新一下字段前端的進(jìn)度條跟著走。表面看沒問題可一旦出現(xiàn)部分退款、贈(zèng)品抵扣、壞賬核銷、換貨這行訂單記錄就變成了一堆狀態(tài)來回橫跳的怪胎。真正壓垮我的場(chǎng)景是這樣的某個(gè)客戶有一筆訂單系統(tǒng)里顯示“已關(guān)閉”財(cái)務(wù)卻堅(jiān)持說這筆錢已經(jīng)收到了。兩邊打開后臺(tái)一對(duì)訂單狀態(tài)是關(guān)閉但支付流水表里確實(shí)有一筆入賬記錄。這個(gè)“已關(guān)閉”到底是誰關(guān)的關(guān)閉之前發(fā)生過什么當(dāng)時(shí)庫(kù)里的余額為什么和銀行流水對(duì)不上沒人能從一個(gè)狀態(tài)字段里找出答案只能去翻日志、查操作記錄一個(gè)晚上就這么沒了。1.1 狀態(tài)字段越長(zhǎng)業(yè)務(wù)真相越模糊狀態(tài)字段本身不是一個(gè)錯(cuò)誤它的問題是只能表達(dá)“當(dāng)前在哪”表達(dá)不了“怎么來的”。一個(gè)訂單從創(chuàng)建到完成中間可能經(jīng)歷了改價(jià)、合并發(fā)貨、部分退款、補(bǔ)發(fā)這一系列過程才是這筆業(yè)務(wù)真正的樣子。把所有這些過程壓縮成一個(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ì)失真。我后來意識(shí)到問題不在狀態(tài)機(jī)的定義而在我們根本沒有一個(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ā)生過程混在了一起。一旦出現(xiàn)并發(fā)超賣、重復(fù)回調(diào)、手工改庫(kù)存余額和真實(shí)情況不一致就成了必然。我記得有一次排查庫(kù)存差異賬上顯示有貨倉(cāng)庫(kù)實(shí)際沒有。查來查去最后發(fā)現(xiàn)是有個(gè)測(cè)試操作直接改了庫(kù)存字段的值既沒有留下業(yè)務(wù)單據(jù)也沒有關(guān)聯(lián)到任何訂單。所有基于“存量字段”的架構(gòu)都有這個(gè)隱患你能看到差值卻永遠(yuǎn)追不到差值的來源。1.3 REA的思路不談?dòng)囝~談事件我開始尋找一種建模思路能讓業(yè)務(wù)數(shù)據(jù)的來龍去脈本身成為數(shù)據(jù)結(jié)構(gòu)的一部分。后來在一個(gè)會(huì)計(jì)信息系統(tǒng)領(lǐng)域的研究資料里看到Resource-Events-Agents模型項(xiàng)目代號(hào)我直接用了REA。它的核心思想概括起來就一句話不要用“余額”或“當(dāng)前狀態(tài)”作為建模中心而是用“事件”作為建模中心資源從哪來、到哪去參與者是誰、有什么責(zé)任全部繞著事件記錄展開。這套思路解決了我上面遇到的兩個(gè)死穴事件記錄了過程等價(jià)于把電影的關(guān)鍵鏡頭都保留下來余額不再是一個(gè)被直接修改的字段而是通過事件記錄聚合計(jì)算出來的推導(dǎo)值。誰改過余額、在哪一單改的、為什么改在REA模型里都是一條條明確的事件。我把這個(gè)項(xiàng)目的整個(gè)推演過程、數(shù)據(jù)庫(kù)落地方案、踩過的坑都整理在這里。如果你也在做訂單、庫(kù)存、財(cái)務(wù)對(duì)賬類系統(tǒng)或者只是覺得當(dāng)前數(shù)據(jù)模型在面對(duì)業(yè)務(wù)追溯時(shí)使不上勁這套思路值得參考。它并不是銀彈但確實(shí)讓我的系統(tǒng)從“猜謎式查賬”變成了“鏈條式追溯”。2. 資源、事件、參與者三要素的邊界比想象中難劃REA模型聽起來簡(jiǎn)單資源、事件、參與者三個(gè)詞而已。但真正動(dòng)手建模時(shí)邊界劃分比想象中難得多。同一個(gè)東西在不同業(yè)務(wù)階段可能是資源也可能只是描述信息同一個(gè)動(dòng)作可能算事件也可能只是一次普通日志。這部分我不想堆理論直接結(jié)合我做訂單重構(gòu)時(shí)的判斷過程來講。2.1 資源重點(diǎn)是“存量”不是“字典”先說資源。REA里的資源指的是經(jīng)濟(jì)資源也就是能給企業(yè)帶來價(jià)值、能在業(yè)務(wù)過程中被交易、消耗、轉(zhuǎn)換的那些東西。常見的有商品、現(xiàn)金、應(yīng)收賬款、積分、服務(wù)工時(shí)、倉(cāng)庫(kù)庫(kù)存甚至可以是某種必須消耗的物料。判斷一個(gè)實(shí)體能不能當(dāng)資源我有一個(gè)很笨但很有效的檢查辦法問自己一句——“它有沒有存量它能不能在一個(gè)事件里減少又在另一個(gè)事件里增加”如果答案是肯定的它才可能成為資源。比如“商品”有庫(kù)存可以被出庫(kù)減少被入庫(kù)增加所以它是資源?！吧唐访Q”不會(huì)因?yàn)闃I(yè)務(wù)動(dòng)作而變化那它就只是一個(gè)描述屬性。類似地“客戶名單”如果沒有被消耗或轉(zhuǎn)移也沒有存量那它就不是資源至少不是這個(gè)模型關(guān)心的資源。這里有個(gè)容易混淆的點(diǎn)主數(shù)據(jù)和資源的關(guān)系。我在項(xiàng)目里一開始把“商品表”整個(gè)當(dāng)成資源表后來發(fā)現(xiàn)不對(duì)勁。商品表里的條碼、名稱、規(guī)格是靜態(tài)主數(shù)據(jù)屬于商品實(shí)體的描述真正會(huì)隨業(yè)務(wù)變化的是“某倉(cāng)某商品的可售庫(kù)存”。所以落地時(shí)我把商品主數(shù)據(jù)和庫(kù)存資源分開了商品存描述庫(kù)存作為資源跟著事件走。資源表只記錄“有什么東西可被業(yè)務(wù)增減”不承擔(dān)字典表的職責(zé)。2.2 事件不是所有操作都能成為事件事件是REA最核心的表也是我重新建模時(shí)花時(shí)間最多的部分。它對(duì)應(yīng)的是業(yè)務(wù)過程中讓資源發(fā)生流入或流出的動(dòng)作。比如“客戶付款”讓現(xiàn)金資源流入“倉(cāng)庫(kù)發(fā)貨”讓商品庫(kù)存流出“采購(gòu)收貨”讓庫(kù)存流入。一個(gè)事件至少要改變一個(gè)資源的數(shù)量這是進(jìn)入事件表的硬門檻。我第一次建模時(shí)犯過一個(gè)錯(cuò)誤把“用戶點(diǎn)擊下單按鈕”記錄成了一個(gè)事件。點(diǎn)擊只是操作痕跡它并沒有讓任何經(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)變化。比如“審核通過”只是一條管理動(dòng)作不會(huì)直接讓庫(kù)存變少除非審核之后緊跟一個(gè)“出庫(kù)”動(dòng)作。我后來把這類狀態(tài)變化歸為“事實(shí)”或“步驟記錄”不放進(jìn)經(jīng)濟(jì)事件表避免把事件表和操作日志混在一起。2.3 參與者區(qū)分誰擁有、誰經(jīng)手、誰受益參與者容易理解就是人、部門、組織、系統(tǒng)賬戶這些活躍角色。但做詳細(xì)設(shè)計(jì)時(shí)我發(fā)現(xiàn)參與者內(nèi)部要區(qū)分兩種性質(zhì)誰對(duì)事件負(fù)有直接責(zé)任誰在事件中擁有或接收資源。舉個(gè)例子“客戶下訂單”這個(gè)事件參與者有客戶和銷售員?？蛻羰峭獠繀⑴c者他承諾付款銷售員是內(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ì)賬和客戶往來。中間還加了一層“參與角色”的概念同一參與者可以在不同事件里扮演不同角色。前期多花一點(diǎn)時(shí)間理清參與者的角色邊界后面寫權(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ā)票開具。我會(huì)按照我當(dāng)時(shí)實(shí)際執(zhí)行的四個(gè)步驟來講每一步的光景大致是先做什么、依據(jù)什么判斷、輸出什么結(jié)果。3.1 第一步先列業(yè)務(wù)動(dòng)作別急著建表我一般不會(huì)一上來就打開數(shù)據(jù)庫(kù)設(shè)計(jì)工具而是先在白板上把業(yè)務(wù)過程里所有能被稱為“動(dòng)作”的東西列出來。這個(gè)階段要求先放開“表”“字段”“狀態(tài)機(jī)”的概念純從業(yè)務(wù)行為出發(fā)把角色做了什么事、資源發(fā)生了什么變化都寫清楚。以訂單場(chǎng)景為例列出來的動(dòng)作大致有客戶瀏覽商品、客戶提交訂單、系統(tǒng)扣除庫(kù)存、倉(cāng)庫(kù)揀貨、倉(cāng)庫(kù)發(fā)貨、物流配送、客戶確認(rèn)收貨、客戶發(fā)起支付、支付渠道回調(diào)、財(cái)務(wù)確認(rèn)收款、開具發(fā)票、申請(qǐng)退款、審批退款、退款完成。這些動(dòng)作可以多列哪怕有一部分后來會(huì)被淘汰掉。先求全再求準(zhǔn)。列完動(dòng)作后我會(huì)做一次粗篩把那些沒有引起經(jīng)濟(jì)資源變化、也不產(chǎn)生實(shí)質(zhì)性義務(wù)的動(dòng)作先圈出來。比如“客戶瀏覽商品”“物流配送”在這個(gè)業(yè)務(wù)里只是支撐信息不是核心經(jīng)濟(jì)事件前者是行為日志后者是服務(wù)過程記錄。真正具備事件資格的主要是提交訂單、發(fā)貨、收款、退款、開票。粗篩后剩下這些再進(jìn)入第二步進(jìn)一步分析它們和資源的關(guān)系。3.2 第二步把動(dòng)作轉(zhuǎn)成“資源流入/流出”事件必須有資源變動(dòng)所以第二步是給候選事件一一配對(duì)資源標(biāo)注流入方向還是流出方向并說明對(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é)果后期的毛利分析完全沒法做。REA的好處在于它會(huì)逼著你去想這個(gè)事件除了庫(kù)存外還動(dòng)了哪些資源。“客戶付款”則讓現(xiàn)金資源流入方向?yàn)閕n同時(shí)客戶的“應(yīng)付義務(wù)”減少這又是一種資源變化。開票事件對(duì)應(yīng)的是“應(yīng)收義務(wù)”的確認(rèn)和稅金的產(chǎn)生。一路梳理下來事件和資源的映射就能落到表里事件資源變化方向價(jià)值體現(xiàn)提交訂單交付承諾 / 付款承諾流入流出建立雙方義務(wù)倉(cāng)庫(kù)發(fā)貨商品庫(kù)存流出銷售成本客戶付款現(xiàn)金 / 銀行存款流入實(shí)收貨款開具發(fā)票應(yīng)收義務(wù) / 稅金流入流出收入確認(rèn)這一步做完業(yè)務(wù)動(dòng)作就有了“經(jīng)濟(jì)后果”?？雌饋碇皇窃诋嫾^實(shí)際上是在為后面每個(gè)數(shù)據(jù)表字段提供邏輯依據(jù)。3.3 第三步用參與者掛上責(zé)任鏈資源變化確定后第三步就是把參與者和事件連起來。我問的問題通常是這個(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)來的”又會(huì)回到翻日志的老路。REA落地時(shí)我建議把系統(tǒng)、渠道、計(jì)時(shí)任務(wù)也作為特殊參與者統(tǒng)一放進(jìn)參與者表。3.4 第四步用恒等式做一次“體檢”所有元素都畫完之后我會(huì)做一道很通用的體檢題對(duì)每個(gè)資源把流入總量加起來減去流出總量應(yīng)該等于這個(gè)資源的“期初存量 期末存量”變化。換句話說不能有流入沒有來源也不希望有流出沒有去處。我拿庫(kù)存資源驗(yàn)證采購(gòu)入庫(kù)的流入之和減去銷售出庫(kù)、報(bào)損出庫(kù)、盤虧出庫(kù)的流出之和應(yīng)該等于期末庫(kù)存。如果算出來不對(duì)就說明要么事件清單漏了要么事件關(guān)聯(lián)錯(cuò)了資源方向。這道體檢題的價(jià)值在于它能在寫代碼之前就暴露業(yè)務(wù)理解的漏洞而不是等上線之后讓對(duì)賬來背鍋。我實(shí)際跑下來最常發(fā)現(xià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ì)有用的地方它能通過經(jīng)濟(jì)恒等式自檢而不是等數(shù)據(jù)錯(cuò)亂后再修。4. 落地關(guān)系型數(shù)據(jù)庫(kù)表怎么拆余額怎么算模型圖畫完接下來是真刀真槍的數(shù)據(jù)庫(kù)設(shè)計(jì)。我之前見過很多REA相關(guān)的文章都在概念層面打轉(zhuǎn)一到建表就語焉不詳。這邊我把實(shí)際能用的一組表結(jié)構(gòu)分享出來并把其中的關(guān)鍵設(shè)計(jì)原因講清楚。不需要用特別復(fù)雜的數(shù)據(jù)庫(kù)一套PostgreSQL足夠其他關(guān)系型數(shù)據(jù)庫(kù)可以平移。4.1 核心表結(jié)構(gòu)事件為主資源、參與者為輔我的落地庫(kù)表結(jié)構(gòu)圍繞三張中心表展開economic_eventresourceagent再配三張關(guān)聯(lián)表event_resourceevent_agentevent_link。第一張中心表是事件表字段包括事件類型、業(yè)務(wù)時(shí)間、業(yè)務(wù)參考號(hào)等。事件表里不冗余存參與者ID和資源ID統(tǒng)一通過關(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ù)量沒變但單價(jià)調(diào)整了或者因?yàn)閰R率波動(dòng)賬面價(jià)值需要修正。把價(jià)值和數(shù)量分開記錄報(bào)表口徑才能靈活調(diào)整。另外我建了一張event_link表專門用來記錄事件之間的關(guān)系。比如“發(fā)貨事件”和“收款事件”并不相互獨(dú)立它們通過同一個(gè)訂單發(fā)生關(guān)聯(lián)。用事件關(guān)聯(lián)表可以表達(dá)“這個(gè)收款是用于抵消哪幾個(gè)發(fā)貨”的多對(duì)多關(guān)系。沒有這張表后面做對(duì)賬時(shí)又要回到“通過訂單號(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á)起來很直白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ì)重新算出來?！坝囝~”和“庫(kù)存”一樣屬于事件聚合出的推導(dǎo)值。每個(gè)客戶的應(yīng)收余額等于所有銷售事件產(chǎn)生的應(yīng)收增加減去所有收款事件產(chǎn)生的應(yīng)收減少再減去退款產(chǎn)生的影響。用事件聚合算余額最大的好處是對(duì)賬不再是“兩邊余額比大小”而是“兩邊的事件序列是否一致”。哪怕兩邊余額碰巧相等只要中間少了一條事件也能通過事件序列比較發(fā)現(xiàn)。4.3 防止重復(fù)入賬業(yè)務(wù)唯一鍵和冪等設(shè)計(jì)事件表是追加式的這帶來一個(gè)潛在問題——重復(fù)寫入。比如支付回調(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的兩條流出記錄。這類約束看起來繁瑣但每一個(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表格來記錄銀行流水的匹配狀態(tài)。實(shí)際項(xiàng)目中這部分會(huì)做得更復(fù)雜但核心思路不變對(duì)賬系統(tǒng)變成“找兩邊事件集合的差集”而不是“比較兩個(gè)標(biāo)量余額”。我做了這次改造以后財(cái)務(wù)同事反饋?zhàn)疃嗟囊痪湓捠恰敖K于知道差在哪一筆了”而不是以前那種“數(shù)量對(duì)上就行具體哪筆再說”。5. 這模型不是萬能藥踩坑記錄與適用邊界REA確實(shí)解決了我上面提到的追溯性和一致性問題但它不是毫無代價(jià)的萬能結(jié)構(gòu)。我用下來大概半年踩過好幾個(gè)坑也摸出了一些適用邊界。把這些經(jīng)驗(yàn)寫出來是為了讓你別像我一樣在某個(gè)地方反復(fù)權(quán)衡很久才想明白。5.1 最容易失控的是事件粒度事件粒度是我踩得最狠的坑。一開始我擔(dān)心事件記錄不夠細(xì)于是把“客戶修改收貨地址”“客服發(fā)起改價(jià)”“運(yùn)營(yíng)添加備注”都做成了事件關(guān)聯(lián)到訂單。結(jié)果模型變得越來越重滿屏都是“事件”業(yè)務(wù)方卻看不懂任何一條事件的價(jià)值。后來我把粒度原則收斂成一句話只有會(huì)改變資源數(shù)量或法律義務(wù)的動(dòng)作才被認(rèn)定為經(jīng)濟(jì)事件其他作為操作日志保存關(guān)聯(lián)訂單號(hào)即可。粒度失控還會(huì)拖垮查詢性能。事件表一旦膨脹到上億行實(shí)時(shí)聚合的成本會(huì)顯著上升。我后來按日、按資源重建物化視圖才把查詢拉回來。如果你在事件粒度上拿不準(zhǔn)建議先用“是否會(huì)引發(fā)資源增減”判斷再問一句“把這個(gè)動(dòng)作從模型中刪掉業(yè)務(wù)追溯會(huì)不會(huì)缺核心證據(jù)”。兩個(gè)問題都通過才值得進(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)控記錄、審核步驟通過事件ID和經(jīng)濟(jì)核心層關(guān)聯(lián)。這兩層共用一套主數(shù)據(jù)但不互相污染。這樣REA模型保持精簡(jiǎn)支撐層的豐富信息也不丟失。5.3 與常規(guī)CRUD開發(fā)的思維沖突最后要提醒的是心態(tài)問題。習(xí)慣了CRUD開發(fā)的同事遇到REA會(huì)有一種強(qiáng)烈的“不舒服”為什么“更新庫(kù)存”不是UPDATE一個(gè)庫(kù)存表而是INSERT一條新事件記錄為什么訂單狀態(tài)變了不直接改狀態(tài)字段而要關(guān)聯(lián)一串事件這種沖突不只是技術(shù)問題更是數(shù)據(jù)思維的轉(zhuǎn)變。CRUD的默認(rèn)假設(shè)是“數(shù)據(jù)記錄代表當(dāng)前狀態(tài)”REA的默認(rèn)假設(shè)是“數(shù)據(jù)記錄代表發(fā)生變化的過程”。如果你所在團(tuán)隊(duì)的成員沒有這種意識(shí)哪怕表結(jié)構(gòu)設(shè)計(jì)成REA編碼時(shí)他們也會(huì)想方設(shè)法繞過事件表去存一個(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)范圍過大否則項(xiàng)目本身就變成了災(zāi)難事件。說來也怪做完這次重構(gòu)后我的感受不是“我掌握了一個(gè)高深的建模方法”而是“我終于敢讓代碼解釋歷史了”。以前每次遇到數(shù)據(jù)不一致都要靠人肉翻日志去猜現(xiàn)在只要順著事件表往下游查該誰的責(zé)任、該補(bǔ)哪條記錄一目了然。最后分享一個(gè)小習(xí)慣是我現(xiàn)在建每一張業(yè)務(wù)表之前都會(huì)做的自檢這行記錄能不能回答“誰在什么時(shí)間做了什么動(dòng)作導(dǎo)致了哪個(gè)資源的增加或減少”。如果回答不了就回到事件表重新設(shè)計(jì)。這個(gè)習(xí)慣比任何建模工具都管用。