我和一些来自学校的朋友在一家新创业公司工作，我正在开发一个REST API作为Web应用程序/网站的后端。我最近已经开始大肆宣传，对大型项目没有多少经验。
如果不详细了解具体的商业理念，那将是一种“共享经济”。服务，例如uber或airbnb，用户注册为特定服务的客户或提供商。因此，用户需要注册一个帐户并拥有与该帐户相关的数据。
API是使用ASP.NET Web API开发的。对于身份验证/授权，我使用ASP.NET Identity和JWT作为带有OWIN OAuth中间件的Oauth承载令牌。
我在部分设置中使用了指南，并进行了一些更改以适合我们的设置 项目。 （只需搜索＆＃34; bitoftech在ASP.NET Web API和Identity 2.1＆＃34中实现OAuth JSON Web令牌身份验证;如果您感兴趣，可以找到它。）
对于那些不了解的人，ASP.NET Identity数据库如下所示： ASP.NET Identity database diagram.
因此，我们有一个代表用户的AppUser表，其中角色，声明和登录附加在Identity数据库的不同表中。
现在，用户在我们的应用程序中有许多与其帐户相关的其他数据，例如消息（用户可以互相发送消息），事件（如果这是优步的话），类别，评论，文件和其他数据。全部在单独的表格中。
因此，由于所有这些其他表都与用户身份相关，我所做的就是将所有这些其他表放在同一个数据库中，并使用AppUser表中Id的外键。
每个用户在IdentityRole表中都有Customer或Provider（如Uber示例中的客户或驱动程序）的角色。 这样我就可以根据角色授权用户，也可以根据角色查询数据。
现在抓住了：意外的需求变化。该公司已决定他们（我们）想要创建类似的服务（与客户和提供商），但在不同的业务领域，并具有相同的用户身份。因此，不应要求已经在一个站点注册的用户再次使用其他站点的新帐户注册，而只需使用他们现有的帐户（也可以通过单击他们的个人资料中的按钮等来注册新站点）
因此，如果第一个网站是超级网站，那么现在我们想要创建airbnb（不是真的，但作为一个例子）。
新网站中的数据与第一个网站非常相似。用户将拥有消息，事件，类别，文件等。但事件表可能会有所不同，可能是新站点的一些新的或不同的表。我们将首先尝试保持数据非常相似，因此我们可以使用大部分现有代码，但我们希望 - 如果网站变得流行 - 它们将在（在代码和数据方面）分开时间。
首先我想：＆＃34;如何更改现有的数据库模式以使其适合这两种服务？＆＃34;。但是，当我更多地考虑它时，我认为这可能只会在将来产生问题。
在Oauth flow diagram中，您有一个单独的资源服务器和授权服务器。即使我现在使用Oauth，我的API也是资源服务器和授权服务器，如果它们没有以我描述的方式耦合，那可能会好的吗？
所以我的问题是：
1： 我是否应该为用户身份（IdentityDbContext）使用一个（单独的）数据库， 和所有其他数据的另一个数据库（事件，消息等）？
这样，如果需要，Identity可以在完全不同的服务器上运行，而不是与任何特定的域/站点/服务耦合。这是个好主意吗？
2： 如果是这样，我将如何在数据库之间建立关系？
我唯一能想到的是在＆＃34; Uber＆＃34;中创建一个单独的用户表，其中只有UserId（来自Identity数据库）。数据库，这将在用户首次注册站点时创建，所有其他数据都与此密钥相关。然后我需要查询来自两个数据库的数据并将它们放在一起进行某些操作，例如，当用户查询其传入的消息时，消息本身将在一个数据库中，而发送者的名称在另一个数据库中。还有更好的方法吗？
3： 我应该为第一个和第二个网站/服务使用单独的数据库（一个用于优步，一个用于Airbnb，如示例中所示）？或者有更好的方法吗？
4： 是否有其他解决方案，我没想过会更好？
许多人之前可能遇到过这些问题，所以如果有经验的开发人员能告诉我最佳做法，我将不胜感激。
最后，更多的服务将被附加＆＃34;并不是不可能的。如果我们当前的努力成功，将来的用户身份，所以我真的需要一个面向未来的解决方案来解决这个问题。
感谢您的回复。
答案 0 :(得分：0)
这种方法似乎有点普遍：
维护一个完全独立的身份数据库。任何业务线（LOB）数据库都不应该存在任何连接。
每个LOB数据库都应该有自己的用户表，并对其他LOB表具有适当的参照完整性约束，例如：您案件中的事件或消息。
当用户第一次点击您的某个LOB网站时，他应该“登记”在LOB数据库中。插入LOB用户记录。使用访问令牌调用身份服务器以获取您的LOB站点所需的任何人口统计信息。
当用户第N次点击您的某个LOB网站时，您可以使用访问令牌来呼叫身份服务器并获取最新的最新人口统计信息，以防万一它自上次访问以来发生了变化。然后，您可以将此信息存储在LOB用户表中，以便脱机使用它，例如如果您需要推送营销电子邮件，您将拥有该电子邮件地址的副本。
这种方法的优点是可以分离关注点和支持多个身份验证提供程序的能力（例如，将来您也可以支持Facebook或Google+登录）。
此外，您还可以避免身份服务器和LOB服务器之间的任何依赖关系，因此您可以根据需要添加或删除业务线，并使身份服务器保持良好和轻量级。
