對賬系統設計(賬戶系統設計從入門到精通)
第一部分：賬戶總述
賬戶體系是支付交易的基礎，就像電池對于手機，油罐對于加油站，心臟對于人體？那么這么核心的系統是不是很難設計呢，其實恰恰不難；這也印證了那樣一句話“大道至簡”
1.什么是賬戶
我們先看看標準定義
賬戶是根據會計科目設置的，具有一定格式和結構，用于反映會計要素的增減變動情況及其結果的載體。
增減變動的會計分錄的書寫規范
借:科目A 金額1
貸:科目B 金額1
賬戶結構規范
賬戶的基本結構應同時具備以下內容:
1)賬戶的名稱，即會計科目;
2)日期和摘要，即記載經濟業務的日期和概括說明經濟業務的內容;
3)增加方和減少方的金額及余額;
4)憑證號數，即說明記載賬戶記錄的依據。
財務知識不是很充足的同學可能對以上的賬戶定義很難理解和繞口；我們從業務的角度來看賬戶，后面的電子賬戶我們都會從業務角度去看，拋棄財務視角
從業務視角來看賬戶其實就是用于記錄某個主體的某類型資金的余額以及余額變動明細的數據載體
所以賬戶有3個關鍵的點
賬戶余額：這個賬戶有多少錢
賬戶流水：這個賬戶資金進進出出的明細記錄
賬戶交易：怎么把錢放進去，怎么把錢取出來
抓住了上面3個點我們基本就抓住了賬戶設計的核心了，是不是很簡單
基于這3個點去構建賬戶的輔助設施，比如賬戶主體，賬戶種類，賬戶余額結構，賬戶流水的記錄字段，賬戶的功能權限，賬戶的出入賬，賬戶服務（賬戶開通注銷，凍結解凍，余額流水查詢等）等
2.賬戶的種類
從財務科目分類來看內部賬戶，賬戶可以分資產類賬戶，負債類賬戶，損益類賬戶，共同類賬戶，然后就是不同的科目
但是站在業務的視角，我們更多是基于業務場景來對賬戶進行命名，比如商戶的結算款會結算到商戶結算賬戶，支付公司在銀行開的賬戶叫備付金賬戶，備付金賬戶又分存管戶，收付戶，匯繳戶；個人賬戶，企業賬戶；會員子賬戶，商戶子賬戶，中間擔保戶
所以從賬戶命名上我們基本就知道了這個賬戶是干嘛用的；就像你有10張卡，一張是放工資的你叫他工資卡，一張是公積金的你叫公積金卡等等，所以這時候我們基于業務命名，目的是為了區分賬戶用途
但是收回來我們發現，無論賬戶叫什么名字，都是有賬戶余額，賬戶流水，賬戶交易；無論卡叫什么名字都是銀行卡；所以賬戶的本質屬性不變，設計辦法基本相通，唯一會有不同的是附屬內容，比如支出戶只能打款不能收款，中間擔保戶不能為負等等，權限不同，主體不同，交易特點不同.....
小樣，你以為穿個馬甲我就不認識你啦，你裝錢的，能進能出，記得明明白白；別管你叫啥我都知道怎么設計，不管我叫你啥我都這么設計
3.賬戶的結構
賬戶結構
賬戶主體
這個賬戶是誰的，個人的？企業的？內部業務線的？
賬戶結構樹
就像會計科目，就像商品類目，由于賬戶可能種類繁多所以有時也需要一個結構樹，比如：
賬戶類型
賬戶的分類，比如個人賬戶/對公賬戶，結算賬戶/付款賬戶，收款賬戶/打款賬戶
賬戶名稱
錢多少不重要，名字一定要有氣質：陳老師全球通國際清算私房錢賬戶
賬戶余額
賬戶余額一般為了業務需要，會設計多個金額屬性，比如凍結金額，可用金額，可提金額
賬戶流水
賬戶的資金變動記錄，記錄對手賬戶，收支方向，金額，費用類型等基本信息
| 賬務號 | 費用 | 收支 | 金額 | 商品 | 剩余金額 | 備注 |
| 1111 | 私房錢 | 支出 | 100 | 冰激凌 | 0 | 給老婆吃 |
賬戶服務
開通/關閉
權限設置
入賬
扣賬
調賬
凍結/解凍
余額查詢
流水查詢
賬戶底線原則
支付成功才入賬，扣賬成功才出款，一分不少真安全
4.如何設計類型
賬戶名稱，結算戶，付款戶，支出戶
原則：名稱是便于區分業務，賬戶本質相同
就像有的公司叫產品經理，有的公司就產品策劃，有的公司叫需求分析師；但本質大家干的都是產品設計工作
基于主體類型命名賬戶：個人賬戶，企業賬戶
基于業務類型命名賬戶：電商商家結算戶，快遞商家結算戶
基于資金屬性命名賬戶：工資賬戶，公積金賬戶，手續費賬戶
基于賬戶職能命名賬戶：待清算賬戶，中間擔保賬戶
等等，現在應該清楚設計賬戶時如何給賬戶命名了吧，簡單易記，容易區分
5.賬戶的附屬設施
有了電池是不是還需要充電線，有了油罐是不是還得有加油設備，安全設備；同樣有了賬戶是不是還得有附屬模塊才能實現賬戶的資金管理職能
費用類型
每筆交易都有業務場景，比如下單付款，投訴罰款，用戶充值，余額提現，賬戶年費等等，一個是為了讓用戶知道這是筆什么交易，另一個就是財務能夠知道編寫什么科目的會計憑證
| 費用編碼 | 費用名稱 | 創建人 | 創建時間 |
| 1002 | 化妝品消費 | PM陳老師 | 2021.3.14 |
| 1001 | 私房錢存入 | PM陳老師 | 2021.5.20 |
入賬規則
上游有業務系統比如賬務系統請求一筆費用的入賬，那么如那個賬戶呢，收支方向如何呢？所以入賬規則就是來確定這筆入賬怎么入的問題，規則主要有2部分組成
| 條件參數 | 費用編碼：1001 費用名稱：私房錢存入 業務線：藏錢事業部 |
| 入賬規則 | 收支：收入 賬戶父類：家庭賬戶 賬戶子類：PM陳老師私房錢戶 |
| 入賬規則ID | 111 |
凍結規則
有些費用入賬后是需要暫時凍結的，比如用戶領的活動獎金，必須在凍結7個工作日之后才能解凍；某業務線的商家結算收入，統一在次月15號可提走；所以一條入賬規則需要關聯一個凍結規則
| 入賬規則ID | 111 |
| 凍結規則ID | 11101 |
| 凍結規則 | 是否凍結：凍結 凍結模式：固定時長 凍結設置：7天 是否有效：是 |
費用/入賬規則/凍結規則關系
一個費用入賬時，可能記一筆賬，也可能記多筆；比如商戶傭金費用，則會入兩筆賬：成本賬戶入一筆扣款，商家傭金賬戶入一筆收入；而扣款不用凍結，收入需要凍結7天
對外服務
任何系統都不是孤島，賬戶系統同樣，要將能力賦能給上游實現自己的價值；賬戶向外提供的服務基礎的應該包含：開戶，注銷，查詢（余額，流水，狀態），交易（支付，退款，充值，提現，凍結）等
賬戶管理后臺
賬戶系統需要提供一個業務后臺給到相關的運營人員，財務等角色；后臺可以查看所有的賬戶以及賬戶的狀態，所屬主體以及余額情況；還可以操作賬戶進行注銷
還需要能夠查看所有的出入賬流水，配置相關費用，配置入賬規則和凍結規則
6.賬戶系統架構圖
功能架構
業務架構
7.賬戶入賬流程圖
8.賬戶系統后臺
上面基本已經很清楚了，賬戶系統后臺頁面文章不再詳述，原型可以到星球進行下載
9.賬戶的應用
賬戶除了管錢之外還可以在此之上構建一些應用產品比如下面這兩個
錢包
像微信錢包，就是用戶的一個虛擬賬戶，在錢包里可以看到余額，可以充值余額，也可以將余額里的錢提現到銀行卡
余額支付
賬戶可以作為一種支付方式，包裝出一個支付通道，利用平臺自己的賬戶進行平臺商品的購買支付，當然這個要考慮合規性
10.合規淺談
果然最后說的都是重頭戲，賬戶作為一種資金池形態，要嚴格做好其合規性，如果平臺沒有資質牌照，那么自建可以但是用戶賬戶的真實資金一定要放到監管賬戶當中進行監管，避免違規沉淀資金池，其他合規風險讀者朋友們自己思考一下吧
第二部分：賬戶主體
賬戶本身記錄的是資產或者負債或者費用，那么必然就需要一個主體承載，誰的錢，誰的債，誰的費用，誰的愛！世界上沒有一片樹葉沒有歸屬，就算秋風落了葉，那它要不屬于天空或是歸屬大地，所以賬戶歸于誰，而這個誰是誰就是今天我們要聊的主體
1.什么是主體
主體可以是人，可以是公司，可以是一個組織，我們暫且認為主體就是一個具有基本特征和屬性的一個可定義的對象
2.主體的廣義定義
基于對象出發，那么主體可以認為是自然界存在的實體物質和虛無的對象；比如一個人是一個主體，一個公司是一個主體，一個組織是一個主體；公司的一條業務線是一個主體，公司的一個部門也是一個主體，一個城市也是一個主體，一座房子也是一個主體等等
那么這么多主體有什么意義呢，其實就是說明賬戶的主體可以非常廣義，比如一個城市的GDP,可以通過一個統計報表得到，同樣也可以為每個城市設置一個GDP賬戶，那么這個賬戶的主體就是一座城市；北京GDP賬戶2020年年末余額4萬億！
所以主要是一個可以被定義的對象，我們就可以將它作為賬戶的主體來管理，就可以為之開通某種意義上的賬戶，賬戶也可以是廣義的，不只是金錢余額，也可以是水量余額，點量余額，好感度余額等等，從而賬戶的廣義我們是不是就可以認為：賬戶可以記錄一個可被量化的數量以及變化過程的記錄工具；那么我們就可以用賬戶的設計理念去設計更多的事物的數量以及變化過程
3.狹義賬戶主體
我們回歸賬戶主體本身，就是賬戶的歸屬對象；最常見的主體就是個人和企業；銀行卡的主體有個人主體和法人主體；
對于一個公司內部來說為了經營分析或者管理的需要又會虛擬出更多的主體類型，比如營銷賬戶的這類費用賬戶的主體可以是業務線或者部門或者小組，來記錄部門和小組的預算以及預算的消耗
站在人民銀行的角度看賬戶主體我們知道就是：網聯，銀聯，各商業銀行，各城市處理中心，各特批處理機構等
站在銀行角度看銀行賬戶主體就是：個人，企業，支付機構等
站在一個普通企業看賬戶主體就是：個人用戶，企業用戶，內部業務線，子公司等
4.主體的唯一ID
就像個人我們的唯一ID可以是身份證，我們在開銀行卡的時候就是用的身份證ID作為這個主體的唯一ID，在辦理社保的時候也是用身份證ID作為身份的唯一ID；唯一ID的條件就是能夠唯一識別這個主體
比如個人的唯一ID可以是身份證，手機號，社保號，一個平臺的userID及時在這個平臺的唯一ID；
企業的唯一ID可以是統一社會信用編號，也可以是對公戶的卡號等；如果企業入駐了一個平臺那么這個平臺為這個企業生成的企業編碼也可以唯一識別這個企業
唯一ID的用途就是唯一識別這個主體，但是有時候可能這個主體的唯一身份ID不夠用，比如這個人在淘寶即是個人用戶又是商家用戶，那么他在開戶時可能就不能只用身份證了，而是用userID 去開付款戶 和 bussid 去開結算戶
5.主體的身份認證
安全起見，我們需要核查主體的身份，像銀行開戶需要本人到場+身份證核驗；二類戶的開通需要多要素鑒權識別主體身份的合法性
對于企業來說企業的營業執照，法人簽字，蓋章或者對公戶小額打款來驗證企業的真實身份
6.主體的創建
對于一個平臺而言，其賬戶系統的主體無非以下幾種
個人用戶：具有身份證或者手機號唯一識別的一個自然人個體
企業用戶：具有企業信用編號唯一識別的一個法人主體
內部主體用戶：為了管理需要內部的子公司主體或者業務線主體或者部門
主體下業務線子用戶：一個子公司下面的一個業務線或者部門
所以我們在創建主體的同時就需要定義每一類主體的唯一識別ID
在開戶的時候，就需要使用這個唯一識別ID作為賬戶主體的唯一識別ID
7.主體的信息管理
一個平臺的各類主體信息一般是放在用戶中心或者crm系統，這些系統去調用賬戶中心進行開戶，在這些系統內對于一個主體我們需要管理他的基本信息，比如ID信息，屬性信息，權限信息，關系信息；有什么信息就增加字段管理即可，也可以將信息分類，每一類記錄的不同的表中，比如身份信息，認證信息，賬戶開通信息等
8.為主體開戶
有了主體以后，賬戶的開通可以是人工也可以是上游系統調用開戶接口開通相關賬戶和賬戶權限
比如接口要傳入下面的信息
入參
主體ID：123
ID類型：userid
用戶類型：個人
用戶姓名：張三
開通賬戶類型：傭金賬戶
賬戶特殊要求：可付款
請求成功后賬戶系統就會先在賬戶主體表中插入基本主體信息，如果需要其他信息，在后面加字段即可
根據主體ID可以去賬戶表查詢開通的所有賬戶
然后基于開戶請求我們在賬戶中心表中創建對應的賬戶，賬戶中心表中要有主體的用于開戶唯一ID
| 主體ID | 賬戶ID | 賬戶類型 |
| 123 | 33333333 | 傭金賬戶 |
| 123 | 2222222 | 紅包賬戶 |
| 123 | 111111111 | 積分賬戶 |
同時在賬戶余額表中創建賬戶余額
| 賬戶ID | 賬戶類型 | 總余額 | 凍結余額 | 可用余額 |
| 33333333 | 傭金賬戶 | 0 | 0 | 0 |
同時在賬戶的權限表中設置賬戶權限
| 賬戶ID | 付款權限 | 透支權限 |
| 33333333 | 是 | 否 |
賬戶中心經過一些列的處理后賬戶就開通了，然后返回給開戶方
出參
開戶結果：開通成功
我們從上面的開戶過程可以看出來，賬戶內部和主體之間是一個復雜的對應關系
9.主體與賬戶的關系
通過8我們知道，主體和賬戶以及賬戶內部有復雜的對應關系
主體vs賬戶是一對多的關系，一個主體可以開通多個賬戶，每一個賬戶又會關聯余額表，權限表，流水表
主體的開戶ID去關聯賬戶的賬戶ID，賬戶ID去關聯賬戶的余額表中的余額，權限表中的權限
第三部分：賬戶結構和余額結構
1.簡單賬戶結構
賬戶結構一個是本身的結構有什么組成，另一個就是賬戶體系內賬戶與賬戶之間的構成模型，我們主要說后者，我們看幾個最簡單的賬戶結構
只有一類賬戶，比如整個賬戶系統只有一類賬戶：張三-工資賬戶
有多個類型的賬戶，比如下圖，但本質上依然很簡單，很容易管理
2.簡單余額結構
余額結構就是針對賬戶內部來說，賬戶的余額如何劃分，就像火鍋，有一個鍋，鴛鴦鍋，九宮格，一樣，賬戶作為一個容器，其內部依然可以劃分成多個存儲空間
只有一個余額的余額結構，你會發現微信錢包的余額就只有一個，有多少就是多少，簡單粗暴
賬戶余額
0.00
這樣的余額結構必然支持的交易種類就很簡單，收入，支出；無法支撐其他的針對余額的處理
3.復雜賬戶結構
隨著業務的復雜度增加，各類功能性以及運營需求增加，簡單的賬戶結構開始變得復雜，以支撐更復雜的業務模型，比如紅包可能每個業務線都要推出一種紅包營銷形態，比如保險業務線，游戲業務線；而紅包又被拆分成了現金紅包，虛擬幣紅包等這樣的話紅包賬戶結構就成了多層級的賬戶結構；如下
看著是不是很像會計科目的結構，最下一層是不是很像葉子科目，當然第二層和第三層換一下位置也可以；這種情況下賬戶結構就很復雜了，而且自然存在了總賬戶和明細賬戶之分
還有一種是賬戶結構分總分機構，但二級賬戶的種類繁多，功能劃分較細，這類賬戶結構具有支撐復雜的記賬能力，以及業務處理能力，這類賬戶結構常見在二清監管戶體系，比如下面具有眾多子賬戶的賬戶體系，協同完成資金的監管和分賬職能
一朋友咨詢我人力資源代理平臺的賬戶該如何設計，業務模型就是平臺幫助很多企業代收代發工資，并且支付公積金和社保等多種資金款項，我設計了四個方案，你覺得那個方案好呢
4.復雜余額結構
因為資金清算周期或者業務流轉節點多，或者其他風控要求，需要對賬戶余額進行復雜的處理操作，比如有的能提，有的不能提，最常見的結構就是三個余額屬性
| 總余額 | 凍結余額 | 可用余額 |
| 100.00 | 20.00 | 80.00 |
核算恒等式：總余額=凍結余額+可用余額
這樣的話，就可以對賬戶余額進行一些處理，比如發的紅包7天后才能提現，那么紅包入賬戶時就會先入凍結余額，7日后解凍之可用余額
5.賬戶結構和余額結構的關系
從上面我們可以看到，賬戶可以分多級，余額可以分多塊，那么有什么關系呢
多級之間：x級總賬戶總余額=sum( x-1 級子賬戶所有賬戶總余額之和 )
某個賬戶：總賬戶余額=凍結余額+可用余額
上面另個恒等式可以用于校驗賬戶系統記錄的合法性，是不是覺得跟會計系統科目之間的試算平衡很類似
6.賬戶管理表的設計
通過前面的賬戶主體，賬戶結構，賬戶余額結構，我們基本可以設計出賬戶表的基本字段了，只要包含這幾部分信息：賬戶主體信息，賬戶結構信息，余額信息，賬戶狀態信息，我們設計如下，除了核心字段以外，其他想展示的字段可以去相關表中查詢，比如主體姓名，可以用主體ID去主體表中查詢
7.余額的變化
我們簡單說一下，后面在將流水和余額更新時會細講；賬務請求賬戶入賬時，基于凍結規則我們可以知道該筆入賬是否需要凍結，如果需要凍結的話就更新凍結余額，后面再解凍，如果不需要凍結的話就直接更新可用余額
作業：思考一下，如果你是螞蟻財富的賬戶產品經理，你會如何設計賬戶結構和余額結構，來滿足業務模型呢？歡迎在產品群或者星球提交作業！（備注小心有坑哦）
第四部分：費用和入賬規則
有了賬戶那么賬戶里就需要存入和存出，充值和提現，轉賬和消費；這樣賬戶才會流動起來，才有了生命力；那么在交易場景里費用就顯得十分重要了，多少錢，什么費......我們以滴滴司機的結算賬戶為例來討論本節內容
1.交易場景
任何一筆收支都依賴于一個場景，而且這個場景基本涵蓋所有后續清結算的信息，
比如用戶叫了一輛快車，張師傅接了單子，從立水橋南到奧森公園；這就是一個交易場景，我們可以稱為”快車打車場景“，在這個場景下我們可以知道用戶是誰，在哪打的車，什么車型，起步價多少，每公里多少，司機是誰等；
如果車到了，超過了4分鐘用戶不用車取消了，那么這時候就需要支付一個取消費用，這又是一個場景，我們可以稱為“超時取消場景”
我們將平臺的所有交易場景進行枚舉，如果要新增場景，那么要預先在場景中心申請場景編號，才能開展上線業務
2.費用
在上面的場景中，就會產生交易，因此產生一些列的費用，
比如打車單訂單費用，完單后要給司機做結算就有了訂單結算費用，平臺要抽取一定服務費就有了“平臺服務費用”，如果高峰期給司機發一定補貼的話就有了“高峰補貼費”等等；
費用就是站在業務角度定義資金的業務屬性，基于業務側的費用我們可以關聯到后續的財務科目，這樣的話費用是從業務發生那一刻就產生并且定義了，而且最后關聯到會計科目，這樣業務和財務實現信息一體，對于業務記賬以及轉財務賬提供巨大的遍歷
3.計算
這需要一個強大的計算系統，我們在支付系列清結算模塊會做重點介紹；這里點到為止
下單前的預計算，為用戶選擇起點和重點后預先計算可能需要的訂單費用
進行中的實時計算，這個大家都打過車就不再說了
結束后的計算，計算出本單實際產生的費用
我們可以看出訂單總費用包含三部分：起步價+里程費+時長費；你可能會問，一個訂單為什么要拆成這么多費用呢？我們簡單想一下，這三個費用的特點，而且這三個費用在不同的城市，不同的時段，不同的用戶，不同的車型都會發生變化，所以我們可以理解為，費用的細化是精細化運營的必然結果，另外用戶也需要知道為什么收這么多錢
訂單的清結算，訂單完結后就需要給司機做結算，那么還需要進行一次計算，那就是這一單應該給司機多少錢，平臺抽多少錢，要不要實時扣稅，有沒有其他費用，比如保險費，我們得出如下的清算結果
4.賬戶結構和余額結構
簡單點，每個司機只有一個結算賬戶，在某支付平臺開通的二類支付賬戶，沒有其他類型的賬戶，接單的收入，補貼獎金全部結算到該賬戶，司機可以進行提現
因為為了風控客訴問題，我們為司機設置一個7天的訂單結算凍結期，這樣的話我們的賬戶余額分成了凍結余額和可用余額，可用余額可以用于提現
5.費用管理設計
上面我們講了交易場景和費用的定義，現在我們就來設計費用費用管理，設計費用有三個關鍵點
費用編碼 費用名稱 費用結構
這里的設計辦法有2種
一級枚舉型，就是費用之間沒有關系，對所有費用進行枚舉，有規律設置編碼
多級結構，就是像會計科目一樣，有總科目，明細科目，明細科目可以設置多級
以上兩種方式可能第二種更好一些，特別是在核算和統計時，可以進行總分分別進行統計分析和核算
6.入賬規則管理
我們設置好了費用，那么在每個節點都會產生費用，或者計算出相關的費用，比如司機收入，那么清分之后就需要計入相關的賬戶，比如司機收入要計入司機的結算賬戶；那么還可能一個費用要計入多個賬戶，比如復試記賬時，又比如司機獎金可能要同時計入平臺的運營賬戶和司機的結算賬戶
入賬規則設計有兩個關鍵點
一個是匹配條件：要基于入賬請求傳參的條件來匹配到相關的入賬規則條目，比如我們需要定義每類記賬請求需要什么條件，比如司機收入入賬，一個條件就夠了
費用類型 司機收入
另一個是入賬規則：就是這個條目指定入什么賬戶，比如司機收入匹配到的規則應該是要入司機結算賬戶，則入賬規則是
賬戶主體：司機
主體ID：司機ID
賬戶類型：結算賬戶
這樣我們就得到了一條入賬配置規則
基于上面的規則，上游系統在申請入賬時必須傳幾個參數：費用類型，主體類型，主體id;基于司機收入這個費用，我們就匹配出一條規則，應該入司機的結算賬戶，利用司機ID找到相關的結算賬戶ID然后計入賬戶
第五部分：凍結規則和賬戶流水
當業務系統請求入賬以后基于費用類型以及入賬規則我們就可以知道應該入哪個賬戶；這時候問題就來了，因為賬戶余額也是分結構的，有凍結和可用，那么要是想先凍結起來怎么辦呢？
我們先回顧一下上一篇的最后一個圖，在凍結處理里我畫了一個虛線圈，本篇文章我們就把他做實了
1.凍結規則
我們在賬戶系統設計詳解里講過凍結模塊，這里我們再細講一下；凍結就是一個費用請求入賬時要基于業務要求決定需不需要暫時凍結起來，還是直接就可以使用；那么如何設計凍結規則呢
凍結規則是基于入賬規則設置的，也就是這筆入賬需不需要凍結，如何凍結，是全部凍結還是部分凍結；這里我們以全部凍結為例
所以一個入賬規則要關聯一個凍結規則，入賬的時候就需要同時獲取凍結規則；入賬規則和凍結規則是一對一的關系，費用類型和入賬規則是一對多的關系
凍結規則有2部分組成，一個是關聯的入賬規則；另一個是凍結規則；也就是說在配置入賬規則的同時就需要關聯性的去配置一條凍結規則
| 入賬規則ID | 111 |
| 凍結規則ID | 11101 |
| 凍結規則 | 是否凍結：凍結 凍結模式：固定時長 凍結設置：7天 是否有效：是 |
凍結規則的配置有幾個關鍵點
凍結模式：就是按照固定時長凍結還是凍結到固定時間點
凍結時間：如果選擇固定時長的話就填一個時間值，如果是固定時間的話就選擇一個可循環的時間點函數，比如次月10號，就配置成M+1月10號
2.賬戶流水
賬戶有2個核心部分組成，一個是賬戶余額我們已經講過了，另一個就是賬戶流水，賬戶流水就是記錄了賬戶的變動歷史明細，我們收窄為“資金的變動明細”
為了記錄資金的變動明細，我們就需要記錄最基本的明細信息，一般必須包含以下信息
賬務流水號：作為該筆明細的唯一標識
請求ID：請求入賬方的ID，便于后續的核算
賬戶ID：這筆流水屬于哪個賬戶（會計記賬就是科目編號）
費用類型：這筆流水是什么費用
金額：發生額
剩余余額：這筆流水發生后的賬戶余額
收支：支出，收入，這筆流水是增加余額還是減少余額（同會計分錄的借貸）
賬務發生時間：記賬時間
會計時間：作為業務口徑和財務口徑轉換的時間（非必須）
備注：業務備注信息
凍結狀態：凍結的管理
操作：凍結/解凍
這樣我們就將業務的記賬請求通過入賬規則處理，凍結規則處理，進入到賬戶系統并且生成賬戶流水了
3.更新賬戶余額
這里有一個賬務處理任務流，每筆入賬都需要從頭執行到尾，不能遺漏，任何一個處理失敗了這筆入賬就宣布失敗進行入賬的失敗處理，我們先設定一個最簡單的任務流
檢查賬戶流水合法性 通過
賬戶流水表插入賬戶流水 完成
基于賬戶流水信息更新余額表對應賬戶的凍結余額或者可用余額 完成
賬戶ID：
總余額=總余額+本次發生額
凍結余額=凍結余額+本次發生額（凍結時）
可用余額=可用余額+本次發生額（不凍結時）
自洽校驗：總余額=凍結余額+可用余額 通過
入賬成功
經過一些列的處理，入賬成功了，通知請求方，本次入賬結束
4.余額解凍
因為入賬的時候有的流水處于凍結狀態，那么我們就需要按照凍結的規則進行解凍，這時候就需要一個凍結解凍處理的任務進行掃描執行，至于掃描的模式要基于凍結模式去設計，我們以凍結固定時長最小單位為天為例，那么任務就需要每日凌晨去掃描遍歷所有處于凍結狀態的賬戶流水，滿足解凍條件的變更凍結狀態為未凍結，然后對余額進行處理；這又是一個處理的任務流
任務掃描遍歷凍結狀態的賬戶流水
滿足條件的賬戶流水變更凍結狀態為未凍結狀態
扣減賬戶的凍結余額并同時增加賬戶的可用余額
解凍完成
第六部分：賬戶后臺設計
1.賬戶列表
2.賬戶詳情
3.賬戶流水
