【新年第一篇】平臺的帳號管理系統設計的設想

 

        今天說的是電商平臺的帳號管理系統設計，或者是支付平臺帳號管理系統設計，或者是充值平臺帳號管理系統設計。

 

        之前本身也設計過電商平臺的帳號管理系統，也涉及了充值這個功能，就是用戶充值到平臺，而後能夠用充值的錢買平臺的商品。

        那時候本身設計的簡單，直接就是用戶信息，而後充值信息。用戶信息記錄用戶當前的餘額，充值信息記錄充值的歷史記錄。

        可是需求老是在變化的，由於要適應不一樣場合，系統要發展，並且要跟得上線下的發展，兼容線下的遊戲規則。

 

        其實用戶信息和帳號信息就應該是分開的，一個用戶能夠有多個帳號，好比說網站帳號，手機客戶端帳號，充值帳號，消費帳號等等。有人會說，這麼多帳號，有什麼用呢，信息都是一個樣的，多餘吧。我要說的是，這確定很少於，除非你的系統只是個demo。由於真實的系統確定會演進，會升級，會變化，設計這麼多的帳號，後面你升級系統，分離子系統，變動需求的時候就會很方便，誰用誰知道哦。

 

        經過個人觀察，一號店就是這麼幹的。由於我在一號店網站的帳號和手機客戶端的帳號，兩個帳號登錄用戶名和密碼是同樣的，可是裏面的收貨地址不是同樣的。我在網站保存的收貨地址在手機客戶端登錄以後沒有看到，我就又在手機客戶端保存了一個同樣的地址，而後登錄網站發現兩個一樣的地址，這就說明一號店的網站帳號和手機客戶端帳號是兩個獨立的帳號，儘管使用了相同的登錄信息。後來一號店手機客戶端更新說明也證明了個人猜測，有一次他們的更新說明寫到「同步手機客戶端和網站的收貨地址信息」。

 

        好比說消費帳號吧，記錄充值消費變化，這個之後就能夠獨立出來一個支付系統，甚至是支付寶之類的獨立系統。

        若是你設計的時候沒有作這樣的考慮，後面你是不可能分離的，就算分離也會很痛苦，極可能就是從新來一遍，若是你沒有認識到這個問題，就算從新來一編，也仍是不能支撐過久，又會須要從新來一遍了。

 

        有充值，有消費，就會有結算。

        我想說的是，確定會衍生出來一個充值返利的需求，你怎麼實現呢？

        難道直接把餘額信息放大，那就會出現混亂，數據對不上了，看不明白。由於沒有地方記錄此次的充值還有額外的返利，返利多少，返利的規則是什麼。

        我要說的是我想到的一個辦法，不知道現實中有誰作過相似的設計，確定有系統有相似的需求，還但願你們賜教。

 

        設計一個系統內部結算消費的幣種，而後充值的錢和這個幣種有某種規則匹配，好比說1:1，或者是1:5之類的比例，這樣的話，就能夠輕鬆解決充值返利的需求，並且順便還能夠解決多國貨幣的需求，由於咱們系統內部消費結算使用統一的平臺幣，而後外部的任何幣種都根據匹配規則換算成平臺幣來計算。不論是充值，仍是消費，仍是返利，仍是結算，都是用統一的平臺幣，固然了，平臺幣對用戶是透明的，最終用戶看到的是本身的幣種。甚至用戶也能夠有多種幣種，都沒有關係的，反正平臺內部使用的是統一的平臺幣。