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