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