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