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