账户体系的设计(1)
回来看看自己的博客园,自己总是三天打鱼,2天晒网。从flask到爬虫,现在啥也没学会,残念。
也许要一以贯之吧。
我是想说说账户体系的设计的。
但我没有什么强大的设计能力,而且我也总觉得账户设计这个事和会计没啥关系,不知道很多人为什么一定要扯上会计的事。
我们还是从第三方支付来只管感受一下,小白用户对账户的感受是咋样的?
直接就以微信支付来说好了,先看微信支付是否有账户?
我们觉得是有的。为什么有?因为我能看到一个自己有一个微信零钱的余额,也许可能余额是零也说不定。
回顾一下上面一句话,其实从我的理解来看,我们之所以说微信支付有账户,是因为微信支付有一个地方记录了我的微信钱包余额的变化。
这引出一个问题,微信钱包余额是啥?
我为什么会有微信钱包余额?我为什么要知道我的微信钱包余额的变化?
我们先从业务发生的角度来看,当我们使用银行卡向微信钱包充值的时候,我们就拥有了微信钱包余额。
那我为什么要充值呢?
因为微信支付钱包的余额可以让我发红包,或者去买个快餐。
那我为什么要关注微信钱包的余额呢?
第一,因为我的余额是我的一部分钱。
第二,根据微信支付的设计,当我的余额不足以支付时,我必须再充值。
这大概是我们用户对微信支付账户的一个理解。
当然可能和大家实际感受不是那么一致。
为什么?
因为微信支付不仅有账户的功能,他还做了一个“桥”的功能。
什么是“桥”?
就是我们使用银行卡快捷支付的时候。
当我们通过微信支付使用快捷支付的时候,我们其实和我们的微信余额半毛钱关系都没有,这个时候你其实用的是你的银行账户来支付,微信支付只是做一个桥。让你可以使用不是微信支付的东东也来支付。
好的,那我们现在说错了一些什么事情呢?
我知道转折的有些大。
这个可能还不是我们理解的一个账户。
因为从我们理解来看,我用银行卡快捷支付的时候,我感觉我也是在用微信支付的账户啊,反正我是这么感觉的。
我的证据是什么?或者说造成我错觉的是什么呢?
我可以通过查看微信支付的交易记录看到我所有的快捷支付。这你还说和微信支付账户半毛钱关系都没有?
也是哦,这会让我们再深入的思考账户这个玩意到底是什么?
我们再来头脑风暴一下,如果用一些词来形容账户,我们会想到什么?
实名认证,绑卡,余额,发红包,理财,查交易记录,被盗号了,密码
这里的感受是,账户这个东东好像有很多功能,实名认证就说明他一定记录了我的身份信息,比如我多少岁,性别是啥,姓甚名谁,身份证号码是多少,哪个国家的人,如果可能再细一点的话,可能还有我是干啥的,我的工资有多少,我是已婚还是未婚....
绑卡,是啥?这个账户还可以和其他账户体系关联。
余额是我们最开始说的账户的一些粗略印象。
发红包理财,查交易我们也说了一下。
被盗号?大家会不会突然想到我们是否有一个微信支付账户的ID呢?我们很清楚的是我们有身份证ID,我们有手机号码,我们是否有微信支付账户ID呢?好像是没有的。感觉像是我们的微信支付账户是跟着微信开通的,只不过我多点了一个确认信息。
那我可能微信账号被盗,微信支付账号不被盗么?
这涉及到一个密码的事了,微信支付单独设立了一个微信支付的交易密码。这个是微信账号被盗,我们微信支付账号不被盗的保护了。
我们零零散散的说了很多,其实就是想说,我们感觉账户是一个很大的综合体,感觉他好像啥事都参与了一些。
好像真的要仔细说明一个账户是很复杂的。
那我们不如换一个视角来看看,假设你自己是设计的人员,你设计的账户体系要把上面的功能全部完成,你要怎么设计?
假设我们把账户当一个对象来看的话,是不是他就会有很多玩意。
他有用户的身份信息,有用户绑定的卡的信息,他有用户所有交易的信息,有用户的密码,和他和哪些外面账户有关联。
这样一个对象是不是有些太大了?
是不是能更好的分层,来简化一下复杂程度呢?
网上有一些三户体系,我很敬佩的知乎梁川大神也提了一个客户/账户/账务的体系,说实话我都不是特别懂。
但我们也想冒险设计一下?
我们设计之前总是有些自己的原则和目标的,我自己的第一个目标是关于资金变化的信息,越少干扰信息就越好。
这个也不知道对不对,只是我的直觉。
对于编程垃圾的我,也只是在胡说不到,但我还是想扯一扯。
如果按照这样的层次划分话,
我想账户应该是很纯粹的一个东西。
他有啥信息?
有余额,有交易。
没了。
其实这个就和我一开始最初的印象基本一致。
那我们再来具体定一下,啥叫有余额?
我们的第一个问题就是,我不仅有微信钱包的余额,我还有理财通的余额,你这个余额是啥余额?
这就是我想说的第一个点。
从我的理解来看,这其实是2个账户。
一个账户就应该只记录一种余额。
而且其实也可以把这些账户都放在一起,互相之间产生交易。
或者说,我们想说的账户设计,不仅对微信钱包的余额有用,其实也应该对理财通余额也是有用的,或者说和你公交卡的余额也是有用的。只是上层功能会有不同。
最底层的账户设计应该是要通用的。
说完余额,我们再说说交易。
交易是一个令人疑惑的东西。
既然我们说了我们的账户是只针对零钱的账户,那你通过桥的交易,抱歉,在我们的账户,我们是不记录的。除非你的交易涉及到了我的账户余额发生变化,比如充值,那我会记录这样一笔交易。
当然你也可以把每一次银行快捷的支付都设计成为账户充值+账户支付的组合,但是这个又是后面的话题了。
然后我们在具体说说交易你到底要记录啥?
我们说交易其实在说啥,比如我通过余额给朋友转了一笔账,你觉得我们的交易是啥?
这笔交易是不是就是我的账户给我朋友的账户转了一笔钱?是的,就是这样。
我们还要再细说,我们为什么要记录交易?
其实上面的一个转账不就是我的余额减少了100元钱,我朋友的余额加了100元钱么?一减一加就完成了。
但是这样会产生几个问题。
第一,假设说我要查我之前有什么交易的话,我不知道。
第二,假设系统加错了,我朋友的余额加了200元钱,这个怎么办?我们是否能发现?发现之后是否能处理?
如果不记交易的话,我们就不知道这里加错了。
其实,从这里出发,可以看出,账户系统的很多设计,其实是为了当系统出问题时,我们能定位并发现问题。
如果我们要满足上面的几个要求,我们的交易该怎么设计呢?
这笔交易应该说名几个事情。
谁出钱,谁收钱,金额,时间,唯一编码
这样,当我们看到我朋友的余额加了200元钱的时候,我们就可以发现了他多家了100元钱。
等等,你是不是想多了?
你怎么发现?
你其实这样还很难发现,为什么?
你还缺一个事情,就是我的账户的流水。
我的账户加了一百元钱,我还必须记录一条流水,这条流水有啥信息呢?
唯一编码,金额,时间
这样你才可以发现。
具体怎么操作呢?
假设说我们要查我的账户是不是有没有操作错误?
我就把所有的交易拉出来,挑选出是关于我的账户的交易,然后吧这些单和流水比对,怎么比对,因为你们公用一个唯一编码,你就可以一条条比对,我是不是加错了还是加对了。
那这样的话,你也可以推而观之,把所有的账户都这样核对一遍,这样我们初步的账户体系也就设计完了。