回來看看自己的博客園，自己總是三天打魚，2天曬網。從flask到爬蟲，現在啥也沒學會，殘念。
也許要一以貫之吧。
我是想說說賬戶體系的設計的。
但我沒有什么強大的設計能力，而且我也總覺得賬戶設計這個事和會計沒啥關系，不知道很多人為什么一定要扯上會計的事。
我們還是從第三方支付來只管感受一下，小白用戶對賬戶的感受是咋樣的？
直接就以微信支付來說好了，先看微信支付是否有賬戶？
我們覺得是有的。為什么有？因為我能看到一個自己有一個微信零錢的余額，也許可能余額是零也說不定。
回顧一下上面一句話，其實從我的理解來看，我們之所以說微信支付有賬戶，是因為微信支付有一個地方記錄了我的微信錢包余額的變化。
這引出一個問題，微信錢包余額是啥？
我為什么會有微信錢包余額？我為什么要知道我的微信錢包余額的變化？
我們先從業務發生的角度來看，當我們使用銀行卡向微信錢包充值的時候，我們就擁有了微信錢包余額。
那我為什么要充值呢？
因為微信支付錢包的余額可以讓我發紅包，或者去買個快餐。
那我為什么要關注微信錢包的余額呢？
第一，因為我的余額是我的一部分錢。
第二，根據微信支付的設計，當我的余額不足以支付時，我必須再充值。
這大概是我們用戶對微信支付賬戶的一個理解。
當然可能和大家實際感受不是那么一致。
為什么？
因為微信支付不僅有賬戶的功能，他還做了一個“橋”的功能。
什么是“橋”？
就是我們使用銀行卡快捷支付的時候。
當我們通過微信支付使用快捷支付的時候，我們其實和我們的微信余額半毛錢關系都沒有，這個時候你其實用的是你的銀行賬戶來支付，微信支付只是做一個橋。讓你可以使用不是微信支付的東東也來支付。
好的，那我們現在說錯了一些什么事情呢？
我知道轉折的有些大。
這個可能還不是我們理解的一個賬戶。
因為從我們理解來看，我用銀行卡快捷支付的時候，我感覺我也是在用微信支付的賬戶啊，反正我是這么感覺的。
我的證據是什么？或者說造成我錯覺的是什么呢？
我可以通過查看微信支付的交易記錄看到我所有的快捷支付。這你還說和微信支付賬戶半毛錢關系都沒有？
也是哦，這會讓我們再深入的思考賬戶這個玩意到底是什么？
我們再來頭腦風暴一下，如果用一些詞來形容賬戶，我們會想到什么？
實名認證，綁卡，余額，發紅包，理財，查交易記錄，被盜號了，密碼
這里的感受是，賬戶這個東東好像有很多功能，實名認證就說明他一定記錄了我的身份信息，比如我多少歲，性別是啥，姓甚名誰，身份證號碼是多少，哪個國家的人，如果可能再細一點的話，可能還有我是干啥的，我的工資有多少，我是已婚還是未婚....
綁卡，是啥？這個賬戶還可以和其他賬戶體系關聯。
余額是我們最開始說的賬戶的一些粗略印象。
發紅包理財，查交易我們也說了一下。
被盜號？大家會不會突然想到我們是否有一個微信支付賬戶的ID呢？我們很清楚的是我們有身份證ID，我們有手機號碼，我們是否有微信支付賬戶ID呢？好像是沒有的。感覺像是我們的微信支付賬戶是跟着微信開通的，只不過我多點了一個確認信息。
那我可能微信賬號被盜，微信支付賬號不被盜么？
這涉及到一個密碼的事了，微信支付單獨設立了一個微信支付的交易密碼。這個是微信賬號被盜，我們微信支付賬號不被盜的保護了。
我們零零散散的說了很多，其實就是想說，我們感覺賬戶是一個很大的綜合體，感覺他好像啥事都參與了一些。
好像真的要仔細說明一個賬戶是很復雜的。
那我們不如換一個視角來看看，假設你自己是設計的人員，你設計的賬戶體系要把上面的功能全部完成，你要怎么設計？
假設我們把賬戶當一個對象來看的話，是不是他就會有很多玩意。
他有用戶的身份信息，有用戶綁定的卡的信息，他有用戶所有交易的信息，有用戶的密碼，和他和哪些外面賬戶有關聯。
這樣一個對象是不是有些太大了？
是不是能更好的分層，來簡化一下復雜程度呢？
網上有一些三戶體系，我很敬佩的知乎梁川大神也提了一個客戶/賬戶/賬務的體系，說實話我都不是特別懂。
但我們也想冒險設計一下？
我們設計之前總是有些自己的原則和目標的，我自己的第一個目標是關於資金變化的信息，越少干擾信息就越好。
這個也不知道對不對，只是我的直覺。
對於編程垃圾的我，也只是在胡說不到，但我還是想扯一扯。
如果按照這樣的層次划分話，
我想賬戶應該是很純粹的一個東西。
他有啥信息？
有余額，有交易。
沒了。
其實這個就和我一開始最初的印象基本一致。
那我們再來具體定一下，啥叫有余額？
我們的第一個問題就是，我不僅有微信錢包的余額，我還有理財通的余額，你這個余額是啥余額？
這就是我想說的第一個點。
從我的理解來看，這其實是2個賬戶。
一個賬戶就應該只記錄一種余額。
而且其實也可以把這些賬戶都放在一起，互相之間產生交易。
或者說，我們想說的賬戶設計，不僅對微信錢包的余額有用，其實也應該對理財通余額也是有用的，或者說和你公交卡的余額也是有用的。只是上層功能會有不同。
最底層的賬戶設計應該是要通用的。
說完余額，我們再說說交易。
交易是一個令人疑惑的東西。
既然我們說了我們的賬戶是只針對零錢的賬戶，那你通過橋的交易，抱歉，在我們的賬戶，我們是不記錄的。除非你的交易涉及到了我的賬戶余額發生變化，比如充值，那我會記錄這樣一筆交易。
當然你也可以把每一次銀行快捷的支付都設計成為賬戶充值+賬戶支付的組合，但是這個又是后面的話題了。
然后我們在具體說說交易你到底要記錄啥？
我們說交易其實在說啥，比如我通過余額給朋友轉了一筆賬，你覺得我們的交易是啥？
這筆交易是不是就是我的賬戶給我朋友的賬戶轉了一筆錢？是的，就是這樣。
我們還要再細說，我們為什么要記錄交易？
其實上面的一個轉賬不就是我的余額減少了100元錢，我朋友的余額加了100元錢么？一減一加就完成了。
但是這樣會產生幾個問題。
第一，假設說我要查我之前有什么交易的話，我不知道。
第二，假設系統加錯了，我朋友的余額加了200元錢，這個怎么辦？我們是否能發現？發現之后是否能處理？
如果不記交易的話，我們就不知道這里加錯了。
其實，從這里出發，可以看出，賬戶系統的很多設計，其實是為了當系統出問題時，我們能定位並發現問題。
如果我們要滿足上面的幾個要求，我們的交易該怎么設計呢？
這筆交易應該說名幾個事情。
誰出錢，誰收錢，金額，時間，唯一編碼
這樣，當我們看到我朋友的余額加了200元錢的時候，我們就可以發現了他多家了100元錢。
等等，你是不是想多了？
你怎么發現？
你其實這樣還很難發現，為什么？
你還缺一個事情，就是我的賬戶的流水。
我的賬戶加了一百元錢，我還必須記錄一條流水，這條流水有啥信息呢？
唯一編碼，金額，時間
這樣你才可以發現。
具體怎么操作呢？
假設說我們要查我的賬戶是不是有沒有操作錯誤？
我就把所有的交易拉出來，挑選出是關於我的賬戶的交易，然后吧這些單和流水比對，怎么比對，因為你們公用一個唯一編碼，你就可以一條條比對，我是不是加錯了還是加對了。
那這樣的話，你也可以推而觀之，把所有的賬戶都這樣核對一遍，這樣我們初步的賬戶體系也就設計完了。