項(xiàng)目名寫的是 rea我在這里把它理解成 REA 業(yè)務(wù)建模方法Resource、Event、Agent。做業(yè)務(wù)系統(tǒng)的朋友應(yīng)該都有過這種經(jīng)歷訂單、庫存、財務(wù)各有一套口徑同一個“出庫”動作倉管叫發(fā)貨財務(wù)叫成本結(jié)轉(zhuǎn)客服叫物流更新。系統(tǒng)表面在跑對賬永遠(yuǎn)在補(bǔ)窟窿。我最近在一個內(nèi)部重構(gòu)項(xiàng)目下面就叫它模擬項(xiàng)目X里實(shí)踐了一輪 REA 建模體會是它不能直接給你代碼但能把“業(yè)務(wù)事實(shí)”和“數(shù)據(jù)表”之間的裂縫補(bǔ)上。這篇文章會把 REA 的核心概念、建模拆解、表設(shè)計、代碼實(shí)現(xiàn)和排查經(jīng)驗(yàn)一起講清楚適合正在做訂單、庫存、財務(wù)系統(tǒng)的產(chǎn)品、開發(fā)和架構(gòu)師參考。1. REA 到底是什么把業(yè)務(wù)從“狀態(tài)”還原成“事件”1.1 三個基礎(chǔ)元素一張圖看懂REA 的名字很直白。Resource 是有價值的資源包括商品、現(xiàn)金、銀行存款、應(yīng)收款甚至積分和知識產(chǎn)權(quán)Event 是讓資源狀態(tài)發(fā)生變化的一次動作比如銷售出庫、收款到賬Agent 是參與這個動作的個人或組織可以來自公司內(nèi)部也可以來自外部。三者的關(guān)系是一個經(jīng)濟(jì)事件至少讓一種資源流出、另一種資源流入并且至少有一個內(nèi)部代理和一個外部代理參與。舉個例子倉庫給客戶發(fā)出 1000 件商品。這個“銷售出庫”事件里流出資源是庫存商品流入資源可以拆成應(yīng)收賬款和銷售成本。外部代理是客戶內(nèi)部代理是倉管員。整個模型不去畫“訂單走到哪一步”的狀態(tài)而是用一張張事件記錄回答“誰在什么時間給了誰什么資源”。這一句話我建議讀到這先記下來后面所有設(shè)計都圍繞它展開。傳統(tǒng) ER 建模會先問“表里有哪些字段”REA 會先問“業(yè)務(wù)里有哪些動作”。前者以實(shí)體為中心后者以動作為中心。如果你只做一個簡單管理系統(tǒng)ER 建模夠用但如果系統(tǒng)需要長期承載業(yè)務(wù)規(guī)則、財務(wù)核算、審計追溯REA 的視角省掉的坑是后面幾倍的工作量。1.2 為什么事件模型比狀態(tài)機(jī)更抗變化大多數(shù)訂單系統(tǒng)是狀態(tài)機(jī)思維訂單表里有一列 status從“待支付”到“已支付”再到“已完成”。這套設(shè)計本身沒毛病可業(yè)務(wù)不會乖乖沿著狀態(tài)走。客戶可能付款后又改型號倉庫可能先發(fā)貨后補(bǔ)審批財務(wù)可能跨月才確認(rèn)收入。一旦出現(xiàn)這些情況狀態(tài)枚舉就要加分支狀態(tài)遷移代碼就要加判斷時間一長每一個狀態(tài)字段背后都藏著十幾個 if。REA 換個思路我不維護(hù)“當(dāng)前狀態(tài)”只維護(hù)“已經(jīng)發(fā)生的事實(shí)”。訂單當(dāng)前處于什么狀態(tài)完全由事件流推導(dǎo)出來。比如訂單關(guān)聯(lián)了付款事件但沒有發(fā)貨事件那它就是“已付款待發(fā)貨”如果發(fā)貨事件也有了它就是“已發(fā)貨”。新業(yè)務(wù)動作根本不需要改舊狀態(tài)機(jī)只需要新增一種事件類型并配置好它應(yīng)當(dāng)釋放和吸收哪些資源流。這個類比很像記賬軟件。狀態(tài)機(jī)像在冰箱門上貼便簽“里面有青菜”REA 像記每一筆食材買入和消耗。你隨時可以從流水里算出冰箱里還剩什么便簽就算丟了也不怕。系統(tǒng)未來的擴(kuò)展、退款、換貨、補(bǔ)差價在事件流模型里都只是新事件歷史事件依舊不變。1.3 它和會計復(fù)式記賬為什么天生一對會計上每一筆記賬憑證都必須借貸平衡。REA 的每個經(jīng)濟(jì)事件也要求資源流出和流入至少各一條兩者邏輯完全同構(gòu)。以前我問過業(yè)務(wù)同事為什么銷售出庫要在庫存系統(tǒng)和財務(wù)系統(tǒng)各錄一遍因?yàn)閮蓚€系統(tǒng)建模語言不同?，F(xiàn)在用 REA 建好事件和資源流后庫存異動、財務(wù)憑證都可以從同一張事件表派生。比如發(fā)貨事件庫存商品減少同時銷售成本增加、應(yīng)收賬款增加、銷售收入增加。這件事在庫存系統(tǒng)里叫“出庫”在財務(wù)系統(tǒng)里叫“結(jié)轉(zhuǎn)成本、確認(rèn)應(yīng)收”在業(yè)務(wù)系統(tǒng)里叫“發(fā)貨”。REA 只是把這件事記錄成若干條資源流誰都能從自己需要的視角去投影。這也是為什么我說 REA 能成為訂單、庫存、財務(wù)三套口徑之間的共同語言。2. 拿一個訂單履約場景先做業(yè)務(wù)事件拆解2.1 把流程動作逐條過一遍區(qū)分事件和承諾為了講清楚我假設(shè)一個面向企業(yè)客戶的商品銷售場景客戶下單、倉庫發(fā)貨、財務(wù)收款。流程很短但足夠暴露傳統(tǒng)建模的很多問題。先逐條列動作客戶提交訂單倉庫揀貨并發(fā)出商品財務(wù)收到貨款。這中間的“提交訂單”最容易混淆。訂單本身沒有改變?nèi)魏钨Y源只是雙方對未來資源轉(zhuǎn)移的約定。在 REA 中這叫承諾Commitment不是經(jīng)濟(jì)事件。如果把“下單”當(dāng)成事件你會發(fā)現(xiàn)它沒有資源流硬要套資源流就會把訂單余額、鎖定庫存這類派生值當(dāng)成真實(shí)資源賬就亂了。所以訂單我單獨(dú)建模為承諾表只記錄客戶要買什么、數(shù)量多少、單價多少。真正的經(jīng)濟(jì)事件從發(fā)貨開始貨物從庫存轉(zhuǎn)移給客戶同時公司對客戶的應(yīng)收賬款增加、銷售成本確認(rèn)。等到財務(wù)收款又一個獨(dú)立事件發(fā)生應(yīng)收賬款減少、銀行存款增加。業(yè)務(wù)方如果問“訂單狀態(tài)是什么”我在后臺把關(guān)聯(lián)事件按時間排序算一遍就行。2.2 給每個事件標(biāo)注資源和代理現(xiàn)在把核心事件拆出來事件流出資源流入資源外部代理內(nèi)部代理業(yè)務(wù)含義倉庫發(fā)貨庫存商品應(yīng)收賬款、銷售成本、銷售收入客戶倉管員貨物轉(zhuǎn)移確認(rèn)應(yīng)收和收入財務(wù)收款應(yīng)收賬款銀行存款客戶財務(wù)人員貨款結(jié)清應(yīng)收減少銀行增加這里有一個容易鉆牛角尖的地方銷售成本是費(fèi)用銷售收入是權(quán)益它們不是嚴(yán)格意義上的“資源賬戶”。但把會計科目當(dāng)成資源賬戶來建模是可以的關(guān)鍵是每個科目的余額隨事件變動的方向要定義清楚。應(yīng)收賬款在發(fā)貨時增加收款時減少這就是資源的流入和流出。代理方面每條事件都必須有內(nèi)部代理和外部代理。發(fā)貨事件外部代理是客戶、內(nèi)部代理是倉管員收款事件外部代理是客戶、內(nèi)部代理是財務(wù)人員。這樣一個疑問會自然消失庫存扣了沒人簽字不會代理缺失時事件根本無法完整記錄。2.3 資源賬戶與代理清單合并成一張業(yè)務(wù)地圖資源賬戶我建議單獨(dú)維護(hù)它代表公司真正要盤點(diǎn)、要記賬的對象。在這個例子里至少有五個庫存商品、應(yīng)收賬款、銷售成本、銷售收入、銀行存款。代理表維護(hù)客戶、倉管員、財務(wù)人員等主體。建模時最容易踩的坑是把代理和資源混在一個表里。比如客戶表加一個“應(yīng)收賬款余額”字段看似方便實(shí)際上客戶是代理應(yīng)收賬款是資源兩者是事件關(guān)聯(lián)起來的。如果直接給客戶掛余額每筆賬款變動都要 update 客戶表審計和歷史追溯全部丟失。代理不直接持有余額余額由資源賬戶表達(dá)代理只是參與引起資源變化的事件。把這一步做完業(yè)務(wù)地圖已經(jīng)清楚了資源賬戶是會計科目代理是參與人事件是資源和代理之間的連接點(diǎn)。后面所有表結(jié)構(gòu)都是這個邏輯模型的投影。3. 從 REA 模型到數(shù)據(jù)庫表設(shè)計的落地方案3.1 邏輯模型承諾表加事件表狀態(tài)字段退居二線落到關(guān)系型數(shù)據(jù)庫我會設(shè)計四類核心表資源賬戶表、代理表、承諾表、事件表外加事件資源流表。訂單表作為承諾表存在但訂單狀態(tài)不再作為事實(shí)依據(jù)只作為可選的聚合展示字段。事件流設(shè)計我比較建議用主事件表加子表“事件資源流”的方式。一條經(jīng)濟(jì)事件可能對應(yīng)多筆資源變動發(fā)貨事件會同時影響庫存商品、應(yīng)收賬款、銷售成本、銷售收入四個賬戶。如果把這四筆直接寫在事件表字段里擴(kuò)展性很差一旦業(yè)務(wù)再增加“稅費(fèi)”賬戶就要改表結(jié)構(gòu)。拆成子表后一個事件關(guān)聯(lián)多少資源流都行查詢用 JOIN。承諾表與事件表的關(guān)系是一對多一個訂單后續(xù)可能產(chǎn)生發(fā)貨事件、收款事件、退款事件。事件表通過 commitment_id 關(guān)聯(lián)回訂單同時持有自己的業(yè)務(wù)編號和發(fā)生時間。查詢訂單當(dāng)前狀態(tài)時把該訂單的所有事件按時間拉出來就可以推導(dǎo)。3.2 可復(fù)用的核心表結(jié)構(gòu)與 DDL下面給一套最小可用的建表 SQL已經(jīng)去除多余字段保留最能體現(xiàn) REA 思想的部分CREATE TABLE resource_account ( id BIGSERIAL PRIMARY KEY, code VARCHAR(32) NOT NULL UNIQUE, name VARCHAR(64) NOT NULL, category VARCHAR(16) NOT NULL DEFAULT ASSET, -- ASSET/LIABILITY/EQUITY/REVENUE/EXPENSE unit VARCHAR(16) NOT NULL DEFAULT CNY ); CREATE TABLE agent ( id BIGSERIAL PRIMARY KEY, agent_type VARCHAR(16) NOT NULL, -- CUSTOMER/INTERNAL name VARCHAR(128) NOT NULL, ext_id VARCHAR(64) NULL ); CREATE TABLE commitment ( id BIGSERIAL PRIMARY KEY, commitment_no VARCHAR(64) NOT NULL UNIQUE, agent_id BIGINT NOT NULL REFERENCES agent(id), total_amount NUMERIC(18,2) NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE economic_event ( id BIGSERIAL PRIMARY KEY, event_type VARCHAR(32) NOT NULL, -- SHIPMENT/RECEIPT/... commitment_id BIGINT REFERENCES commitment(id), occurred_at TIMESTAMPTZ NOT NULL, recorded_at TIMESTAMPTZ NOT NULL DEFAULT now(), external_agent_id BIGINT NOT NULL REFERENCES agent(id), internal_agent_id BIGINT NOT NULL REFERENCES agent(id), biz_no VARCHAR(64) NOT NULL, CONSTRAINT uniq_event_biz UNIQUE (event_type, biz_no) ); CREATE TABLE event_resource_flow ( id BIGSERIAL PRIMARY KEY, event_id BIGINT NOT NULL REFERENCES economic_event(id), resource_account_id BIGINT NOT NULL REFERENCES resource_account(id), flow_type VARCHAR(8) NOT NULL CHECK (flow_type IN (IN,OUT)), amount NUMERIC(18,2) NOT NULL, quantity NUMERIC(18,4) NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT now() );把事件表和資源流表分開之后好處馬上能看到。想要知道“發(fā)貨事件影響了哪些賬戶”一條 SQL 就能查出來想要知道“庫存商品賬戶所有變動”按 resource_account_id 過濾即可。同時uniq_event_biz唯一鍵非常關(guān)鍵它保證同一事件不會因?yàn)榻涌谥卦嚩貜?fù)入賬。3.3 金額、數(shù)量、時區(qū)的三類規(guī)范化約束字段設(shè)計上有幾個細(xì)節(jié)我吃了不少虧先寫在這。金額一律用NUMERIC(18,2)不要用FLOAT或DOUBLE。金額計算出現(xiàn) 0.1 加 0.2 變成 0.30000000000000004 的問題在財務(wù)系統(tǒng)里就是事故。數(shù)量字段用NUMERIC(18,4)而不是INTEGER因?yàn)樯唐酚锌赡馨粗亓?、長度計費(fèi)整數(shù)不夠用。時間字段一律TIMESTAMPTZ并且嚴(yán)格區(qū)分業(yè)務(wù)發(fā)生時間occurred_at和系統(tǒng)記錄時間recorded_at。補(bǔ)單、跨時區(qū)操作、月底沖銷的時候這兩個字段會救命。我之前遇到對賬差異追了一天發(fā)現(xiàn)是有人用now()當(dāng)業(yè)務(wù)時間一筆昨天的補(bǔ)單被算到了今天。資源流表里的金額和數(shù)量必須同用一條業(yè)務(wù)規(guī)則決定正負(fù)方向。我建議flow_typeIN表示資源賬戶余額增加flow_typeOUT表示余額減少。這樣對賬腳本只需要按方向匯總不需要在每次寫的業(yè)務(wù)代碼里判斷“這個賬戶該加還是該減”規(guī)則集中在一張配置表里。4. 核心環(huán)節(jié)實(shí)現(xiàn)從下單支付到出庫結(jié)轉(zhuǎn)4.1 創(chuàng)建承諾與發(fā)貨事件事務(wù)內(nèi)雙寫資源流創(chuàng)建承諾非常簡單只是往commitment表插一行不放業(yè)務(wù)規(guī)則不鎖庫存。真正的核心在發(fā)貨事件。發(fā)貨事件必須在一個數(shù)據(jù)庫事務(wù)里完成三件事插入economic_event、插入若干條event_resource_flow、更新庫存余額投影表。任何一步失敗都要全部回滾。我用類似這樣的偽代碼描述框架換成 Java、Python 都一樣def process_shipment(event_dto, flows): with db.transaction(): event_id insert_event(event_dto) for flow in flows: insert_flow(event_id, flow.resource_account_id, flow.flow_type, flow.amount, flow.quantity) # 更新庫存等余額投影需要加鎖 update_balance(event_dto).check_and_apply() # 生成會計憑證或庫存流水也寫在同一個事務(wù)里 generate_voucher(event_id)這里有個很容易被忽略的動作冪等。支付回調(diào)、ERP 推送都可能重復(fù)調(diào)用如果接口沒有冪等控制同一張發(fā)貨單會被插兩次事件庫存和應(yīng)收全部翻倍。辦法就是前面 DDL 里的uniq_event_biz用event_type biz_no做唯一鍵。第一次插入成功第二次插入因?yàn)槲ㄒ绘I沖突直接失敗業(yè)務(wù)端捕獲后返回“已處理”即可。很多團(tuán)隊習(xí)慣先寫業(yè)務(wù)主表再異步發(fā)消息給庫存系統(tǒng)和財務(wù)系統(tǒng)。異步?jīng)]問題但事件表和資源流表絕對不能分成兩個事務(wù)寫。一旦中間進(jìn)程崩潰事件存在但資源流不存在對賬馬上不平。把事件和資源流放進(jìn)同一個事務(wù)是 REA 落地最底線的要求。4.2 負(fù)數(shù)庫存校驗(yàn)余額表只是投影在事件模型里真實(shí)的事實(shí)是event_resource_flow表里的一條條流水庫存余額只是這些流水匯總出來的投影。理論上每次查詢庫存都可以重算但性能扛不住所以我會額外維護(hù)一張resource_balance表專門存放每個資源賬戶的最新余額。這張余額表和事件流水必須在同一個事務(wù)里更新?？蹨p庫存前先鎖定余額行SELECT quantity FROM resource_balance WHERE resource_account_id $1 FOR UPDATE;如果quantity小于要出庫的數(shù)量直接拋異?；貪L。鎖住行的目的是防止兩個發(fā)貨請求同時讀到相同的可用庫存最后超賣。事務(wù)完成后再 update 余額表把余額減掉。這個設(shè)計把“不可變事件流”和“可變投影表”結(jié)合起來了。平時查詢和校驗(yàn)都走余額表速度快出問題時從事件表重放把余額重建出來不需要相信任何一個中間狀態(tài)。我見過有人用 update 訂單狀態(tài)字段去扣庫存扣完以后連“當(dāng)初為什么扣”都查不到這屬于把投影當(dāng)成了事實(shí)早晚出事。4.3 事件回放與現(xiàn)實(shí)對賬程序?qū)~程序的核心邏輯就是按資源賬戶匯總事件流再和余額表對比。以庫存為例一天的出庫入庫流水匯總出來應(yīng)該等于期初余額加當(dāng)天的流入減流出SELECT resource_account_id, SUM(CASE WHEN flow_type IN THEN quantity ELSE 0 END) AS total_in, SUM(CASE WHEN flow_type OUT THEN quantity ELSE 0 END) AS total_out FROM event_resource_flow WHERE event_id IN ( SELECT id FROM economic_event WHERE occurred_at $1 AND occurred_at $2 ) GROUP BY resource_account_id;這個查詢結(jié)果拿給財務(wù)對賬不再需要兩邊翻 Excel。若對賬不平直接查所有資源流按事件時間一條條比對即可。財務(wù)同事曾經(jīng)問我“這個余額是怎么來的”我把事件流列表導(dǎo)出來從第一筆開始加給他看問題立刻清楚。再配合一個定時任務(wù)每天從事件表重建一次全量余額和現(xiàn)有余額表做差異比對。差異為零說明系統(tǒng)自洽差異不為零就說明某個事務(wù)里事件流和投影表沒有同步可以很快定位到具體事件和操作人。5. 常見問題與排查技巧實(shí)錄5.1 五個典型的建模錯誤在實(shí)際項(xiàng)目中最常見的問題不是代碼而是建模走偏。我整理了五個反復(fù)出現(xiàn)的錯誤第一個錯誤是把所有狀態(tài)都當(dāng)成事件。有些人把訂單狀態(tài)的每次變更都寫成 event比如“狀態(tài)從待支付變成已支付”。這不是資源流動只是狀態(tài)變化。REA 的事件必須改變資源賬戶余額沒有這種變化放進(jìn)事件表只會增加噪音還會讓對賬無從下手。第二個錯誤是單邊記錄資源流。只記錄庫存商品減少卻沒有同步記錄銷售成本或應(yīng)收賬款的增加。這樣庫存余額是準(zhǔn)的財務(wù)賬永遠(yuǎn)對不上。REA 的“每事件至少一出一入”不是理論教條是保障賬平的基本約束。第三個錯誤是直接 update 余額表。系統(tǒng)每天都把庫存余額、應(yīng)收余額直接改成新值沒有事件流。某天數(shù)據(jù)被改錯沒有任何回溯依據(jù)。事件不可變余額表只是投影這兩條原則不能動搖。第四個錯誤是把資源與代理混在一起?？蛻舯砝锓艖?yīng)收余額商品表里放庫存數(shù)量。短期看很方便長期看業(yè)務(wù)擴(kuò)展極其別扭。換貨、凍結(jié)、折扣這些動作會滲透到每一張業(yè)務(wù)表最終改無可改。第五個錯誤是忽略承諾。訂單作為承諾被簡單壓成一個狀態(tài)字段后續(xù)改價、取消、拆分都只能覆蓋原數(shù)據(jù)。一旦發(fā)生糾紛想還原當(dāng)時客戶究竟承諾了什么歷史全部丟失。把訂單做成承諾表把所有變更動作做成事件這個成本值得。5.2 三個能直接用的 SQL 排查模板排查事件完整性我常用下面這三個 SQL建議直接存到運(yùn)維工具里。第一找出資源流數(shù)量少于兩條的事件SELECT e.id, e.event_type, COUNT(f.id) AS flow_count FROM economic_event e LEFT JOIN event_resource_flow f ON f.event_id e.id GROUP BY e.id, e.event_type HAVING COUNT(f.id) 2;第二找出同一業(yè)務(wù)編號重復(fù)入庫的事件SELECT event_type, biz_no, COUNT(*) FROM economic_event GROUP BY event_type, biz_no HAVING COUNT(*) 1;第三找出資源流方向缺失的賬戶。比如某事件只有流出沒有流入但是事件表本身看起來正常SELECT e.id, e.event_type, f.flow_type FROM economic_event e JOIN event_resource_flow f ON f.event_id e.id WHERE e.id IN ( SELECT event_id FROM event_resource_flow GROUP BY event_id HAVING SUM(CASE WHEN flow_type IN THEN 1 ELSE 0 END) 0 );這三個查詢基本覆蓋了數(shù)據(jù)對不上的常見原因。我每次遇到庫存賬和財務(wù)賬差異先跑一遍這三個 SQL通常十分鐘內(nèi)能定位到問題事件。5.3 落地過程中的幾條實(shí)在建議最后給幾條建議都是我在模擬項(xiàng)目X里實(shí)際驗(yàn)證過的東西。第一事件不可更新。發(fā)現(xiàn)錯誤不要直接修改原事件而是新增一個沖正事件比如金額原本多記了就新增一個等額反方向的事件。這樣做的原因是方便回放任何時刻都可以通過事件流重建真實(shí)歷史而不是看到中間被改過的痕跡。第二業(yè)務(wù)編號要有全局意識。支付回調(diào)單號、物流單號、手工調(diào)整單號都要保證全局唯一并且入庫時使用唯一鍵兜底。系統(tǒng)集成越多重復(fù)報文就越常見靠代碼判重不如靠數(shù)據(jù)庫約束。第三小步引入不做一刀切。如果現(xiàn)有系統(tǒng)已經(jīng)很復(fù)雜不要試圖一天把所有表都改成 REA。先挑一個經(jīng)常對不平的環(huán)節(jié)比如“發(fā)貨”或“收款”建事件表和資源流表其它系統(tǒng)繼續(xù)走老邏輯。存量數(shù)據(jù)可以做一個“初始余額事件”一次性進(jìn)入新模型之后新增業(yè)務(wù)全部走事件流。等團(tuán)隊跑順了再逐步擴(kuò)展比推倒重來安全得多。最后說一點(diǎn)個人體會。REA 不是銀彈它不會自動幫你解決所有業(yè)務(wù)問題但它強(qiáng)迫你把“事實(shí)”和“狀態(tài)”分開。以前大家爭論發(fā)貨后庫存怎么減、應(yīng)收怎么確認(rèn)現(xiàn)在只需要確認(rèn)一個事件帶多少條資源流以前對賬靠兩邊系統(tǒng)導(dǎo)出 Excel現(xiàn)在直接從同一張事件表投影。這套思路不挑技術(shù)棧也不需要什么新框架有一張會寫 SQL 的表就夠起步。我自己的感覺是認(rèn)真走完一遍 REA你會重新看到很多“理所當(dāng)然”的需求背后到底缺了哪個事件。