訂單系統(tǒng)：用事件溯源解決對賬與審計(jì)難題)
1. 為什么我會(huì)把一個(gè)訂單系統(tǒng)推翻重做舊模型的兩個(gè)死穴前一陣我把一個(gè)后臺系統(tǒng)的訂單模塊整個(gè)推倒重來了。原因不是業(yè)務(wù)代碼寫得亂而是數(shù)據(jù)模型根本撐不住對賬和審計(jì)。那套舊方案很常見訂單表一行數(shù)據(jù)上面掛一個(gè)狀態(tài)字段從“待支付”到“已支付”再到“已發(fā)貨”狀態(tài)一變更新一下字段前端的進(jìn)度條跟著走。表面看沒問題可一旦出現(xiàn)部分退款、贈(zèng)品抵扣、壞賬核銷、換貨這行訂單記錄就變成了一堆狀態(tài)來回橫跳的怪胎。真正壓垮我的場景是這樣的某個(gè)客戶有一筆訂單系統(tǒng)里顯示“已關(guān)閉”財(cái)務(wù)卻堅(jiān)持說這筆錢已經(jīng)收到了。兩邊打開后臺一對訂單狀態(tài)是關(guān)閉但支付流水表里確實(shí)有一筆入賬記錄。這個(gè)“已關(guān)閉”到底是誰關(guān)的關(guān)閉之前發(fā)生過什么當(dāng)時(shí)庫里的余額為什么和銀行流水對不上沒人能從一個(gè)狀態(tài)字段里找出答案只能去翻日志、查操作記錄一個(gè)晚上就這么沒了。1.1 狀態(tài)字段越長業(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)?；ハ嗝?。比如倉庫已經(jīng)掃描出庫物流單也生成了訂單狀態(tài)卻還停在“待發(fā)貨”或者“處理中”。狀態(tài)字段一旦和真實(shí)世界的動(dòng)作脫節(jié)后面所有基于狀態(tài)的統(tǒng)計(jì)、對賬、報(bào)表都會(huì)失真。我后來意識到問題不在狀態(tài)機(jī)的定義而在我們根本沒有一個(gè)穩(wěn)定的數(shù)據(jù)載體去描述“動(dòng)作”本身。1.2 “余額對不上”是最低成本的失敗方式另一個(gè)讓我下定決心重做的原因是庫存和資金余額的對賬。很多系統(tǒng)喜歡在表里直接存一個(gè)“當(dāng)前庫存”字段、一個(gè)“賬戶余額”字段每次業(yè)務(wù)動(dòng)作發(fā)生時(shí)加減它。看似高效實(shí)際等于把計(jì)算結(jié)果和業(yè)務(wù)發(fā)生過程混在了一起。一旦出現(xiàn)并發(fā)超賣、重復(fù)回調(diào)、手工改庫存余額和真實(shí)情況不一致就成了必然。我記得有一次排查庫存差異賬上顯示有貨倉庫實(shí)際沒有。查來查去最后發(fā)現(xiàn)是有個(gè)測試操作直接改了庫存字段的值既沒有留下業(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)目代號我直接用了REA。它的核心思想概括起來就一句話不要用“余額”或“當(dāng)前狀態(tài)”作為建模中心而是用“事件”作為建模中心資源從哪來、到哪去參與者是誰、有什么責(zé)任全部繞著事件記錄展開。這套思路解決了我上面遇到的兩個(gè)死穴事件記錄了過程等價(jià)于把電影的關(guān)鍵鏡頭都保留下來余額不再是一個(gè)被直接修改的字段而是通過事件記錄聚合計(jì)算出來的推導(dǎo)值。誰改過余額、在哪一單改的、為什么改在REA模型里都是一條條明確的事件。我把這個(gè)項(xiàng)目的整個(gè)推演過程、數(shù)據(jù)庫落地方案、踩過的坑都整理在這里。如果你也在做訂單、庫存、財(cái)務(wù)對賬類系統(tǒng)或者只是覺得當(dāng)前數(shù)據(jù)模型在面對業(yè)務(wù)追溯時(shí)使不上勁這套思路值得參考。它并不是銀彈但確實(shí)讓我的系統(tǒng)從“猜謎式查賬”變成了“鏈條式追溯”。2. 資源、事件、參與者三要素的邊界比想象中難劃REA模型聽起來簡單資源、事件、參與者三個(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í)、倉庫庫存甚至可以是某種必須消耗的物料。判斷一個(gè)實(shí)體能不能當(dāng)資源我有一個(gè)很笨但很有效的檢查辦法問自己一句——“它有沒有存量它能不能在一個(gè)事件里減少又在另一個(gè)事件里增加”如果答案是肯定的它才可能成為資源。比如“商品”有庫存可以被出庫減少被入庫增加所以它是資源?！吧唐访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)不對勁。商品表里的條碼、名稱、規(guī)格是靜態(tài)主數(shù)據(jù)屬于商品實(shí)體的描述真正會(huì)隨業(yè)務(wù)變化的是“某倉某商品的可售庫存”。所以落地時(shí)我把商品主數(shù)據(jù)和庫存資源分開了商品存描述庫存作為資源跟著事件走。資源表只記錄“有什么東西可被業(yè)務(wù)增減”不承擔(dān)字典表的職責(zé)。2.2 事件不是所有操作都能成為事件事件是REA最核心的表也是我重新建模時(shí)花時(shí)間最多的部分。它對應(yīng)的是業(yè)務(wù)過程中讓資源發(fā)生流入或流出的動(dòng)作。比如“客戶付款”讓現(xiàn)金資源流入“倉庫發(fā)貨”讓商品庫存流出“采購收貨”讓庫存流入。一個(gè)事件至少要改變一個(gè)資源的數(shù)量這是進(jìn)入事件表的硬門檻。我第一次建模時(shí)犯過一個(gè)錯(cuò)誤把“用戶點(diǎn)擊下單按鈕”記錄成了一個(gè)事件。點(diǎn)擊只是操作痕跡它并沒有讓任何經(jīng)濟(jì)資源發(fā)生增減也不會(huì)產(chǎn)生法律義務(wù)。真正的“下單”其實(shí)是一個(gè)承諾事件它讓商家對客戶產(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ì)直接讓庫存變少除非審核之后緊跟一個(gè)“出庫”動(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ì)誰對事件負(fù)有直接責(zé)任誰在事件中擁有或接收資源。舉個(gè)例子“客戶下訂單”這個(gè)事件參與者有客戶和銷售員?？蛻羰峭獠繀⑴c者他承諾付款銷售員是內(nèi)部參與者他負(fù)責(zé)跟進(jìn)訂單。到了“收款”事件客戶付款財(cái)務(wù)人員確認(rèn)入賬。客戶是資源流出方財(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)限和績效追溯外部參與者用于對賬和客戶往來。中間還加了一層“參與角色”的概念同一參與者可以在不同事件里扮演不同角色。前期多花一點(diǎn)時(shí)間理清參與者的角色邊界后面寫權(quán)限、報(bào)表、責(zé)任追溯時(shí)會(huì)非常順。3. 一個(gè)訂單業(yè)務(wù)的完整推演從需求清單到REA模型前面講的是概念這一章我直接用一個(gè)簡化版的訂單業(yè)務(wù)場景走一遍完整建模流程。場景很典型客戶瀏覽商品、下單、倉庫發(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ù)庫設(shè)計(jì)工具而是先在白板上把業(yè)務(wù)過程里所有能被稱為“動(dòng)作”的東西列出來。這個(gè)階段要求先放開“表”“字段”“狀態(tài)機(jī)”的概念純從業(yè)務(wù)行為出發(fā)把角色做了什么事、資源發(fā)生了什么變化都寫清楚。以訂單場景為例列出來的動(dòng)作大致有客戶瀏覽商品、客戶提交訂單、系統(tǒng)扣除庫存、倉庫揀貨、倉庫發(fā)貨、物流配送、客戶確認(rèn)收貨、客戶發(fā)起支付、支付渠道回調(diào)、財(cái)務(wù)確認(rèn)收款、開具發(fā)票、申請退款、審批退款、退款完成。這些動(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)所以第二步是給候選事件一一配對資源標(biāo)注流入方向還是流出方向并說明對應(yīng)什么價(jià)值。“客戶提交訂單”這個(gè)動(dòng)作從REA角度屬于承諾事件它不直接讓庫存減少但建立了一項(xiàng)義務(wù)企業(yè)承諾交付商品客戶承諾交付現(xiàn)金。這個(gè)承諾如果要建?？梢猿橄鬄椤敖桓冻兄Z”和“付款承諾”兩種資源但在第一版我建議不用強(qiáng)建模先把實(shí)際買賣雙方的真實(shí)動(dòng)作梳理清楚?！皞}庫發(fā)貨”是明確的經(jīng)濟(jì)事件商品庫存這個(gè)資源發(fā)生流出方向?yàn)閛ut與此同時(shí)企業(yè)付出了一項(xiàng)“銷售成本”也是資源流出。很多系統(tǒng)只記錄了庫存減少忽略了銷售成本結(jié)果后期的毛利分析完全沒法做。REA的好處在于它會(huì)逼著你去想這個(gè)事件除了庫存外還動(dòng)了哪些資源。“客戶付款”則讓現(xiàn)金資源流入方向?yàn)閕n同時(shí)客戶的“應(yīng)付義務(wù)”減少這又是一種資源變化。開票事件對應(yīng)的是“應(yīng)收義務(wù)”的確認(rèn)和稅金的產(chǎn)生。一路梳理下來事件和資源的映射就能落到表里事件資源變化方向價(jià)值體現(xiàn)提交訂單交付承諾 / 付款承諾流入流出建立雙方義務(wù)倉庫發(fā)貨商品庫存流出銷售成本客戶付款現(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)“倉庫發(fā)貨”是倉庫操作員執(zhí)行倉管負(fù)責(zé)人審核“客戶付款”是客戶發(fā)起支付財(cái)務(wù)人員確認(rèn)到賬。不同的事件內(nèi)外部參與者的邊界不一樣。把這些對應(yīng)關(guān)系整理成一張責(zé)任矩陣后面做權(quán)限、審批流、業(yè)績歸屬都會(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ì)做一道很通用的體檢題對每個(gè)資源把流入總量加起來減去流出總量應(yīng)該等于這個(gè)資源的“期初存量 期末存量”變化。換句話說不能有流入沒有來源也不希望有流出沒有去處。我拿庫存資源驗(yàn)證采購入庫的流入之和減去銷售出庫、報(bào)損出庫、盤虧出庫的流出之和應(yīng)該等于期末庫存。如果算出來不對就說明要么事件清單漏了要么事件關(guān)聯(lián)錯(cuò)了資源方向。這道體檢題的價(jià)值在于它能在寫代碼之前就暴露業(yè)務(wù)理解的漏洞而不是等上線之后讓對賬來背鍋。我實(shí)際跑下來最常發(fā)現(xiàn)的問題是“退貨”事件方向填反。客戶退貨導(dǎo)致庫存流入同時(shí)要退款給客戶現(xiàn)金流出。一正一反兩個(gè)資源都要?jiǎng)尤绻r(shí)只記錄了庫存流入、漏了現(xiàn)金流出恒等式當(dāng)場就能發(fā)現(xiàn)總資產(chǎn)平不了。這就是REA建模比普通ER設(shè)計(jì)有用的地方它能通過經(jīng)濟(jì)恒等式自檢而不是等數(shù)據(jù)錯(cuò)亂后再修。4. 落地關(guān)系型數(shù)據(jù)庫表怎么拆余額怎么算模型圖畫完接下來是真刀真槍的數(shù)據(jù)庫設(shè)計(jì)。我之前見過很多REA相關(guān)的文章都在概念層面打轉(zhuǎn)一到建表就語焉不詳。這邊我把實(shí)際能用的一組表結(jié)構(gòu)分享出來并把其中的關(guān)鍵設(shè)計(jì)原因講清楚。不需要用特別復(fù)雜的數(shù)據(jù)庫一套PostgreSQL足夠其他關(guān)系型數(shù)據(jù)庫可以平移。4.1 核心表結(jié)構(gòu)事件為主資源、參與者為輔我的落地庫表結(jié)構(gòu)圍繞三張中心表展開economic_eventresourceagent再配三張關(guān)聯(lián)表event_resourceevent_agentevent_link。第一張中心表是事件表字段包括事件類型、業(yè)務(wù)時(shí)間、業(yè)務(wù)參考號等。事件表里不冗余存參與者ID和資源ID統(tǒng)一通過關(guān)聯(lián)表掛接目的是讓“一個(gè)事件可以涉及多個(gè)資源、多個(gè)參與者”這件事變得自然。比如“倉庫發(fā)貨”事件可能同時(shí)涉及多個(gè)SKU如果每個(gè)SKU的庫存變化都拆成獨(dú)立事件粒度太碎后期核對訂單維度就很麻煩。用事件主表和資源明細(xì)關(guān)聯(lián)表一個(gè)發(fā)貨單對應(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字段。它存在的原因很簡單庫存數(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ā)貨”的多對多關(guān)系。沒有這張表后面做對賬時(shí)又要回到“通過訂單號反查”的老路等于把事件之間的業(yè)務(wù)聯(lián)系又丟給了應(yīng)用層。4.2 庫存和余額不靠字段存靠事件聚合算這是REA落地時(shí)最容易引發(fā)爭議的一條因?yàn)樾阅軋F(tuán)隊(duì)通常會(huì)抱怨“每次算庫存都SUM整個(gè)表數(shù)據(jù)量大怎么辦”我的回答很直接第一事件表是追加式數(shù)據(jù)幾乎不更新可以靠索引優(yōu)化第二可以建立物化視圖或每日匯總表但結(jié)算依據(jù)仍然是事件明細(xì)而不是一個(gè)隨手改的“庫存字段”。拿庫存舉例真正的當(dāng)前庫存是資源表上的一個(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ì)重新算出來?！坝囝~”和“庫存”一樣屬于事件聚合出的推導(dǎo)值。每個(gè)客戶的應(yīng)收余額等于所有銷售事件產(chǎn)生的應(yīng)收增加減去所有收款事件產(chǎn)生的應(yīng)收減少再減去退款產(chǎn)生的影響。用事件聚合算余額最大的好處是對賬不再是“兩邊余額比大小”而是“兩邊的事件序列是否一致”。哪怕兩邊余額碰巧相等只要中間少了一條事件也能通過事件序列比較發(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)識支付單號、發(fā)貨單號、采購入庫單號。業(yè)務(wù)上同一筆支付只有一個(gè)支付單號數(shù)據(jù)庫層面用唯一約束直接攔住第二次插入比應(yīng)用層判斷更可靠。ALTER TABLE economic_event ADD CONSTRAINT uk_event_business_ref UNIQUE (business_ref_no);還有一個(gè)細(xì)節(jié)業(yè)務(wù)參考號字段必須由上游業(yè)務(wù)系統(tǒng)生成而不是由事件記錄系統(tǒng)自己生成。原因很簡單只有上游生成的單號才能代表“真實(shí)世界的同一筆業(yè)務(wù)”。如果是事件表自己用自增ID做判斷那么同一筆業(yè)務(wù)在兩個(gè)環(huán)境里就會(huì)擁有不同ID冪等約束就形同虛設(shè)。針對極端并發(fā)場景還可以在event_resource表上加“同一事件同一資源只能有一個(gè)方向的減記”這類約束防止同一張發(fā)貨單不小心關(guān)聯(lián)了同一SKU的兩條流出記錄。這類約束看起來繁瑣但每一個(gè)都是對“重復(fù)入賬”這個(gè)坑的主動(dòng)防御。4.4 對賬不再是對余額而是對事件序列傳統(tǒng)對賬方式系統(tǒng)余額 vs 銀行/倉庫賬面余額兩邊各自算一個(gè)期末數(shù)比較是否相等。REA落地后我把它改成了事件序列比對。具體做法是把系統(tǒng)內(nèi)的收款事件按業(yè)務(wù)參考號、金額、時(shí)間導(dǎo)出一份清單把銀行渠道流水也按同樣的口徑導(dǎo)出一份清單然后逐筆匹配。匹配不上的不是“最終余額不對”而是“中間有一筆差異”定位到具體是哪一筆的時(shí)間點(diǎn)通常很快就能找到原因。這種模式在數(shù)據(jù)庫層面的表達(dá)是一個(gè)簡單的“未匹配事件”查詢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ù)雜但核心思路不變對賬系統(tǒng)變成“找兩邊事件集合的差集”而不是“比較兩個(gè)標(biāo)量余額”。我做了這次改造以后財(cái)務(wù)同事反饋?zhàn)疃嗟囊痪湓捠恰敖K于知道差在哪一筆了”而不是以前那種“數(shù)量對上就行具體哪筆再說”。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)營添加備注”都做成了事件關(guān)聯(lián)到訂單。結(jié)果模型變得越來越重滿屏都是“事件”業(yè)務(wù)方卻看不懂任何一條事件的價(jià)值。后來我把粒度原則收斂成一句話只有會(huì)改變資源數(shù)量或法律義務(wù)的動(dòng)作才被認(rèn)定為經(jīng)濟(jì)事件其他作為操作日志保存關(guān)聯(lián)訂單號即可。粒度失控還會(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)單號、物流軌跡、圖片審核、風(fēng)控規(guī)則命中這些要么是法規(guī)要求要么是流程控制要么是機(jī)器學(xué)習(xí)推斷它們不直接交換經(jīng)濟(jì)資源硬塞進(jìn)去只會(huì)讓模型變得又長又難懂。我的處理方式是把系統(tǒng)分成兩層經(jīng)濟(jì)核心層和業(yè)務(wù)支撐層。經(jīng)濟(jì)核心層使用REA承載訂單、庫存、資金、應(yīng)收應(yīng)付業(yè)務(wù)支撐層保存物流軌跡、風(fēng)控記錄、審核步驟通過事件ID和經(jīng)濟(jì)核心層關(guān)聯(lián)。這兩層共用一套主數(shù)據(jù)但不互相污染。這樣REA模型保持精簡支撐層的豐富信息也不丟失。5.3 與常規(guī)CRUD開發(fā)的思維沖突最后要提醒的是心態(tài)問題。習(xí)慣了CRUD開發(fā)的同事遇到REA會(huì)有一種強(qiáng)烈的“不舒服”為什么“更新庫存”不是UPDATE一個(gè)庫存表而是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ì)的成員沒有這種意識哪怕表結(jié)構(gòu)設(shè)計(jì)成REA編碼時(shí)他們也會(huì)想方設(shè)法繞過事件表去存一個(gè)“方便”的狀態(tài)字段最后模型依然會(huì)老化回舊形態(tài)。我的建議是導(dǎo)入REA模型的初期不要急著動(dòng)所有模塊先選一個(gè)對追溯要求高的模塊試點(diǎn)比如應(yīng)收對賬或庫存流水。跑通一輪后再把經(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í)慣比任何建模工具都管用。 REA模型重構(gòu)訂單系統(tǒng)：用事件溯源解決對賬與審計(jì)難題
1. 為什么我會(huì)把一個(gè)訂單系統(tǒng)推翻重做舊模型的兩個(gè)死穴前一陣我把一個(gè)后臺系統(tǒng)的訂單模塊整個(gè)推倒重來了。原因不是業(yè)務(wù)代碼寫得亂而是數(shù)據(jù)模型根本撐不住對賬和審計(jì)。那套舊方案很常見訂單表一行數(shù)據(jù)上面掛一個(gè)狀態(tài)字段從“待支付”到“已支付”再到“已發(fā)貨”狀態(tài)一變更新一下字段前端的進(jìn)度條跟著走。表面看沒問題可一旦出現(xiàn)部分退款、贈(zèng)品抵扣、壞賬核銷、換貨這行訂單記錄就變成了一堆狀態(tài)來回橫跳的怪胎。真正壓垮我的場景是這樣的某個(gè)客戶有一筆訂單系統(tǒng)里顯示“已關(guān)閉”財(cái)務(wù)卻堅(jiān)持說這筆錢已經(jīng)收到了。兩邊打開后臺一對訂單狀態(tài)是關(guān)閉但支付流水表里確實(shí)有一筆入賬記錄。這個(gè)“已關(guān)閉”到底是誰關(guān)的關(guān)閉之前發(fā)生過什么當(dāng)時(shí)庫里的余額為什么和銀行流水對不上沒人能從一個(gè)狀態(tài)字段里找出答案只能去翻日志、查操作記錄一個(gè)晚上就這么沒了。1.1 狀態(tài)字段越長業(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)?；ハ嗝?。比如倉庫已經(jīng)掃描出庫物流單也生成了訂單狀態(tài)卻還停在“待發(fā)貨”或者“處理中”。狀態(tài)字段一旦和真實(shí)世界的動(dòng)作脫節(jié)后面所有基于狀態(tài)的統(tǒng)計(jì)、對賬、報(bào)表都會(huì)失真。我后來意識到問題不在狀態(tài)機(jī)的定義而在我們根本沒有一個(gè)穩(wěn)定的數(shù)據(jù)載體去描述“動(dòng)作”本身。1.2 “余額對不上”是最低成本的失敗方式另一個(gè)讓我下定決心重做的原因是庫存和資金余額的對賬。很多系統(tǒng)喜歡在表里直接存一個(gè)“當(dāng)前庫存”字段、一個(gè)“賬戶余額”字段每次業(yè)務(wù)動(dòng)作發(fā)生時(shí)加減它。看似高效實(shí)際等于把計(jì)算結(jié)果和業(yè)務(wù)發(fā)生過程混在了一起。一旦出現(xiàn)并發(fā)超賣、重復(fù)回調(diào)、手工改庫存余額和真實(shí)情況不一致就成了必然。我記得有一次排查庫存差異賬上顯示有貨倉庫實(shí)際沒有。查來查去最后發(fā)現(xiàn)是有個(gè)測試操作直接改了庫存字段的值既沒有留下業(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)目代號我直接用了REA。它的核心思想概括起來就一句話不要用“余額”或“當(dāng)前狀態(tài)”作為建模中心而是用“事件”作為建模中心資源從哪來、到哪去參與者是誰、有什么責(zé)任全部繞著事件記錄展開。這套思路解決了我上面遇到的兩個(gè)死穴事件記錄了過程等價(jià)于把電影的關(guān)鍵鏡頭都保留下來余額不再是一個(gè)被直接修改的字段而是通過事件記錄聚合計(jì)算出來的推導(dǎo)值。誰改過余額、在哪一單改的、為什么改在REA模型里都是一條條明確的事件。我把這個(gè)項(xiàng)目的整個(gè)推演過程、數(shù)據(jù)庫落地方案、踩過的坑都整理在這里。如果你也在做訂單、庫存、財(cái)務(wù)對賬類系統(tǒng)或者只是覺得當(dāng)前數(shù)據(jù)模型在面對業(yè)務(wù)追溯時(shí)使不上勁這套思路值得參考。它并不是銀彈但確實(shí)讓我的系統(tǒng)從“猜謎式查賬”變成了“鏈條式追溯”。2. 資源、事件、參與者三要素的邊界比想象中難劃REA模型聽起來簡單資源、事件、參與者三個(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í)、倉庫庫存甚至可以是某種必須消耗的物料。判斷一個(gè)實(shí)體能不能當(dāng)資源我有一個(gè)很笨但很有效的檢查辦法問自己一句——“它有沒有存量它能不能在一個(gè)事件里減少又在另一個(gè)事件里增加”如果答案是肯定的它才可能成為資源。比如“商品”有庫存可以被出庫減少被入庫增加所以它是資源?！吧唐访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)不對勁。商品表里的條碼、名稱、規(guī)格是靜態(tài)主數(shù)據(jù)屬于商品實(shí)體的描述真正會(huì)隨業(yè)務(wù)變化的是“某倉某商品的可售庫存”。所以落地時(shí)我把商品主數(shù)據(jù)和庫存資源分開了商品存描述庫存作為資源跟著事件走。資源表只記錄“有什么東西可被業(yè)務(wù)增減”不承擔(dān)字典表的職責(zé)。2.2 事件不是所有操作都能成為事件事件是REA最核心的表也是我重新建模時(shí)花時(shí)間最多的部分。它對應(yīng)的是業(yè)務(wù)過程中讓資源發(fā)生流入或流出的動(dòng)作。比如“客戶付款”讓現(xiàn)金資源流入“倉庫發(fā)貨”讓商品庫存流出“采購收貨”讓庫存流入。一個(gè)事件至少要改變一個(gè)資源的數(shù)量這是進(jìn)入事件表的硬門檻。我第一次建模時(shí)犯過一個(gè)錯(cuò)誤把“用戶點(diǎn)擊下單按鈕”記錄成了一個(gè)事件。點(diǎn)擊只是操作痕跡它并沒有讓任何經(jīng)濟(jì)資源發(fā)生增減也不會(huì)產(chǎn)生法律義務(wù)。真正的“下單”其實(shí)是一個(gè)承諾事件它讓商家對客戶產(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ì)直接讓庫存變少除非審核之后緊跟一個(gè)“出庫”動(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ì)誰對事件負(fù)有直接責(zé)任誰在事件中擁有或接收資源。舉個(gè)例子“客戶下訂單”這個(gè)事件參與者有客戶和銷售員?？蛻羰峭獠繀⑴c者他承諾付款銷售員是內(nèi)部參與者他負(fù)責(zé)跟進(jìn)訂單。到了“收款”事件客戶付款財(cái)務(wù)人員確認(rèn)入賬。客戶是資源流出方財(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)限和績效追溯外部參與者用于對賬和客戶往來。中間還加了一層“參與角色”的概念同一參與者可以在不同事件里扮演不同角色。前期多花一點(diǎn)時(shí)間理清參與者的角色邊界后面寫權(quán)限、報(bào)表、責(zé)任追溯時(shí)會(huì)非常順。3. 一個(gè)訂單業(yè)務(wù)的完整推演從需求清單到REA模型前面講的是概念這一章我直接用一個(gè)簡化版的訂單業(yè)務(wù)場景走一遍完整建模流程。場景很典型客戶瀏覽商品、下單、倉庫發(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ù)庫設(shè)計(jì)工具而是先在白板上把業(yè)務(wù)過程里所有能被稱為“動(dòng)作”的東西列出來。這個(gè)階段要求先放開“表”“字段”“狀態(tài)機(jī)”的概念純從業(yè)務(wù)行為出發(fā)把角色做了什么事、資源發(fā)生了什么變化都寫清楚。以訂單場景為例列出來的動(dòng)作大致有客戶瀏覽商品、客戶提交訂單、系統(tǒng)扣除庫存、倉庫揀貨、倉庫發(fā)貨、物流配送、客戶確認(rèn)收貨、客戶發(fā)起支付、支付渠道回調(diào)、財(cái)務(wù)確認(rèn)收款、開具發(fā)票、申請退款、審批退款、退款完成。這些動(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)所以第二步是給候選事件一一配對資源標(biāo)注流入方向還是流出方向并說明對應(yīng)什么價(jià)值。“客戶提交訂單”這個(gè)動(dòng)作從REA角度屬于承諾事件它不直接讓庫存減少但建立了一項(xiàng)義務(wù)企業(yè)承諾交付商品客戶承諾交付現(xiàn)金。這個(gè)承諾如果要建?？梢猿橄鬄椤敖桓冻兄Z”和“付款承諾”兩種資源但在第一版我建議不用強(qiáng)建模先把實(shí)際買賣雙方的真實(shí)動(dòng)作梳理清楚?！皞}庫發(fā)貨”是明確的經(jīng)濟(jì)事件商品庫存這個(gè)資源發(fā)生流出方向?yàn)閛ut與此同時(shí)企業(yè)付出了一項(xiàng)“銷售成本”也是資源流出。很多系統(tǒng)只記錄了庫存減少忽略了銷售成本結(jié)果后期的毛利分析完全沒法做。REA的好處在于它會(huì)逼著你去想這個(gè)事件除了庫存外還動(dòng)了哪些資源。“客戶付款”則讓現(xiàn)金資源流入方向?yàn)閕n同時(shí)客戶的“應(yīng)付義務(wù)”減少這又是一種資源變化。開票事件對應(yīng)的是“應(yīng)收義務(wù)”的確認(rèn)和稅金的產(chǎn)生。一路梳理下來事件和資源的映射就能落到表里事件資源變化方向價(jià)值體現(xiàn)提交訂單交付承諾 / 付款承諾流入流出建立雙方義務(wù)倉庫發(fā)貨商品庫存流出銷售成本客戶付款現(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)“倉庫發(fā)貨”是倉庫操作員執(zhí)行倉管負(fù)責(zé)人審核“客戶付款”是客戶發(fā)起支付財(cái)務(wù)人員確認(rèn)到賬。不同的事件內(nèi)外部參與者的邊界不一樣。把這些對應(yīng)關(guān)系整理成一張責(zé)任矩陣后面做權(quán)限、審批流、業(yè)績歸屬都會(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ì)做一道很通用的體檢題對每個(gè)資源把流入總量加起來減去流出總量應(yīng)該等于這個(gè)資源的“期初存量 期末存量”變化。換句話說不能有流入沒有來源也不希望有流出沒有去處。我拿庫存資源驗(yàn)證采購入庫的流入之和減去銷售出庫、報(bào)損出庫、盤虧出庫的流出之和應(yīng)該等于期末庫存。如果算出來不對就說明要么事件清單漏了要么事件關(guān)聯(lián)錯(cuò)了資源方向。這道體檢題的價(jià)值在于它能在寫代碼之前就暴露業(yè)務(wù)理解的漏洞而不是等上線之后讓對賬來背鍋。我實(shí)際跑下來最常發(fā)現(xiàn)的問題是“退貨”事件方向填反。客戶退貨導(dǎo)致庫存流入同時(shí)要退款給客戶現(xiàn)金流出。一正一反兩個(gè)資源都要?jiǎng)尤绻r(shí)只記錄了庫存流入、漏了現(xiàn)金流出恒等式當(dāng)場就能發(fā)現(xiàn)總資產(chǎn)平不了。這就是REA建模比普通ER設(shè)計(jì)有用的地方它能通過經(jīng)濟(jì)恒等式自檢而不是等數(shù)據(jù)錯(cuò)亂后再修。4. 落地關(guān)系型數(shù)據(jù)庫表怎么拆余額怎么算模型圖畫完接下來是真刀真槍的數(shù)據(jù)庫設(shè)計(jì)。我之前見過很多REA相關(guān)的文章都在概念層面打轉(zhuǎn)一到建表就語焉不詳。這邊我把實(shí)際能用的一組表結(jié)構(gòu)分享出來并把其中的關(guān)鍵設(shè)計(jì)原因講清楚。不需要用特別復(fù)雜的數(shù)據(jù)庫一套PostgreSQL足夠其他關(guān)系型數(shù)據(jù)庫可以平移。4.1 核心表結(jié)構(gòu)事件為主資源、參與者為輔我的落地庫表結(jié)構(gòu)圍繞三張中心表展開economic_eventresourceagent再配三張關(guān)聯(lián)表event_resourceevent_agentevent_link。第一張中心表是事件表字段包括事件類型、業(yè)務(wù)時(shí)間、業(yè)務(wù)參考號等。事件表里不冗余存參與者ID和資源ID統(tǒng)一通過關(guān)聯(lián)表掛接目的是讓“一個(gè)事件可以涉及多個(gè)資源、多個(gè)參與者”這件事變得自然。比如“倉庫發(fā)貨”事件可能同時(shí)涉及多個(gè)SKU如果每個(gè)SKU的庫存變化都拆成獨(dú)立事件粒度太碎后期核對訂單維度就很麻煩。用事件主表和資源明細(xì)關(guān)聯(lián)表一個(gè)發(fā)貨單對應(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字段。它存在的原因很簡單庫存數(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ā)貨”的多對多關(guān)系。沒有這張表后面做對賬時(shí)又要回到“通過訂單號反查”的老路等于把事件之間的業(yè)務(wù)聯(lián)系又丟給了應(yīng)用層。4.2 庫存和余額不靠字段存靠事件聚合算這是REA落地時(shí)最容易引發(fā)爭議的一條因?yàn)樾阅軋F(tuán)隊(duì)通常會(huì)抱怨“每次算庫存都SUM整個(gè)表數(shù)據(jù)量大怎么辦”我的回答很直接第一事件表是追加式數(shù)據(jù)幾乎不更新可以靠索引優(yōu)化第二可以建立物化視圖或每日匯總表但結(jié)算依據(jù)仍然是事件明細(xì)而不是一個(gè)隨手改的“庫存字段”。拿庫存舉例真正的當(dāng)前庫存是資源表上的一個(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ì)重新算出來?！坝囝~”和“庫存”一樣屬于事件聚合出的推導(dǎo)值。每個(gè)客戶的應(yīng)收余額等于所有銷售事件產(chǎn)生的應(yīng)收增加減去所有收款事件產(chǎn)生的應(yīng)收減少再減去退款產(chǎn)生的影響。用事件聚合算余額最大的好處是對賬不再是“兩邊余額比大小”而是“兩邊的事件序列是否一致”。哪怕兩邊余額碰巧相等只要中間少了一條事件也能通過事件序列比較發(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)識支付單號、發(fā)貨單號、采購入庫單號。業(yè)務(wù)上同一筆支付只有一個(gè)支付單號數(shù)據(jù)庫層面用唯一約束直接攔住第二次插入比應(yīng)用層判斷更可靠。ALTER TABLE economic_event ADD CONSTRAINT uk_event_business_ref UNIQUE (business_ref_no);還有一個(gè)細(xì)節(jié)業(yè)務(wù)參考號字段必須由上游業(yè)務(wù)系統(tǒng)生成而不是由事件記錄系統(tǒng)自己生成。原因很簡單只有上游生成的單號才能代表“真實(shí)世界的同一筆業(yè)務(wù)”。如果是事件表自己用自增ID做判斷那么同一筆業(yè)務(wù)在兩個(gè)環(huán)境里就會(huì)擁有不同ID冪等約束就形同虛設(shè)。針對極端并發(fā)場景還可以在event_resource表上加“同一事件同一資源只能有一個(gè)方向的減記”這類約束防止同一張發(fā)貨單不小心關(guān)聯(lián)了同一SKU的兩條流出記錄。這類約束看起來繁瑣但每一個(gè)都是對“重復(fù)入賬”這個(gè)坑的主動(dòng)防御。4.4 對賬不再是對余額而是對事件序列傳統(tǒng)對賬方式系統(tǒng)余額 vs 銀行/倉庫賬面余額兩邊各自算一個(gè)期末數(shù)比較是否相等。REA落地后我把它改成了事件序列比對。具體做法是把系統(tǒng)內(nèi)的收款事件按業(yè)務(wù)參考號、金額、時(shí)間導(dǎo)出一份清單把銀行渠道流水也按同樣的口徑導(dǎo)出一份清單然后逐筆匹配。匹配不上的不是“最終余額不對”而是“中間有一筆差異”定位到具體是哪一筆的時(shí)間點(diǎn)通常很快就能找到原因。這種模式在數(shù)據(jù)庫層面的表達(dá)是一個(gè)簡單的“未匹配事件”查詢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ù)雜但核心思路不變對賬系統(tǒng)變成“找兩邊事件集合的差集”而不是“比較兩個(gè)標(biāo)量余額”。我做了這次改造以后財(cái)務(wù)同事反饋?zhàn)疃嗟囊痪湓捠恰敖K于知道差在哪一筆了”而不是以前那種“數(shù)量對上就行具體哪筆再說”。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)營添加備注”都做成了事件關(guān)聯(lián)到訂單。結(jié)果模型變得越來越重滿屏都是“事件”業(yè)務(wù)方卻看不懂任何一條事件的價(jià)值。后來我把粒度原則收斂成一句話只有會(huì)改變資源數(shù)量或法律義務(wù)的動(dòng)作才被認(rèn)定為經(jīng)濟(jì)事件其他作為操作日志保存關(guān)聯(lián)訂單號即可。粒度失控還會(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)單號、物流軌跡、圖片審核、風(fēng)控規(guī)則命中這些要么是法規(guī)要求要么是流程控制要么是機(jī)器學(xué)習(xí)推斷它們不直接交換經(jīng)濟(jì)資源硬塞進(jìn)去只會(huì)讓模型變得又長又難懂。我的處理方式是把系統(tǒng)分成兩層經(jīng)濟(jì)核心層和業(yè)務(wù)支撐層。經(jīng)濟(jì)核心層使用REA承載訂單、庫存、資金、應(yīng)收應(yīng)付業(yè)務(wù)支撐層保存物流軌跡、風(fēng)控記錄、審核步驟通過事件ID和經(jīng)濟(jì)核心層關(guān)聯(lián)。這兩層共用一套主數(shù)據(jù)但不互相污染。這樣REA模型保持精簡支撐層的豐富信息也不丟失。5.3 與常規(guī)CRUD開發(fā)的思維沖突最后要提醒的是心態(tài)問題。習(xí)慣了CRUD開發(fā)的同事遇到REA會(huì)有一種強(qiáng)烈的“不舒服”為什么“更新庫存”不是UPDATE一個(gè)庫存表而是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ì)的成員沒有這種意識哪怕表結(jié)構(gòu)設(shè)計(jì)成REA編碼時(shí)他們也會(huì)想方設(shè)法繞過事件表去存一個(gè)“方便”的狀態(tài)字段最后模型依然會(huì)老化回舊形態(tài)。我的建議是導(dǎo)入REA模型的初期不要急著動(dòng)所有模塊先選一個(gè)對追溯要求高的模塊試點(diǎn)比如應(yīng)收對賬或庫存流水。跑通一輪后再把經(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í)慣比任何建模工具都管用。