前言
本文从最原始的需求出发,结合需求变化,推导出用户系统的演进。(如果有理解偏差之处,还请谅解,欢迎讨论)(故事纯属虚构)
一、创业
老王是程序员,出去创业了,做当下最火的web3.0,需要做app和web,第一步需要一个用户登录功能,这对老王来说简单。用户可以拿邮箱或者手机注册,填一些基本信息(如名称、性别、年龄等),初始化密码,提交后给用户生成平台唯一id。用户可以拿手机或者邮箱登录,设计如图,搞定了。
二、新增需求-三方登录
产品经理提出为了方便用户快速注册,借助当前用户量最大的平台,实现授权登录,授权登录后经过用户授权从大平台那里拿用户基本信息(手机号,邮箱等等),避免用户注册耗时原因导致用户放弃注册的流失。安全同学也提出了,有可能用户邮箱泄露,黑客拿着邮箱来调用平台的登录服务暴力破解密码,需要限制验密错误次数以及冻结功能等。老王想了想,简单,在模型中扩充一些字段就可以解决。把市面上比较火的平台id都预留一下,免得后面一个一个加;同时在把验密失败次数或验密失败时间记录下来,一旦达到一定次数,就不允许调用登录服务。
三、新增需求-用户类型区分
由于业务的发展,用户不在局限于个人用户,一些公司也需要入驻进来,显然,年龄、性别等信息就不再适合给公司用户使用了,到这里,模型必须要拆分了。老王希望把模型拆成继承关系,用户表作为父类,可以延伸出公司用户和个人用户,如下图所示。
四、业务扩张了
老王的创业公司发展迅速,开始融资了,不仅nft搞得如火如荼,还要搞某币交易。某币交易涉及到金融(我们假设老王创业的地方监管环境允许),那么需要进行实人(实体)认证,需要知道用户在法律意义上到底是谁。这里的需求,已经不是纯用户角度了,而是知道你的客户是谁,已经开始向客户系统演进。另外由于涉及到某币账户操作,因此需要搞一个交易密码,现在很多设备都支持指纹和人脸了,产品希望指纹和人脸也能支持。老王接到了以上需求,他开始思考以下几个问题:
- 密码:现在密码种类变多,从登录密码扩展了交易密码;另外交易密码可以支持普通密码、指纹密码、人脸等子类型。
- 登录方式:之前的设计太粗暴了,扩展性很差,之后如果要支持身份证登录,或者营业执照号登录,都需要再加字段。
- 实人(实体)认证:真实世界的人或者企业,与之前系统模型中的用户是一个概念吗?假如没有监管的要求,之前用户模型里边的信息,就可以支撑用户在平台上的各种使用诉求(登录、信息显示等等)。
4.1 登录方式
我们思考一下为什么会有登录方式,登录方式是用来确定系统中的哪个用户正在进行操作(这里先不考虑账号被盗的情况)。只要登录进来,就能在系统中确定是某一个userid(系统内部唯一标识),登录后的所有操作,都可以通过userid来留痕。
登录方式总共有多少种?能穷举吗?目前行业里的登录方式实现基本包含以下几种:
- 电子联系方式:手机号、邮箱,用这类方式有个很好的收益,就是密码管理,如果出现被盗或者忘记密码,可以多因子认证(验证码)找回在平台上的账号。
- 证件号码:身份证、营业执照号等,这类登录方式在政务系统上比较常见,政务系统一般希望直接服务社会上的实人或者组织。
- 系统生成的id:系统中的唯一id,QQ是最典型的例子,注册QQ会生成一个qq号,需要用户记住直接拿QQ号作为登录名。
- 三方登录:通过oauth协议,在客户授权的前提下,获取用户在第三方平台的部分信息,比如头像、昵称、唯一id,进行授权登录。
总结一下上述的多种登录方式,除了系统生成的id登录,其他三种都是通过外部系统唯一标识登录,登录系统实际就是维护一个用户记忆的系统外部唯一标识 ——> 系统内部唯一标识的关联关系。而外部系统唯一标识可以有千千万万种,并不能穷举,那么就不能像userV2版本中通过字段的模式,每次新增字段解决。通过以上的分析,老王从模型层面讲登录方式从用户模型中拆了出来,如下图所示。loginType可以是邮箱、手机号、支付宝、身份证、甚至银行卡号,这些都是能够定义注册人是谁的外部唯一标识(这些标识不可能同时被两个人拥有)。这样,任何外部唯一标识都可以作为系统的登录方式,找到系统中的用户,模型做到了高度可扩展。
4.2 密码
基于上述需求,密码首先需要定义分类,现在有了登录密码和交易密码的区别,同时交易密码要支持普通密码、指纹密码、人脸密码三种密码,因此再定义一个subtype来标识,如下图所示。那么密码和登录方式的关系是啥?是不是每一个登录方式都要定义一个登录密码?显然不是,用户在平台有多个登录方式(登录名:手机、邮箱等),但是不可能让用户每个登录方式都维护一个密码,用户记密码、维护密码都累死了。那么,显然登录方式和登录密码的关系是N:1的。但是,交易密码怎么实现呢?交易密码是用户维度在交易时的验证,因此,每个用户只需要一个交易密码,那么,我们将模型设计成如下这样,每个用户可以有多种密码,但是在登录的主类型(type)下,只有一个密码。在交易的主类型(type)下,有三个密码,靠子类型(subtype)区分开(数字、指纹、人脸)。
总结一下密码这么设计的好处:
- 不同登录方式之间可以共享登录密码,用户不用维护多个登录密码;
- 密码根据类型、子类型可以支持多种密码同时存在;
好像登录和密码这么设计很完美了,想一想有没有什么问题。
4.3 实人认证
大部分互联网应用,平台并不用知道注册人的真实信息,互联网精神就是自由开放,有一句上个世纪流行语,你永远不知道网络的另一边是人还是狗。但是也有一些业务必须知道注册人的真实合法的信息,才能完成业务,比如金融业务,监管要求必须实人认证还有附加的限制规则。比如一些toB的CRM业务,会维护潜客、客户的真实信息,甚至是客户公司的经营情况,这里就涉及到了真实世界是否存在的认定。因此,我们需要在系统中记录真实世界的合法标识,对于个人有身份证、护照,对于企业有营业执照。那么是不是直接在用户模型中添加一些字段就搞定了?可以这么做,但是有个问题,一个人完全可以在平台中注册多个账户,如果在用户模型维度来承载实人信息,那么每个注册的账户都要维护认证状态,显然是不合理的,如果能够做到一个真实世界的实体(人、组织),在系统中只维护一份,针对这一份认证相关的数据进行维护,无论这个人注册了多少个账号,都关联到这份实体信息上,那么实体是认证过的,所有账号都是认证过的。那么很显然,由于真实的人和用户在系统中是1:N的关系,在这里抽象了新的模型,我们可以把它命名为客户,模型扩展后如下图所示。客户和用户的设计类似,是一体两面的。一个人的真实信息属于客户这个领域,而一个人在平台里边可以有多个账号登录,使用平台的服务,因此系统中为了登录和现实信息相关的数据,都属于用户这个领域。没有客户域的数据,是可以在系统中运行的(使用系统服务),这就是用户领域的职责。那么客户领域的职责是什么?我认为是维护客户关系,要维护客户关系第一步是知道你的客户是谁,是不是真实的,在这之后,就可以进行营销相关的操作,将客户从潜客发展成资深客户,同时不断完善客户信息,包括不限于真实信息、喜好、消费习惯等等。所以,实人就是客户信息建设的第一步。
4.4 其他问题
到这里模型好像已经很强大了,对于老王的创业团队来说可以支撑很多情况,我们在回顾下整个模型,客户是真实世界存在的实体的反映,登录方式是断定注册人是谁的外部唯一标识,这两个概念互相之间貌似是有关系的。也就是说,登录方式里边的手机号、邮箱都是真实世界的实体所拥有的唯一标识。同一个手机号不可能同时被两个人拥有,并且用作平台的登录名。那么在4.3提到,一个人在平台上可以有多个账户,比如张三,刚开始作为nft的用户用手机号注册了一个账号,过了一段时间他开了一家公司,想在平台上开店,张三希望还是用这个手机号来登录(这个例子举得并不恰当,大家不要当真)。这个场景下,登录方式和用户变成了1:2的关系。
手机号作为我的唯一标识,我希望在一个平台只需要手机号就能登陆,同时我在平台可能有多个身份,因此登录方式需要升级一下。无论有多少登录方式,都是为了识别出真实世界的人是谁在登录,因此抽象实体外标并分配一个id,就代表了这个人在登录,登录成功之后,可以选择具体的身份,比如个人用户或者企业用户。密码模型不再和userId强关联,抽象出targetEntity字段可以对登录、用户甚至客户等维度做密码验证。当前登录密码场景直接通过实体外标的id关联,交易密码场景通过userid关联。到这里,整个模型比较完备了。
五、总结
总结一下前边的模型,简化下来就是下图的关系,登录名就是标识,系统用来判定实际是谁在注册,用登录名登录后,可以选择一个身份在系统中操作,可以是卖家(经营店铺),也可以是买家(逛店+购物),还可以是客服(负责与买家沟通,处理异常订单)。该模型中每一个抽象都充分考虑了业务场景的需求,非常灵活,可以支撑大用户量级的各种需求。