見過太多把訂單表塞滿狀態(tài)字段的系統(tǒng)了三五十個字段、十來種狀態(tài)、十幾個流程節(jié)點(diǎn)每個部門對“訂單”的理解還不一樣銷售覺得訂單是合同財(cái)務(wù)覺得訂單是發(fā)票依據(jù)倉儲覺得訂單是揀貨指令。結(jié)果就是業(yè)務(wù)一提需求開發(fā)先吵一架改一版表結(jié)構(gòu)再吵一架。后來我接觸到一個叫REA的東西——Resource-Event-Agent徹底改變了我的建模思路。它不是某個前端框架也不是新出的編程語言而是一套從會計(jì)學(xué)里走出來的業(yè)務(wù)建模方法專門用來回答“這個系統(tǒng)里到底發(fā)生了什么經(jīng)濟(jì)事件誰參與動了什么資源”。這篇文章我就從一個實(shí)踐者的角度把REA模型這套東西掰開揉碎講清楚它解決什么問題、三個核心概念怎么落地、數(shù)據(jù)模型怎么設(shè)計(jì)、服務(wù)怎么拆分、對賬怎么做以及我在實(shí)際項(xiàng)目中踩過的坑。適合正準(zhǔn)備做中臺、微服務(wù)拆分、或者被復(fù)雜業(yè)務(wù)狀態(tài)搞到頭禿的架構(gòu)師和開發(fā)者參考。1. REA模型的核心思想與行業(yè)價(jià)值1.1 REA到底是什么從會計(jì)學(xué)走出來的業(yè)務(wù)建模范式REA的全稱是Resource-Event-Agent最早是上個世紀(jì)八十年代由會計(jì)信息系統(tǒng)領(lǐng)域的研究者提出來的。傳統(tǒng)會計(jì)模型關(guān)注的是借貸分錄但REA的初衷是擺脫單純面向財(cái)務(wù)報(bào)表的表單思維轉(zhuǎn)而描述業(yè)務(wù)本身的真實(shí)結(jié)構(gòu)。它的核心論斷非常簡潔任何業(yè)務(wù)活動本質(zhì)上都是Agent通過控制Resource參與Event的過程。這個論斷看起來很抽象但非常耐琢磨。舉個例子你在電商平臺買了一瓶水。用傳統(tǒng)建模方式我們會在數(shù)據(jù)庫里建一張訂單表字段包括商品ID、數(shù)量、金額、狀態(tài)、收貨地址、下單時間。但用REA的眼光看這瓶水從倉庫貨架轉(zhuǎn)移到你的手中就是一次Resource的“流經(jīng)”過程而下單、付款、發(fā)貨這三個動作才是真正值得記錄的Event買家、賣家、倉庫管理員、快遞員是參與整個過程的Agent。REA的牛掰之處在于它把“業(yè)務(wù)”從“表單狀態(tài)”中解放了出來。傳統(tǒng)方式里訂單的狀態(tài)可能叫“已付款”“已發(fā)貨”“已完成”這是一種以表單為中心的視角狀態(tài)是人工定義的枚舉值既容易遺漏又容易和別的部門口徑?jīng)_突。而REA視角下系統(tǒng)里記錄的是一條一條不可變的事實(shí)在什么時間哪個參與者對什么資源執(zhí)行了什么動作。狀態(tài)只是這些事實(shí)的投影隨時可以根據(jù)需要重新計(jì)算。這個思想跟事件溯源不謀而合所以今天聊微服務(wù)、聊消息驅(qū)動REA模型反而越來越有參考價(jià)值。1.2 為什么要用REA傳統(tǒng)狀態(tài)機(jī)模型的痛點(diǎn)用狀態(tài)機(jī)建模業(yè)務(wù)系統(tǒng)表面上直觀實(shí)際維護(hù)成本會隨著業(yè)務(wù)復(fù)雜度指數(shù)級上升。我參與過某大型商城的訂單域重構(gòu)老系統(tǒng)訂單表里光狀態(tài)就有二十多種還不算各種標(biāo)志位。最難受的是每加一種業(yè)務(wù)規(guī)則就要重新審視所有狀態(tài)的流轉(zhuǎn)是否合理。比如“退貨中”這個狀態(tài)支付那邊已經(jīng)退款倉儲那邊貨還沒收回來客服說用戶已寄出財(cái)務(wù)說退款失敗了——一個狀態(tài)根本描述不了這種多點(diǎn)并發(fā)的真實(shí)情況。REA把這種局面徹底改變了。訂單不是由狀態(tài)構(gòu)成的而是由一系列Event構(gòu)成的。每個Event都有明確的時間戳和參與者多個Event之間可以并行、可以亂序、甚至可以在時序上重疊。系統(tǒng)不需要維護(hù)一個“當(dāng)前狀態(tài)”字段只需要把所有Event存檔然后通過投影算法計(jì)算出最終結(jié)果。訂單是否完成不再是某個狀態(tài)位而是“買家確認(rèn)收貨事件”和“賣家收到貨款事件”是否都真實(shí)發(fā)生。這種范式在排查歷史問題的時候尤其給力。狀態(tài)機(jī)模型下如果用戶說“我收了貨但平臺顯示未完成”需要翻日志猜測當(dāng)時狀態(tài)被誰改了REA模型下直接查“收貨事件”是否記錄在案沒有就是沒有有的就是有事實(shí)清清楚楚。1.3 REA的適用范圍與不適用場景REA并不是萬能的。它天生適合那些“有明確經(jīng)濟(jì)資源流動”的領(lǐng)域電商、ERP、進(jìn)銷存、供應(yīng)鏈金融、物流、賬戶賬本系統(tǒng)。這些系統(tǒng)里資源流轉(zhuǎn)清晰參與者明確每次動作都是不可逆的經(jīng)濟(jì)事件用REA構(gòu)建會非常舒服。但對一些偏內(nèi)容運(yùn)營、社交互動的系統(tǒng)REA就有點(diǎn)殺雞用牛刀。你不能說“用戶點(diǎn)贊”是一個經(jīng)濟(jì)事件“粉絲關(guān)注”是一個Agent控制資源的動作硬套的話會非常別扭。同樣純文檔管理系統(tǒng)、后臺配置系統(tǒng)、內(nèi)容CMS也不適合。判斷的標(biāo)準(zhǔn)很樸素系統(tǒng)里有沒有“錢、貨、權(quán)、務(wù)”這些實(shí)打?qū)嵉臇|西在流動有REA合適沒有普通CRUD就夠了。2. REA的關(guān)鍵概念拆解與設(shè)計(jì)原則2.1 三個基石概念Resource、Event、Agent的含義REA三元組中的每一個概念都有明確定義不能拍腦袋亂用。Resource是稀缺且有價(jià)值的東西企業(yè)或個人可以對其進(jìn)行控制和使用。它不一定是有形的現(xiàn)金是資源、庫存商品是資源、積分是資源、公共服務(wù)額度也是資源。關(guān)鍵屬性是“可以轉(zhuǎn)化”和“可以被擁有者支配”。在表設(shè)計(jì)時Resource通常對應(yīng)一張“主數(shù)據(jù)表”比如商品表、賬戶表、倉庫表。Event是改變資源狀態(tài)的動作它是REA模型的絕對核心。一次采購、一回銷售、一筆轉(zhuǎn)賬、一個入庫動作都是Event。Event最大的特點(diǎn)是不可刪改只能追加。你下錯了單不能把“下單事件”改成“取消下單事件”只能追加一條“取消事件”。Event還需要具備冪等鍵——業(yè)務(wù)唯一標(biāo)識比如支付單號、流水號用來防止消息重試導(dǎo)致重復(fù)記錄。Agent是參與Event的個體或組織包括內(nèi)部Agent和外部Agent。內(nèi)部Agent是公司內(nèi)的部門、員工、系統(tǒng)機(jī)器人外部Agent是客戶、供應(yīng)商、承運(yùn)商、監(jiān)管機(jī)構(gòu)。設(shè)計(jì)時最重要的是區(qū)分“代理關(guān)系”——客戶付款這個Event實(shí)際參與人是客戶但內(nèi)部訂單員可能替他輸入單據(jù)。REA里這兩者是要分成不同角色記錄的不能用“操作人”一個字段糊弄過去。2.2 四類關(guān)系與雙向性原則REA模型強(qiáng)調(diào)了四類業(yè)務(wù)增量關(guān)系這是整個建模最精妙、也最容易被忽視的部分。第一存量與流量關(guān)系Resource的期末存量等于期初存量加上流入流量減去流出流量。這是對賬、庫存核算的根本公式。在數(shù)據(jù)庫設(shè)計(jì)時Resource表只需要記錄當(dāng)前余額而“余額變化”全部推給Event表來承載。商品庫存表里的數(shù)字不過是對入庫、出庫、報(bào)廢等Event做聚合計(jì)算的結(jié)果而不是業(yè)務(wù)事實(shí)本身。第二源與目標(biāo)關(guān)系明確資源從哪里來、到哪里去。比如“采購入庫”事件資源的源是供應(yīng)商目標(biāo)是我們自己的倉庫“銷售出庫”事件資源的源是我們的庫存目標(biāo)是客戶。第三控制關(guān)系表示Agent對Resource的支配權(quán)限?？蛻艨刂扑膽?yīng)收賬款倉庫管理員控制托管中的庫存商品財(cái)務(wù)控制銀行賬戶?？刂脐P(guān)系把“誰能動什么資源”說清楚為權(quán)限設(shè)計(jì)提供業(yè)務(wù)底層的依據(jù)。第四配對關(guān)系緊密關(guān)聯(lián)的兩個互補(bǔ)事件必須成對出現(xiàn)。比如“收款”和“提供商品”配對“付款”和“收到服務(wù)”配對。這個關(guān)系直接支撐了冪等和事務(wù)一致性的設(shè)計(jì)——一個事件如果沒有對應(yīng)的配對事件那業(yè)務(wù)上就是不完整的系統(tǒng)就要發(fā)出告警。2.3 事件溯源與REA模型為什么會自然契合事件溯源是近幾年后端圈的熱門詞匯具體做法是不保存對象當(dāng)前狀態(tài)而是把每次狀態(tài)變化都保存為不可變事件流。這跟REA的Event思想幾乎是同一個東西只是名字不同。REA系統(tǒng)天然就是事件溯源友好的。在設(shè)計(jì)案中Event表就是那個可以重放的事件日志。訂單當(dāng)前狀態(tài)不需要單獨(dú)維護(hù)表只要把該訂單的所有Event按照時間順序重放一遍任何時刻的快照都能復(fù)原。如果發(fā)現(xiàn)某筆賬不平最直接的排查方法就是把兩條配對Event拉出來對比而不是像傳統(tǒng)系統(tǒng)那樣糾結(jié)于某一次UPDATE操作。我見過不少團(tuán)隊(duì)在引入REA時還要強(qiáng)行保留狀態(tài)字段理由是“查詢性能考慮”。其實(shí)這是不必要的。所有Event重放確實(shí)慢但可以引入投影表——即預(yù)計(jì)算好的當(dāng)前狀態(tài)快照本質(zhì)上是CQRS中的讀模型。業(yè)務(wù)邏輯以Event為準(zhǔn)查詢性能用投影表來扛兩邊兼顧。2.4 冪等性設(shè)計(jì)從配對關(guān)系中反推做分布式系統(tǒng)時冪等性永遠(yuǎn)是繞不開的問題。很多團(tuán)隊(duì)的第一反應(yīng)是“給每個接口生成一個唯一requestId”這沒錯但如果底層數(shù)據(jù)模型不支持你還是會在對賬時發(fā)現(xiàn)重復(fù)。REA模型把冪等變成了業(yè)務(wù)約束。具體做法是每個Event都帶有全局唯一的EventKey這個EventKey必須是業(yè)務(wù)上天然唯一的值。拿支付事件來說第三方支付回調(diào)里的交易流水號就是天然冪等鍵拿庫存扣減事件來說出庫單號就是唯一鍵拿積分變更來說活動編號加用戶ID加批次號是唯一鍵。入庫前先查EventKey是否存在存在就丟棄或返回已有結(jié)果這比在業(yè)務(wù)邏輯層用分布式鎖、樂觀鎖之類的東西要干凈得多。而且REA的配對關(guān)系會把冪等的范圍擴(kuò)大。比如訂單支付事件和訂單履約事件之間不是互相獨(dú)立的關(guān)系而是必須匹配的配對關(guān)系。系統(tǒng)在記錄一個事件的同時就要指定它與哪個既有事件配對。這樣即使某個環(huán)節(jié)被重復(fù)觸發(fā)配對關(guān)系也只會建立一次整條鏈路天然防重。3. 基于REA模型的業(yè)務(wù)系統(tǒng)落地全過程3.1 從業(yè)務(wù)事件流出發(fā)識別核心對象落地REA系統(tǒng)第一步不是建表而是做業(yè)務(wù)事件盤點(diǎn)。我習(xí)慣用一張業(yè)務(wù)事件清單來整理。以某跨平臺商城系統(tǒng)為例業(yè)務(wù)人員和我們一起梳理出了下面的清單僅展示部分事件名稱涉及資源外部Agent內(nèi)部Agent前置事件配對事件客戶下單商品庫存、訂單客戶訂單專員無倉庫發(fā)貨支付完成銀行存款、應(yīng)收賬款客戶、支付網(wǎng)關(guān)財(cái)務(wù)系統(tǒng)客戶下單訂單發(fā)貨倉庫發(fā)貨商品庫存承運(yùn)商倉儲員支付完成客戶確認(rèn)收貨客戶收貨商品所有權(quán)客戶無倉庫發(fā)貨支付結(jié)算確認(rèn)供應(yīng)商供貨商品庫存供應(yīng)商采購員采購訂單財(cái)務(wù)付款這個表格是系統(tǒng)設(shè)計(jì)的藍(lán)圖。每行的“事件名稱”就是一個微服務(wù)或模塊的核心接口“涉及資源”就是需要管理的Resource“外部Agent”和“內(nèi)部Agent”寫清楚了誰在什么角色下參與了動作“配對事件”則是后續(xù)對賬、一致性校驗(yàn)的錨點(diǎn)。這個過程相比傳統(tǒng)需求分析最大的差異是我們不問產(chǎn)品經(jīng)理“訂單有哪些狀態(tài)”而是問“業(yè)務(wù)上一共會發(fā)生哪些事實(shí)”。狀態(tài)是主觀歸納事件是客觀記錄后者更穩(wěn)定。老系統(tǒng)里今天改一個狀態(tài)、明天加一個標(biāo)志位原因正是沒有把“事實(shí)”跟“解讀”分開。3.2 將REA模型映射到數(shù)據(jù)表結(jié)構(gòu)事件盤點(diǎn)完成之后表結(jié)構(gòu)設(shè)計(jì)就順理成章了。一個相對完整的REA核心數(shù)據(jù)模型包含四種類型Agent表、Resource表、Event表、Event關(guān)系表。Agent表用來記錄參與者的基礎(chǔ)信息Customer、Supplier、Employee這些可以分表也可以統(tǒng)一放在一個Agent表里然后用類型字段區(qū)分。Resource表同樣如此不同的資源分類可以細(xì)化成商品表、賬戶表、倉庫表。Event表是重中之重最少包含這些字段事件ID自增主鍵、事件UUI業(yè)務(wù)冪等鍵、事件類型、發(fā)生時間、資源多ID關(guān)聯(lián)、Agent多ID關(guān)聯(lián)、事件附屬描述信息JSON。不能把“當(dāng)前狀態(tài)”放在這張表里因?yàn)檫@張表只存“發(fā)生的事實(shí)”事實(shí)沒有狀態(tài)。Event關(guān)系表是很容易被忽略的一張表。它記錄Event與Event之間的配對關(guān)系。以付款和發(fā)貨為例發(fā)貨事件需要引用支付事件的業(yè)務(wù)UUI這就是配對關(guān)系在數(shù)據(jù)層的表達(dá)。有了這張關(guān)系查詢“某訂單是否已經(jīng)閉環(huán)”只需一條SQL查配對關(guān)系表里該訂單的“發(fā)貨事件”有沒有關(guān)聯(lián)到“支付事件”。下面是一段簡化的建表語句以PostgreSQL為例展示Event表的核心設(shè)計(jì)思路create table business_event ( id bigserial primary key, event_uuid varchar(64) not null unique, event_type varchar(32) not null, occurred_at timestamptz not null, resource_id varchar(64) not null, source_agent varchar(64) not null, target_agent varchar(64) not null, payload jsonb not null default {}, pair_event_id bigint references business_event(id) ); create index idx_biz_event_resource on business_event(resource_id, occurred_at); create index idx_biz_event_pair on business_event(pair_event_id) where pair_event_id is not null;這里把pair_event_id直接放在同一張Event表里是因?yàn)閷σ粋€簡單案例來說一個事件最多只會有一個配對事件。如果業(yè)務(wù)更復(fù)雜可以單獨(dú)建關(guān)聯(lián)表。設(shè)計(jì)原則就一條用事實(shí)記錄事實(shí)不要讓狀態(tài)機(jī)插足。3.3 服務(wù)拆分與服務(wù)間協(xié)作模式REA模型天然指導(dǎo)微服務(wù)拆分。傳統(tǒng)按業(yè)務(wù)狀態(tài)劃服務(wù)容易造成“訂單服務(wù)什么都管”的上帝服務(wù)而REA按經(jīng)濟(jì)事件邊界拆分每個服務(wù)負(fù)責(zé)一組高內(nèi)聚的Event。以前面那個商城為例可以拆出下單服務(wù)負(fù)責(zé)客戶下單Event、支付服務(wù)支付完成Event、履約服務(wù)倉庫發(fā)貨Event、財(cái)務(wù)結(jié)算服務(wù)收款確認(rèn)、付款結(jié)算Event。這些服務(wù)之間不直接共享數(shù)據(jù)庫而是通過消息隊(duì)列傳遞事件。只有Event流轉(zhuǎn)沒有接口級聯(lián)調(diào)用服務(wù)的獨(dú)立性非常高。這個拆分邏輯和DDD限界上下文的做法是相通的但REA給了個更硬朗的劃分依據(jù)凡是牽涉同一資源的同類動作放到同一個域里。比如庫存的入庫、出庫、盤點(diǎn)、報(bào)廢都是直接改變庫存資源的Event只歸履約服務(wù)管其他服務(wù)想動庫存只能發(fā)消息請求不能直連數(shù)據(jù)庫。服務(wù)之間的協(xié)作方式也有講究。下單服務(wù)發(fā)布“OrderCreated”事件支付服務(wù)訂閱后生成支付單支付網(wǎng)關(guān)回調(diào)后支付服務(wù)發(fā)布“PaymentCompleted”事件履約服務(wù)訂閱后生成發(fā)貨單。每個服務(wù)的業(yè)務(wù)邏輯都圍繞“事件來了我記錄一個事實(shí)然后判斷是否需要發(fā)起新事件”這個模式展開。清晰、穩(wěn)定、好排查。3.4 對賬與一致性校驗(yàn)的實(shí)現(xiàn)REA模型落地后對賬不再依賴人工導(dǎo)Excel而可以寫成一套自動校驗(yàn)程序。核心就是存量與流量關(guān)系、配對關(guān)系兩條規(guī)則。先說存量流量校驗(yàn)。拿庫存來說每個資源在任何時點(diǎn)的存量都等于期初值加流入減流出。我們把每天的Event按資源ID聚合計(jì)算出理論應(yīng)存數(shù)量和資源表中的當(dāng)前數(shù)量做比對不一致就告警。對應(yīng)到賬戶余額財(cái)務(wù)總賬余額必須等于期初余額加上所有借貸Event的匯總值。這個檢查用一條SQL就可以做。再說配對校驗(yàn)。系統(tǒng)每產(chǎn)生一個Event時我們可以給它標(biāo)記一個“配對期望”如果已發(fā)生事件在預(yù)期時間窗口內(nèi)沒有等到配套事件就進(jìn)入待核查隊(duì)列。舉一個實(shí)際場景支付完成事件發(fā)生后履約服務(wù)在48小時內(nèi)沒有產(chǎn)生對應(yīng)的發(fā)貨事件系統(tǒng)彈出對賬差異單。這樣的機(jī)制大幅削減了業(yè)務(wù)差錯率也比盲目的人工追查高效得多。4. 實(shí)操中的典型問題與排查經(jīng)驗(yàn)實(shí)錄4.1 把REA做成了ER模型的換皮這是新手最容易跳進(jìn)去的坑。團(tuán)隊(duì)覺得建了幾張Event表、加了對Agent的引用、把狀態(tài)字段挪進(jìn)了Event就叫REA。實(shí)際上他們只是把原來的訂單表改名為Event表里面的“status”字段還在狀態(tài)機(jī)的邏輯還捂在服務(wù)層代碼里。這種“換皮式REA”最要命既沒有事件不可變性也沒有配對關(guān)系還沒享受到可追溯性紅利反而多了一層抽象維護(hù)成本更高。怎么判斷自己有沒有真的落地REA我常說一個標(biāo)準(zhǔn)如果你在Event表里加了“狀態(tài)”字段而且系統(tǒng)業(yè)務(wù)邏輯要靠修改這個字段來流轉(zhuǎn)那你就不是REA。真正的事件表是只插入、不更新的。狀態(tài)屬于投影層是讀模型的事不應(yīng)該躺在業(yè)務(wù)事件表里面。4.2 事件表數(shù)據(jù)膨脹與查詢性能下降所有Event都追加保存運(yùn)行一年后表里可能有幾千萬行。還有人遇到過來自行查詢時有明顯的慢SQL。這個問題需要正面面對事件數(shù)據(jù)是“寫多讀少、按時間追加”的流式數(shù)據(jù)需要針對這種特征做專門優(yōu)化。我的做法是對查詢頻繁的讀模型單獨(dú)建投影表對歷史事件定期歸檔到冷存儲。比如三個月之前的Event搬移到歷史事件庫只保留匯總信息在在線庫。代碼層使用一個查詢路由查當(dāng)月數(shù)據(jù)走在線索引查歷史走歸檔庫然后合并結(jié)果。大多數(shù)業(yè)務(wù)場景下歸檔查詢頻率極低慢幾秒完全可接受而在線庫瘦身后性能能穩(wěn)定維持在個位數(shù)毫秒級。4.3 多方參與者的審批與協(xié)作建模真實(shí)業(yè)務(wù)里一個Event往往需要多個Agent審批比如供應(yīng)商送貨要質(zhì)檢差旅報(bào)銷要經(jīng)理批準(zhǔn)。REA初學(xué)者最容易在這里迷惑覺得一個Event怎么有這么多參與人。其實(shí)REA并不是說一次Event只能有一個Agent它說的是要區(qū)分Agent的角色身份。應(yīng)對方案是把“審批”動作本身也建模為若干個子Event。比如質(zhì)檢審批質(zhì)檢員執(zhí)行“質(zhì)檢通過”事件倉庫執(zhí)行“收貨確認(rèn)”事件采購執(zhí)行“賬期確認(rèn)”事件。這些子Event都是獨(dú)立事實(shí)可以并發(fā)、可以亂序最終以最后一個事件作為主流程的觸發(fā)條件。這個模型比在工作流引擎里畫一排審批節(jié)點(diǎn)更有彈性也更符合業(yè)務(wù)真實(shí)面貌。4.4 時間口徑不一致導(dǎo)致的對賬爭議業(yè)務(wù)系統(tǒng)里最怕的是“同一個事實(shí)兩邊統(tǒng)計(jì)口徑不一樣”。下單時間、支付時間、結(jié)算時間、入賬時間看似都是時間在財(cái)務(wù)、運(yùn)營、倉儲三個部門眼里卻可能差出天和地。REA模型能統(tǒng)一口徑因?yàn)槊總€Event只有唯一的發(fā)生時間戳不能因?yàn)槿雸?bào)表就改時間。但有一個坑要提醒物理時間戳和業(yè)務(wù)時間的處理必須分開。支付網(wǎng)關(guān)回調(diào)的時間有時和用戶實(shí)際支付時間差出幾秒如果系統(tǒng)直接使用回調(diào)時間做入賬時間就會和支付對賬單對不上。我們的做法是每條Event同時保留“實(shí)際發(fā)生時間”和“系統(tǒng)接收時間”兩個時間戳業(yè)務(wù)統(tǒng)計(jì)一律用實(shí)際發(fā)生時間系統(tǒng)排查問題用接收時間兩不相混。寫在最后我在實(shí)際項(xiàng)目里折騰REA模型也踩了不少坑但重構(gòu)完成之后再回頭看最大的感受是業(yè)務(wù)團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)的對話方式徹底變了。以前討論訂單狀態(tài)大家各說各話現(xiàn)在聊的是“這個事件有沒有發(fā)生”“誰做的”“動了哪個資源”問題是照著事實(shí)來找的不再靠拍腦袋猜狀態(tài)。無論你現(xiàn)在是用傳統(tǒng)狀態(tài)機(jī)維護(hù)老系統(tǒng)還是正在規(guī)劃新業(yè)務(wù)的領(lǐng)域模型我建議你先別急著寫表結(jié)構(gòu)花一周時間梳理業(yè)務(wù)事件清單再用REA重新畫一遍數(shù)據(jù)關(guān)系。這套思路不會讓你多寫出多少代碼但它能讓你少寫無數(shù)個補(bǔ)丁。