账号C
获取应用服务
应用资源模型 定义
一个用户可以有多个账号
用户N#账号N
账号B
账号N
关联操作产生account_role
RBAC通用权限数据模型定义领域
商家B#商超C
应用B
应用A#API-1
用户A#ID标识
用户A#公司-2
商超A#仓库A
应用市场
关联操作产生role_resources
商家A
商超N#仓库B
申请成为租户
应用C#角色A
应用C#权限标识-1
商家N
应用C#API-1
应用A
商家C#仓库C
用户A#地址-N
用户A#地址-3
商家A#商超A
应用A#角色N
应用列表
商家B
授权-2
应用菜单模型 定义
商家#仓店实例
用户A#工作-2
应用N
APP-1
用户中心
仓库B
子集
商家仓店组织架构
4
商超C#仓库C
授权
开发者A#应用A
accredit授权逻辑
用户地址维度
租户平台
租户A#应用B
用户A#地址-2
商家A#商超B#账号B
开发者C
商超N
入驻商家
应用C#菜单标识-1
开发者A
用户A#公司-3
用户N#ID标识
仓库
菜单列表
云平台-权限模块
租户
仓店域
用户A#账号A
商家C#仓库C#账号C
商家N#商超N#账号N
租户B
账号中心
商超A
关联仓库
商超B
租户-云平台-SAAS
关联商超
商超C
用户A#工作-3
3
商家域
用户A#N-3
开发者
注册
商家A#商超A#账号A
应用A#权限标识-1
用户A#公司-1
关联店铺
SAAS化
user-1
开发者应用
用户A#公司-N
应用模块
APP-3
用户公司维度
租户A#应用A
用户A#账号B
开发者B
应用权限标识模型 定义
用户账号实例
租户B#应用A
创建账号映射账号
account-2
本质上可以直接申请成为租户，但一般会有一些条件约束即，申请成为租户需要完成实名认证，同时需要完成用户公司维度的信息认证系统会为其生产一个商户号，用改商户号去创建一个租户，这个也可以直接粗暴的由账号来触发创建
用户工作维度
账号A
用户B#ID标识
云平台-SAAS
account-3
关联操作产生role_premission
user-2
入驻开发者
用户C#ID标识
云平台-用户模块
商家
云平台-账号模块
用户B#账号C
归属
应用A#权限标识-n
仓库C
一般条件
唯一账号序列
发布应用到应用市场
商超B#仓库A
应用角色模型 定义
开发者A#应用B
应用A#菜单标识-1
招聘员工
商家A#商超B
应用A#菜单标识-n
授权-1
account-1
应用A#角色A
应用C
应用A#API-N
用户A#工作-1
1.先有账号，现实世界中的人去注册一个叫A的应用，会得到一个账号（A应用会为其生成一个账号，这个账号下所由的数据都应该关联到这个应用（appid）2.接着要为这个账号分配一些权限（授权），在分配权限之前需要为A应用定义出角色模型和资源模型，这样才可以通过授权给当前账号有哪些角色，因为不同的角色又对应不同的资源（标准RBAC）3.此时以上的场景中是一个应用，当有多个应用时应该怎么办？一个很实际的问题是一个公司有多个应用，难道每个应用都需要去创建一次账号，完成一次授权，完成一次实名认证？那么这对用户是多么的不友好！对一个公司来说系统的数据又是有多么的冗余？还有其他一些场景，比如商业化，我们的服务是否能为其他行业赋能？因此基于以上的这些问题，你是否也有了答案？4.租户的设计理念也因此产生，软件即服务，这里的解决方案是，此时账号可以去申请为租户（基于能力的扩展），即当前账号ID关联了一个租户ID，也可由该账号完成实名认证之后，并且完成了用户公司维度信息的认证并为其生成一个商户号，用这个商户号去产生一个租户（比较严谨和符合客观世界一点），账号和或用户公司和租户是1：1的关系5.最后是通过saas化动作完成租户和应用的关联，一个tenantId对应多个appId（一个租户可对应对多个应用，一个应用是一系列的资源的集合），一个账号在一个应用下（每一个应用有自己可以独立的权限体系，通过appId唯一标识）一个应用在一个租户下，一个租户依托于一个用户。
商超
租户应用列表
用户中心/用户实体通用模型领域
APP-4
租户N
仓库A
开发者平台
用户A#N-1
用户A#N-2
APP-2
仓库N
用户A#工作-N
租户A
用户A#N-N
用户N个维度
用户A#地址-1
开发者C#应用C
商超#仓库实例
租户C
商家C
