今天說的是電商平台的賬號管理系統設計，或者是支付平台賬號管理系統設計，或者是充值平台賬號管理系統設計。
以前自己也設計過電商平台的賬號管理系統，也涉及了充值這個功能，就是用戶充值到平台，然后可以用充值的錢買平台的商品。
那時候自己設計的簡單，直接就是用戶信息，然后充值信息。用戶信息記錄用戶當前的余額，充值信息記錄充值的歷史記錄。
但是需求總是在變化的，因為要適應不同場合，系統要發展，而且要跟得上線下的發展，兼容線下的游戲規則。
其實用戶信息和賬號信息就應該是分開的，一個用戶可以有多個賬號，比如說網站賬號，手機客戶端賬號，充值賬號，消費賬號等等。有人會說，這么多賬號，有什么用呢，信息都是一個樣的，多余吧。我要說的是，這肯定不多於，除非你的系統只是個demo。因為真實的系統肯定會演進，會升級，會變化，設計這么多的賬號，后面你升級系統，分離子系統，變更需求的時候就會很方便，誰用誰知道哦。
通過我的觀察，一號店就是這么干的。因為我在一號店網站的賬號和手機客戶端的賬號，兩個賬號登陸用戶名和密碼是一樣的，但是里面的收貨地址不是一樣的。我在網站保存的收貨地址在手機客戶端登陸之后沒有看到，我就又在手機客戶端保存了一個一樣的地址，然后登陸網站發現兩個同樣的地址，這就說明一號店的網站賬號和手機客戶端賬號是兩個獨立的賬號，盡管使用了相同的登陸信息。后來一號店手機客戶端更新說明也證實了我的猜想，有一次他們的更新說明寫到“同步手機客戶端和網站的收貨地址信息”。
比如說消費賬號吧，記錄充值消費變化，這個以后就可以獨立出來一個支付系統，甚至是支付寶之類的獨立系統。
如果你設計的時候沒有做這樣的考慮，后面你是不可能分離的，就算分離也會很痛苦，很可能就是重新來一遍，如果你沒有認識到這個問題，就算重新來一編，也還是不能支撐太久，又會需要重新來一遍了。
有充值，有消費，就會有結算。
我想說的是，肯定會衍生出來一個充值返利的需求，你怎么實現呢？
難道直接把余額信息放大，那就會出現混亂，數據對不上了，看不明白。因為沒有地方記錄這次的充值還有額外的返利，返利多少，返利的規則是什么。
我要說的是我想到的一個辦法，不知道現實中有誰做過類似的設計，肯定有系統有類似的需求，還希望大家賜教。
設計一個系統內部結算消費的幣種，然后充值的錢和這個幣種有某種規則匹配，比如說1:1，或者是1:5之類的比例，這樣的話，就可以輕松解決充值返利的需求，而且順便還可以解決多國貨幣的需求，因為我們系統內部消費結算使用統一的平台幣，然后外部的任何幣種都根據匹配規則換算成平台幣來計算。不管是充值，還是消費，還是返利，還是結算，都是用統一的平台幣，當然了，平台幣對用戶是透明的，最終用戶看到的是自己的幣種。甚至用戶也可以有多種幣種，都沒有關系的，反正平台內部使用的是統一的平台幣。