今天说的是电商平台的账号管理系统设计，或者是支付平台账号管理系统设计，或者是充值平台账号管理系统设计。以前自己也设计过电商平台的账号管理系统，也涉及了充值这个功能，就是用户充值到平台，然后可以用充值的钱买平台的商品。
那时候自己设计的简单，直接就是用户信息，然后充值信息。用户信息记录用户当前的余额，充值信息记录充值的历史记录。但是需求总是在变化的，因为要适应不同场合，系统要发展，而且要跟得上线下的发展，兼容线下的游戏规则。
其实用户信息和账号信息就应该是分开的，一个用户可以有多个账号，比如说网站账号，手机客户端账号，充值账号，消费账号等等。有人会说，这么多账号，有什么用呢，信息都是一个样的，多余吧。我要说的是，这肯定不多于，除非你的系统只是个demo。因为真实的系统肯定会演进，会升级，会变化，设计这么多的账号，后面你升级系统，分离子系统，变更需求的时候就会很方便，谁用谁知道哦。
通过我的观察，一号店就是这么干的。因为我在一号店网站的账号和手机客户端的账号，两个账号登陆用户名和密码是一样的，但是里面的收货地址不是一样的。我在网站保存的收货地址在手机客户端登陆之后没有看到，我就又在手机客户端保存了一个一样的地址，然后登陆网站发现两个同样的地址，这就说明一号店的网站账号和手机客户端账号是两个独立的账号，尽管使用了相同的登陆信息。后来一号店手机客户端更新说明也证实了我的猜想，有一次他们的更新说明写到“同步手机客户端和网站的收货地址信息”。
比如说消费账号吧，记录充值消费变化，这个以后就可以独立出来一个支付系统，甚至是支付宝之类的独立系统。如果你设计的时候没有做这样的考虑，后面你是不可能分离的，就算分离也会很痛苦，很可能就是重新来一遍，如果你没有认识到这个问题，就算重新来一编，也还是不能支撑太久，又会需要重新来一遍了。
有充值，有消费，就会有结算。
我想说的是，肯定会衍生出来一个充值返利的需求，你怎么实现呢?难道直接把余额信息放大，那就会出现混乱，数据对不上了，看不明白。因为没有地方记录这次的充值还有额外的返利，返利多少，返利的规则是什么。
我要说的是我想到的一个办法，不知道现实中有谁做过类似的设计，肯定有系统有类似的需求，还希望大家赐教。
设计一个系统内部结算消费的币种，然后充值的钱和这个币种有某种规则匹配，比如说1:1，或者是1:5之类的比例，这样的话，就可以轻松解决充值返利的需求，而且顺便还可以解决多国货币的需求，因为我们系统内部消费结算使用统一的平台币，然后外部的任何币种都根据匹配规则换算成平台币来计算。不管是充值，还是消费，还是返利，还是结算，都是用统一的平台币，当然了，平台币对用户是透明的，最终用户看到的是自己的币种。甚至用户也可以有多种币种，都没有关系的，反正平台内部使用的是统一的平台币。
