前言

abp 把 用户功能模块独立好处有以下两点：

• 做微服务
• 项目复用

具体基于权限模块的设计如下图：

一、领域层

1.user表

用户通常是登录并使用应用程序的人。

IdentityUser

(aggregate root)：表示系统中的用户。

• IdentityUserRole（集合）：用户的角色。
• IdentityUserClaim（集合）：用户的自定义声明(用户扩展字段)。
• IdentityUserLogin（集合）：用户的外部登录。
• IdentityUserToken（集合）：用户的令牌（由Microsoft Identity services使用）。

用户表设计思想：

模仿：人去车站上车

​           人去动物园来动物

​           .....

需要一张票据，这个票据就是用户。

门票就是用户

不同的场景，用户的信息不一样，门票也不一样，为了适应不用的门票场景

所以：出现了用户声明，

2.role表

角色通常是分配给用户的一组权限。

 IdentityRole

(aggregate root): 表示系统中的一个角色。

• IdentityRoleClaim (collection): 角色的自定义声明(角色扩展字段)。

角色表设计思想：

动物园的角色信息，可能会有一些时间限制，显示：管理员，最多只能人质3年。

所以：就使用roleclaims表

3.claimtypes表

ClaimTypes（声明类型表）：是可分配给系统中其他实体（如角色和用户）的声明字段继承表。

• IdentityClaimType（聚合根）：表示字段类型定义。它包含一些属性（例如Required、Regex、Description、ValueType）来定义声明类型和验证规则。

声明类型表设计思想：

对于组织用户而言，公司用户都有相应的部门

所以：就有了用户部分表

由于不同用户可能属于同一个部门，所以，就有了部门表

4.SecurityLog表

“SecurityLog”对象表示系统中与身份验证相关的操作（如login）。

• IdentitySecurityLog（聚合根）：表示系统中的安全日志

5.organizationunits表

组织单元是层级结构中的实体。

OrganizationUnit

(aggregate root): 表示系统中的组织单元。

• Roles (collection):组织单元的角色。

部门表设计思想：

公司部门，去公司里面处理什么，都是有权限控制的。

所以：就有了部分角色表

6.linkuser表

用户关联表设计思想：

比如A用户登录，B用户就不需要登录就可以

7.userstoken表

8.userclaims表

用户声明表设计思想：

在动物园，一张门票，只能访问大象，不能看老虎。

所以：就是对动物园各个动物设置了权限

同理：用户拿票访问系统，也需要做一些权限限制。

所以：就出现了角色表

9.userroles表

用户角色表设计思想：

由于不同用户可能是相同的角色。所以就把用户角色抽出来，

形成了独立的角色表。为了能够复用

10.roleclaims表

角色声明表设计思想：

再进行思考一下，用户也有声明，角色也有声明，用户和角色可能会共享一些角色

所以：就有了claimtypes表

11.organizationunitroles表

部门角色表设计思想：

角色和用户一样都可以属于某个组织

12.permissiongrants表

权限表设计思想：

控制界面的增删改查

13.setting表

设置表设计说明：

配置一些系统信息

14.userorganizationunits表

用户组织表设计思想：

用户属于哪个部门

15.tenants表

租户表设计思想：

Tenant其实是各个服务中的一些可以访问的资源集合。这些资源集合可供多个用户使用，这也是为什么用户默认的总是绑定到某些tenant上。也是配置多租户的表，可以连接单个数据库也可以连接多个数据库

16.tenantconnectionstrings表

租户连接字符串表设计思想：

ABP配置多数据库多租户的表