REA 這個(gè)縮寫乍看平平無(wú)奇但做業(yè)務(wù)系統(tǒng)的人一旦理解透它很多賬實(shí)不符、流程難改的毛病都能從根上解決。REA 指資源、事件、代理三個(gè)核心概念最早來(lái)自會(huì)計(jì)信息系統(tǒng)領(lǐng)域后來(lái)因?yàn)楸磉_(dá)業(yè)務(wù)語(yǔ)義特別干凈被不少企業(yè)軟件團(tuán)隊(duì)拿去重新設(shè)計(jì)進(jìn)銷存、訂單、資產(chǎn)盤點(diǎn)甚至 CRM。這篇文章我就用實(shí)際項(xiàng)目改造的視角講講怎么把一個(gè)傳統(tǒng)表結(jié)構(gòu)的庫(kù)存系統(tǒng)逐步拆成 REA 模型以及在這個(gè)過(guò)程里我踩過(guò)的坑和總結(jié)出的設(shè)計(jì)取舍。## 1. 為什么傳統(tǒng)進(jìn)銷存系統(tǒng)“改不動(dòng)”很多中小團(tuán)隊(duì)的第一套庫(kù)存系統(tǒng)往往是從訂單表加庫(kù)存表開(kāi)始的。結(jié)構(gòu)很簡(jiǎn)單商品表、倉(cāng)庫(kù)表、入庫(kù)單、出庫(kù)單再配一堆更新庫(kù)存的定時(shí)任務(wù)或事務(wù)代碼。剛上線時(shí)挺好用一旦業(yè)務(wù)開(kāi)始加采購(gòu)、退貨、調(diào)撥、盤點(diǎn)、贈(zèng)品、損耗這些動(dòng)作麻煩就來(lái)了。1.1 傳統(tǒng)表結(jié)構(gòu)的典型困境你很容易遇到三類問(wèn)題。第一業(yè)務(wù)表越堆越多采購(gòu)單是采購(gòu)單退貨單是退貨單調(diào)撥單又是另外一張表每張表的字段長(zhǎng)得差不多但查詢和統(tǒng)計(jì)都得分別處理。第二庫(kù)存數(shù)字分散在多個(gè)地方訂單表算一次庫(kù)存出入庫(kù)表又算一次兩個(gè)口徑對(duì)不上財(cái)務(wù)和運(yùn)營(yíng)各拿各的數(shù)經(jīng)常為了一個(gè)庫(kù)存差異吵到半夜。第三業(yè)務(wù)流程一變表結(jié)構(gòu)就得跟著改比如從“先發(fā)貨后開(kāi)票”改成“先開(kāi)票后發(fā)貨”如果不重構(gòu)數(shù)據(jù)模型就只能靠一堆補(bǔ)丁接口把邏輯硬串起來(lái)。我見(jiàn)過(guò)最典型的翻車現(xiàn)場(chǎng)某團(tuán)隊(duì)為了支持“門店調(diào)撥”在出庫(kù)單上硬加了一個(gè)“調(diào)入門店”字段結(jié)果退貨、盤點(diǎn)、報(bào)廢全部按照這個(gè)字段的邏輯套最總庫(kù)存依然是錯(cuò)的。原因不是程序員寫錯(cuò)了代碼而是領(lǐng)域模型沒(méi)有把“庫(kù)存變動(dòng)”的本質(zhì)表達(dá)清楚。1.2 庫(kù)存變動(dòng)的本質(zhì)到底是什么所有業(yè)務(wù)動(dòng)作不管名字叫入庫(kù)、出庫(kù)、調(diào)撥、盤點(diǎn)、退貨還是報(bào)損本質(zhì)上都在做同一件事改變某個(gè)資源在某個(gè)主體的控制狀態(tài)。這里有兩個(gè)基本元素——資源商品、現(xiàn)金、積分和主體倉(cāng)庫(kù)、門店、供應(yīng)商、客戶、內(nèi)部部門。庫(kù)存系統(tǒng)真正要記錄的不是“現(xiàn)在有多少”而是“曾經(jīng)發(fā)生過(guò)哪些事”。傳統(tǒng)表結(jié)構(gòu)把焦點(diǎn)放在“結(jié)果”上每次出入庫(kù)都去 update 庫(kù)存表的數(shù)量字段。REA 不同它把焦點(diǎn)放在“事件”上。事件是不可再拆的業(yè)務(wù)事實(shí)比如“倉(cāng)庫(kù) A 收到供應(yīng)商 X 送來(lái)的 100 個(gè)鍵盤”。至于庫(kù)存結(jié)余是多少那是事件累加出來(lái)的視圖不是存儲(chǔ)的“唯一真相”。這個(gè)思維的轉(zhuǎn)換非常關(guān)鍵。1.3 REA 模型的三個(gè)核心概念REA 分別是 Resource資源、Event事件、Agent代理。資源是經(jīng)濟(jì)活動(dòng)中被交換、消耗、產(chǎn)出的東西比如商品、原材料、現(xiàn)金、工時(shí)。事件是與資源變動(dòng)相關(guān)的業(yè)務(wù)活動(dòng)比如“采購(gòu)入庫(kù)”“銷售出庫(kù)”“調(diào)撥出庫(kù)”“盤點(diǎn)差異調(diào)整”。代理是參與事件的個(gè)人或組織比如供應(yīng)商、客戶、倉(cāng)庫(kù)管理員、物流公司。光看概念有點(diǎn)寡淡我用賣咖啡的例子幫大家順一遍?？蛻糍I一杯拿鐵涉及到的資源是拿鐵和現(xiàn)金事件是“銷售拿鐵”和“收銀收款”代理是客戶和店員。這兩個(gè)事件一對(duì)資源和資源之間就形成了經(jīng)濟(jì)交換關(guān)系。理解到這個(gè)粒度設(shè)計(jì)表結(jié)構(gòu)時(shí)就只需要問(wèn)三個(gè)問(wèn)題資源是誰(shuí)發(fā)生了什么事件誰(shuí)參與所有業(yè)務(wù)場(chǎng)景都能往這個(gè)框子里裝。## 2. 基于 REA 建模的整體設(shè)計(jì)思路真正動(dòng)手設(shè)計(jì)前要先把團(tuán)隊(duì)認(rèn)知對(duì)齊。REA 不是銀彈它是一套讓人按業(yè)務(wù)本質(zhì)建模的方法。設(shè)計(jì)過(guò)程我從四個(gè)步驟來(lái)說(shuō)。2.1 識(shí)別資源池與事件鏈第一步是盤點(diǎn)系統(tǒng)里的核心資源。比如一套進(jìn)銷存系統(tǒng)資源通常有商品、庫(kù)存、現(xiàn)金、應(yīng)收賬款、應(yīng)付賬款。有些資源是有形庫(kù)存有些是賬面上的權(quán)益都需要單獨(dú)建模。第二步是識(shí)別事件鏈。以一筆銷售業(yè)務(wù)為例事件鏈大概是客戶下單 → 倉(cāng)管發(fā)貨 → 物流簽收 → 財(cái)務(wù)收款。每一個(gè)環(huán)節(jié)都是一個(gè)事件。REA 強(qiáng)調(diào)“一件事記一筆”不允許把多個(gè)事件揉進(jìn)一張大表。為什么要這樣因?yàn)楹罄m(xù)做統(tǒng)計(jì)時(shí)你可以從任意一個(gè)事件維度出發(fā)做透視比如只看發(fā)貨環(huán)節(jié)的時(shí)效不用撈整張訂單表。2.2 用“流入流出”定義資源增減每個(gè)事件都會(huì)對(duì)應(yīng)資源的流入或流出。采購(gòu)入庫(kù)時(shí)商品資源流入倉(cāng)庫(kù)銷售出庫(kù)時(shí)商品資源流出倉(cāng)庫(kù)。這個(gè)概念容易被忽略的是“雙向性”。比如退貨可以建模成商品流入倉(cāng)庫(kù)同時(shí)現(xiàn)金資源流出公司。在設(shè)計(jì)事件表時(shí)我建議把“資源方向”作為顯式字段。比如 direction 字段取值 in 或 out。這樣后續(xù)做匯總只需要對(duì)同一張事件表按方向分組不需要去 join 好幾張業(yè)務(wù)單表。這個(gè)字段看起來(lái)簡(jiǎn)單但能救很多命。2.3 代理層與組織權(quán)限的落法代理這個(gè)概念跟權(quán)限系統(tǒng)關(guān)系密切。每個(gè)事件必須記錄“誰(shuí)干的”“對(duì)誰(shuí)干”。比如一次盤點(diǎn)調(diào)整經(jīng)辦人是倉(cāng)管審核人是庫(kù)控主管?！罢l(shuí)干的”是執(zhí)行代理“對(duì)誰(shuí)干”是接收或影響代理。具體建表時(shí)可以用 agent_id 加 agent_type 來(lái)標(biāo)識(shí)代理類型比如 employee、supplier、customer、warehouse。倉(cāng)庫(kù)本身可以作為代理出現(xiàn)因?yàn)樗且粋€(gè)可以持有資源的實(shí)體。權(quán)限模塊不用單獨(dú)造輪子直接從事件表反查某個(gè)代理參與過(guò)哪些業(yè)務(wù)就能做數(shù)據(jù)隔離。2.4 為什么選擇 REA 而不是通用 ERP 表結(jié)構(gòu)很多通用 ERP 的表結(jié)構(gòu)參考了標(biāo)準(zhǔn)財(cái)務(wù)憑證設(shè)計(jì)其實(shí)已經(jīng)是半 REA 的思路了。比如憑證表里“借”和“貸”就是兩類事件方向科目余額就是資源匯總。但通用 ERP 對(duì)中小團(tuán)隊(duì)太重配置成本高而且改字段困難。自研系統(tǒng)如果直接按業(yè)務(wù)單據(jù)建表后面加業(yè)務(wù)類型累死。用 REA 方式建核心層外層可以自由包裝各種單據(jù)視圖既有標(biāo)準(zhǔn)化內(nèi)核又有業(yè)務(wù)柔性這是我最看重的一點(diǎn)。后面查賬、出報(bào)表、做數(shù)據(jù)分析都是在一套統(tǒng)一的事件模型上做映射不需要各個(gè)業(yè)務(wù)各寫各的報(bào)表。## 3. 核心表結(jié)構(gòu)與字段解讀模型設(shè)計(jì)清楚了接下來(lái)就是落地。這套結(jié)構(gòu)我實(shí)際部署過(guò)兩次第一版和第二版差別主要在于索引和冗余字段的取舍。下面給出我比較滿意的一版。3.1 資源表設(shè)計(jì)資源表存的是“靜態(tài)檔案”比如商品表、倉(cāng)庫(kù)表、往來(lái)單位表。這些表字段不多但必須穩(wěn)定不能三天兩頭加業(yè)務(wù)狀態(tài)。CREATE TABLE res_resource ( resource_id BIGINT PRIMARY KEY, resource_type VARCHAR(20) NOT NULL, -- PRODUCT, WAREHOUSE, CASH, RECEIVABLE resource_code VARCHAR(64) NOT NULL, resource_name VARCHAR(128) NOT NULL, owner_agent_id BIGINT, -- 當(dāng)前持有代理 unit VARCHAR(20), -- 計(jì)量單位 status VARCHAR(10) NOT NULL DEFAULT ACTIVE, extra_json JSON, created_at TIMESTAMP, updated_at TIMESTAMP );resource_type 決定資源大類unit 一定要存標(biāo)準(zhǔn)計(jì)量單位避免后續(xù)換算公斤和斤、個(gè)和箱時(shí)出錯(cuò)。owner_agent_id 代表當(dāng)前資源歸屬配合代理表可以做權(quán)限范圍控制但要注意它不是實(shí)時(shí)算出來(lái)的理論上講它只是一個(gè)緩存字段最終真相要以事件流水為準(zhǔn)。3.2 事件表設(shè)計(jì)這是整套系統(tǒng)的核心。所有庫(kù)存變動(dòng)、資金變動(dòng)都寫在這張表里。CREATE TABLE evt_event ( event_id BIGINT PRIMARY KEY, event_type VARCHAR(32) NOT NULL, -- PURCHASE_IN, SALE_OUT, TRANSFER_IN, ... resource_id BIGINT NOT NULL, direction VARCHAR(4) NOT NULL, -- IN / OUT quantity DECIMAL(18,4) NOT NULL, unit_price DECIMAL(18,4), amount DECIMAL(18,4), execute_agent_id BIGINT NOT NULL, -- 執(zhí)行代理 receive_agent_id BIGINT, -- 接收/影響代理 warehouse_id BIGINT, biz_no VARCHAR(64), -- 業(yè)務(wù)單據(jù)號(hào) ref_event_id BIGINT, -- 關(guān)聯(lián)事件用于退貨、沖正 occurred_at TIMESTAMP NOT NULL, created_at TIMESTAMP, created_by BIGINT );這張表乍一看像一個(gè)流水賬但妙就妙在它是所有業(yè)務(wù)單據(jù)的唯一數(shù)據(jù)源。采購(gòu)入庫(kù)寫一條 event_typePURCHASE_IN 且 directionIN 的記錄銷售出庫(kù)寫一條 SALE_OUT 且 directionOUT 的記錄。退貨時(shí)寫一條事件并用 ref_event_id 指向原事件。這樣做的好處是“業(yè)務(wù)單據(jù)”可以隨心所欲地改變外觀底層永遠(yuǎn)只有一套事件流。3.3 代理表與關(guān)聯(lián)關(guān)系設(shè)計(jì)代理表比較簡(jiǎn)單重點(diǎn)是 agent_type 這個(gè)字段用來(lái)區(qū)分客戶、供應(yīng)商、員工、倉(cāng)庫(kù)、門店。有時(shí)候倉(cāng)庫(kù)既是資源存儲(chǔ)地又是代理建模時(shí)容易混淆。我的建議是倉(cāng)庫(kù)作為資源存在同時(shí)把倉(cāng)庫(kù)管理員作為代理不把倉(cāng)庫(kù)本身既當(dāng)資源又當(dāng)代理否則邏輯會(huì)打架。CREATE TABLE agt_agent ( agent_id BIGINT PRIMARY KEY, agent_type VARCHAR(16) NOT NULL, agent_name VARCHAR(128) NOT NULL, ext_info JSON );關(guān)聯(lián)關(guān)系不需要單獨(dú)做一張很大的圖譜因?yàn)?REA 的事件表已經(jīng)天然攜帶了資源、執(zhí)行代理、接收代理的關(guān)聯(lián)。要查“某個(gè)客戶近三個(gè)月的所有銷售”就是在事件表上按 receive_agent_id 客戶ID 過(guò)濾。不需要額外建立關(guān)系表查詢性能也足夠好。3.4 視圖層的“庫(kù)存結(jié)余”怎么做事件表是事實(shí)庫(kù)存結(jié)余是計(jì)算結(jié)果。我建議直接用物化視圖或者定時(shí)匯總表不建議每次查詢實(shí)時(shí)跨表匯總幾百萬(wàn)條事件那樣會(huì)很慢。一個(gè)簡(jiǎn)單標(biāo)準(zhǔn)的 SQL 思路是SELECT resource_id, warehouse_id, SUM(CASE WHEN directionIN THEN quantity ELSE 0 END) AS total_in, SUM(CASE WHEN directionOUT THEN quantity ELSE 0 END) AS total_out, SUM(CASE WHEN directionIN THEN quantity ELSE -quantity END) AS balance FROM evt_event GROUP BY resource_id, warehouse_id;實(shí)際業(yè)務(wù)里我們一般維護(hù)一張 monthly_stock_summary按月、按資源、按倉(cāng)庫(kù)匯總期初加本期流入減流出查詢時(shí)只用拉最近幾個(gè)月的數(shù)據(jù)。每個(gè)月開(kāi)賬做一次快照歷史查詢直接讀快照速度很快。## 4. 實(shí)操改造把一套庫(kù)存系統(tǒng)遷移到 REA說(shuō)完了理論講講實(shí)際操作。這次改造的模擬項(xiàng)目是一個(gè)倉(cāng)庫(kù)進(jìn)銷存系統(tǒng)原來(lái)有采購(gòu)單、銷售單、調(diào)撥單、盤點(diǎn)單四張表每張表都是獨(dú)立結(jié)構(gòu)庫(kù)存更新散落在各個(gè)模塊里。改造分了三步走。4.1 加表、并行寫入、再切換查詢我沒(méi)有選擇“大爆炸”式遷移那樣風(fēng)險(xiǎn)太高。第一步只新增 REA 相關(guān)表同時(shí)保留舊表結(jié)構(gòu)讓新寫的代碼在寫入舊表的同時(shí)也往事件表里寫一條數(shù)據(jù)相當(dāng)于雙寫。這個(gè)階段跑了一周用 er_submit 對(duì)比腳本每天核對(duì)兩邊數(shù)據(jù)是否一致。雙寫階段一旦發(fā)現(xiàn)偏差基本能定位到代碼邏輯錯(cuò)誤不會(huì)影響線上業(yè)務(wù)。比如調(diào)撥業(yè)務(wù)原邏輯是從 A 倉(cāng)庫(kù)存減B 倉(cāng)庫(kù)存加新邏輯必須寫兩條事件一條方向 OUT關(guān)聯(lián)倉(cāng)庫(kù) A一條方向 IN關(guān)聯(lián)倉(cāng)庫(kù) B并且兩條事件要同一個(gè)事務(wù)提交。對(duì)比腳本的計(jì)算邏輯跟新邏輯一致這樣舊的調(diào)撥單也能逐步補(bǔ)錄成事件數(shù)據(jù)。4.2 寫事件讀視圖按業(yè)務(wù)角度重查切換查詢前先把月度匯總快照跑起來(lái)確保物化視圖和舊庫(kù)存表的數(shù)據(jù)對(duì)得上。切換后所有庫(kù)存查詢走 REA 視圖層但業(yè)務(wù)單據(jù)仍在舊表。這意味著舊系統(tǒng)可以繼續(xù)用同時(shí)新功能開(kāi)始基于事件表做擴(kuò)展比如自動(dòng)對(duì)賬、庫(kù)存周轉(zhuǎn)率分析。這里有個(gè)點(diǎn)很關(guān)鍵不要讓業(yè)務(wù)代碼直接操作 REA 事件表。我封裝了一個(gè) StockEventService對(duì)外暴露接口比如 createInboundEvent、createOutboundEvent、reverseEvent內(nèi)部負(fù)責(zé)冪等、事務(wù)和校驗(yàn)。所有業(yè)務(wù)方都走這個(gè)服務(wù)不允許有人偷偷往事件表里 insert。否則事件語(yǔ)義很快就會(huì)被“臟數(shù)據(jù)”污染。4.3 對(duì)賬與審計(jì)為什么天然順滑REA 模型最大的隱藏收益是審計(jì)追蹤。傳統(tǒng)表結(jié)構(gòu)里如果庫(kù)存數(shù)量被改錯(cuò)了你很難反查是被哪張單改的。REA 結(jié)構(gòu)里任何庫(kù)存變化都能找到對(duì)應(yīng)的事件、代理、時(shí)間和業(yè)務(wù)單據(jù)號(hào)連退貨沖正也能通過(guò) ref_event_id 串成完整鏈條。我們做了一次演練財(cái)務(wù)要求核對(duì)某個(gè) SKU 全年所有影響庫(kù)存的事件。換作以前要 join 五張業(yè)務(wù)表還得對(duì)上各自的狀態(tài)字段現(xiàn)在按 resource_id 過(guò)濾事件表半小時(shí)就交付了一份包含時(shí)間、數(shù)量、方向、經(jīng)辦人、關(guān)聯(lián)單據(jù)的完整流水。財(cái)務(wù)同事看完之后對(duì)這套結(jié)構(gòu)的接受度明顯提升了。## 5. 改造過(guò)程中的典型問(wèn)題與排查心得數(shù)據(jù)模型改造從來(lái)不缺坑這里挑幾個(gè)最有代表性的問(wèn)題記錄下來(lái)希望對(duì)正在動(dòng)手的團(tuán)隊(duì)有幫助。5.1 事件重復(fù)寫入與冪等控制雙寫階段最容易出現(xiàn)重復(fù)事件。比如某個(gè)業(yè)務(wù)方成功寫入了舊表但事件表寫入超時(shí)沒(méi)返回業(yè)務(wù)方重試結(jié)果舊表更新了一遍事件表也更新了兩遍。庫(kù)存對(duì)賬立即報(bào)錯(cuò)。我的解決辦法是給事件表增加業(yè)務(wù)唯一鍵直接拿“業(yè)務(wù)日期 業(yè)務(wù)單據(jù)號(hào) 事件類型 資源ID”做聯(lián)合唯一索引。業(yè)務(wù)服務(wù)在調(diào)用 StockEventService 前先生成維度唯一的 event_biz_key數(shù)據(jù)庫(kù)層面防重。如果發(fā)現(xiàn)重復(fù)寫入直接返回已存在的事件ID不報(bào)錯(cuò)這樣重試的動(dòng)作就變得冪等了。5.2 反向沖正時(shí)事件方向別搞反退貨或者單據(jù)作廢正確做法不是刪除原事件而是新增一條方向相反、數(shù)量為正的事件并用 ref_event_id 指向原事件。這樣原事件保留新事件明確表達(dá)“對(duì)立動(dòng)作”后續(xù)統(tǒng)計(jì)時(shí)如果同一 ref_event_id 下存在兩條方向相反的事件可以自動(dòng)互相抵消。千萬(wàn)別用“負(fù)數(shù)數(shù)量”來(lái)表示沖正。一個(gè) -5 的庫(kù)存事件和方向字段組合起來(lái)非常災(zāi)難報(bào)表上會(huì)把累計(jì)入庫(kù)和累計(jì)出庫(kù)算錯(cuò)而且排查問(wèn)題時(shí)你根本不知道一條負(fù)數(shù)記錄到底是“原事件錄錯(cuò)”還是“主動(dòng)沖正”。我吃過(guò)這個(gè)虧而且要糾正已經(jīng)污染的歷史數(shù)據(jù)很痛苦每次都得靠業(yè)務(wù)側(cè)跑手工腳本確認(rèn)。5.3 倉(cāng)庫(kù)既當(dāng)資源又當(dāng)代理的建?；煜稣{(diào)撥單時(shí)同事問(wèn)倉(cāng)庫(kù)是資源還是代理一開(kāi)始模型里把倉(cāng)庫(kù)既放進(jìn) res_resource又放進(jìn) agt_agent結(jié)果查“某倉(cāng)庫(kù)的調(diào)入記錄”時(shí)得到兩份數(shù)據(jù)一份來(lái)自資源關(guān)聯(lián)一份來(lái)自代理關(guān)聯(lián)邏輯完全對(duì)不上。后來(lái)統(tǒng)一為資源表只放商品、現(xiàn)金、應(yīng)收應(yīng)付倉(cāng)庫(kù)只作為存放位置字段 warehouse_id不作為代理參與事件。代理表只放人和組織比如員工、供應(yīng)商、客戶、物流公司。這樣模型干凈很多寫代碼時(shí)也少了一大類判斷分支。5.4 金額精度與小數(shù)位數(shù)要提前定好事件表里的 quantity 用了 DECIMAL(18,4)金額用 DECIMAL(18,4)價(jià)格用 DECIMAL(18,4)。千萬(wàn)別用 FLOAT 或 DOUBLE浮點(diǎn)數(shù)的精度問(wèn)題在財(cái)務(wù)對(duì)賬時(shí)會(huì)讓你懷疑人生。哪怕是數(shù)量為整數(shù)的商品也建議固定小數(shù)位因?yàn)槟承┥唐房赡馨粗亓砍鋈霂?kù)需要保留 3 到 4 位小數(shù)。實(shí)際中我們還發(fā)現(xiàn)客戶在下單時(shí)的金額與我們計(jì)算的金額差一分錢。原因在于單價(jià)有 4 位小數(shù)而金額可能因?yàn)槎惵十a(chǎn)生舍入差異。我們的規(guī)則是金額字段允許存 4 位小數(shù)但對(duì)外展示時(shí)按業(yè)務(wù)規(guī)則的進(jìn)位方式展示事件表保留最原始精度不做四舍五入。這個(gè)細(xì)節(jié)讓后續(xù)對(duì)賬省了非常多口舌。## 6. 這套模型后續(xù)還能擴(kuò)展什么改造完核心賬戶系統(tǒng)之后我發(fā)現(xiàn) REA 模型的可擴(kuò)展性遠(yuǎn)超預(yù)期。很多過(guò)去要新建表才能支持的場(chǎng)景現(xiàn)在只需要增加 event_type 的取值。比如把庫(kù)存借貸變成“可用庫(kù)存”和“在途庫(kù)存”兩個(gè)資源概念就可以通過(guò)事件流水區(qū)分。參考“可用”和“凍結(jié)”資源當(dāng)訂單創(chuàng)建時(shí)寫一條從可用資源到凍結(jié)資源的轉(zhuǎn)移事件訂單取消再寫一條反向轉(zhuǎn)移。再加上一個(gè)資源維度業(yè)務(wù)上的庫(kù)存預(yù)占邏輯就清晰了。再比如多幣種、多計(jì)量的場(chǎng)景事件表的 resource_id 可以指向“幣種資源”或“計(jì)量單位資源”金額做匯率換算后保存基準(zhǔn)幣金額。同一套事件模型能同時(shí)處理商品流、資金流、甚至工時(shí)流這是最讓我滿意的部分。我個(gè)人的體會(huì)是REA 模型最大的門檻不在數(shù)據(jù)庫(kù)設(shè)計(jì)而在團(tuán)隊(duì)認(rèn)知轉(zhuǎn)變。很多程序員習(xí)慣把“業(yè)務(wù)動(dòng)作”直接變成“字段”而不是變成“事件記錄”。一旦大家都接受“只記事實(shí)、由事實(shí)推導(dǎo)結(jié)果”這個(gè)共識(shí)后面的開(kāi)發(fā)效率會(huì)提升一大截。最后再分享一個(gè)心得遷移期別圖快雙寫至少跑兩個(gè)完整的業(yè)務(wù)周期把月初、月中、月末對(duì)賬都覆蓋到再切換查詢。數(shù)據(jù)模型一旦立住了后期比功能代碼復(fù)用帶來(lái)的價(jià)值高得多。