用户系统的设计
前言
设计用户系统可能是Internet或SaaS应用程序中最重要的部分。在过去的十年中，我一次又一次地看到错误的设计，当您稍后意识到设计缺陷时，这会花费多倍的努力去改善。 例如，我曾经使用过一个运行着超过80亿美元的系统，它将用户和帐户混合到一个表中，几乎不可能将整体代码分为user和account两个服务。 最终，我们必须在错误的设计之上解决问题，并使系统更加hacky，难以维护。 因此，我只是希望我能写一些东西与大家分享，以避免在您的早期设计阶段再次发生这种情况。
一个过于简单的系统
让我们从一个非常简单的应用程序开始。 此应用程序永远不需要财务账户(financial account)或客户身份验证标识(customer identity)，这将是非企业客户的典型用户系统（我们稍后将讨论企业客户）。 客户(customer)或用户(user)可以在此处通过电子邮件或Twitter OAuth2注册，如下图所示。 一切看起来都很好，对吧？
这里的问题是，我们不知道他们是谁。这为反欺诈带来了障碍。假设您有一个市场营销活动，并且只有新客户才有资格使用某些优惠券。如果没有身份信息，客户可以通过Twitter和电子邮件进行注册。要停止这种情况，您需要额外的算法来检测重复的客户。
另一个问题是，这种设计通常对于业务增长而言过于短视。在开始阶段，您认为您的应用程序不需要明确区分客户(customer)/用户(user)/帐户(account)，但是一旦您的应用程序具有新功能（尤其是财务功能）发展后，您将遇到大麻烦。
要提供财务功能，您可能需要先KYC（了解客户），然后才能为客户设置任何财务帐户。这意味着，以后您将需要来自客户的身份信息，例如营业执照或SSN，只有在识别并验证了客户之后，您才能为他们创建财务帐户。
一个基本能用的系统
验证客户身份后，在为客户开设帐户之前，您可能会遇到用户合并问题。 因为两个用户可能是同一位客户，所以您可以知道，在验证用户身份之后，也许您拒绝为第二个用户开设帐户，也许您需要设计和实现某种用户合并过程。 后一种选择通常非常痛苦。 例如，如果您的应用程序是销售系统，而您的客户之一注册了两个用户，则分别用于国内和海外销售。 他已经在两个用户中有一些客户，现在他要使用一些需要帐户的财务功能，您的系统需要引导他提供迁移向导以将两个用户合并为一个。
新设计如下图所示。
eTOM三户体系
有了用户身份验证，用户合并和金融帐户系统，我们完成了吗？ 不。 实际上，我们还需要如下区分客户(customer)和用户(user)的概念。 …
这是为什么？ 原因是，随着客户业务的增长，你可以雇用其他人来帮助您，这样您就可以为更复杂的客户（企业客户）提供服务。 而且，您最好在早期考虑这些情况，并实施更通用的用户系统。
企业客户比个人客户复杂得多，因为企业通常由多个用户运营，通常需要RBAC和IAM，或更复杂的身份验证和授权系统。 现在，您实际上需要eTOM用户系统。
eTOM（enhanced Telecom Operations Map）是电信行业中企业流程的框架。 它是一组标准，模型和最佳实践。 首先介绍了三个概念的分离：客户(customer)/用户(user)/帐户(account)。
客户(customer)被定义为法人实体(legal entity)，它可以是企业客户或个人客户，我们必须识别或验证客户。有多种识别客户的方法。例如，个人客户可以根据州系统通过其驾驶执照或SSN进行验证，而企业客户可以根据州税系统通过其营业执照进行验证。在某些国家/地区，这些政府系统的状态不稳定或尚未就绪，您可能还需要其他解决方案，可能需要手动解决。但是，身份验证在SaaS中极为重要，尤其是在您必须遵守KYC的金融系统上工作时。
在大多数情况下，客户总是注册以在系统中创建用户来登录。然后，企业客户（包括小微企业，个体户）可以为不同目的在系统中创建很多用户，如下图所示。换句话说，用户可以是企业，集团或雇主的雇员，并为法人实体行事/经营。
以下是针对企业用户的典型设计，实际上，大多数IaaS / PaaS提供商在设计其用户系统时都遵循此模式。
实现困难
客户身份验证
如果您的系统需要对客户进行身份验证，那么实际上在很多情况下通常很难实施。 例如。 对于个人客户，他/她可以使用不同的身份信息（例如SSN，护照，驾照）进行多次注册。 除非您具有交叉验证机制，否则无法链接它们，您的系统最终将拥有3个客户，而这些客户实际上来自同一个人。 大多数国家或地区不提供此类交叉检查服务或API(比如欧洲的AML)。 对于小型企业SaaS应用程序，最好只保留一种验证方法。 对于大型企业实体，这并不是什么大不了的事情，因为每个客户的ARAP值很高，值得您用不同的标识手段逐一手动验证（统一社会信用代码，电话等手段）。
用户合并
正如我在本文前面所提到的，即使您有一个简单的用户系统，也要进行客户身份验证，并且您可能会看到两个用户实际上是同一位客户，那么您需要合并这两个用户，或者从中迁移客户数据。 一个到另一个。 这很难使流程顺利进行，对于C端产品因此有时我们只能允许其中一个进行验证，而对比B端产品这种情况很少（除了小微企业和个体户）。
客户身份验证挑战
如果用户仅用他的电话号码注册（没有Twitter或WeChat OAuth，没有电子邮件），后来他更改了电话号码，则他可能将无法再次登录，因为他将永远不会收到SMS验证码。因此，我们始终需要鼓励用户使用多种身份验证方法，并结合用户的私人标识和历史行为数据来设计更轻松的更改身份验证的过程。(比如身份证号码和上次访问时间)
另一种情况是，如果用户A离开了您的应用程序并更改了他的电话号码，则两年后，电信服务提供商可以将该电话号码分配给另一个用户B。当B尝试注册时，他将看到“电话号码已经注册”。那么当他尝试登录时，我们不能让用户直接使用SMS验证码登录，因为那将使用户B登录为用户A， 用户B会看到A的历史数据。为避免这种情况，我们需要分析历史用户行为数据并检测此类情况（例如新设备ID），然后提示用户提供更多信息以验证客户身份。如果发现这是老用户A长期没有访问而已，那么允许他进入。如果发现是个新用户，我们需要设计一个过程来删除用户A的电话号码，并允许用户B使用该电话号码进行注册。
Conclusions
在业务开始之初拥有精心设计的类似eTOM的用户系统将在下一个十年使您受益，如果没有它，您将来可能会花费更多的精力来修复它。 希望本文能对您有所帮助，并帮助您避免在许多公司中犯的错误。