2. 角色实体设计
角色是权限模型中最核心的实体。本章围绕角色的定义边界、层级化组织、继承关系以及属性设计展开，为后续权限分配与数据流控制奠定实体基础。
2.1 角色定义与边界
角色（Role）本质是一组权限的集合，代表系统中一类用户的功能权限与操作范围。边界定义需明确：
- 职责域：角色仅描述“能做什么”，不包含用户个人信息、组织归属等实体属性。
- 粒度级：角色应独立于具体用户实例，同一角色可被多个用户、用户组共享。
- 互斥性：同一用户在同一上下文中无法同时持有两个互斥角色（如业务审核员与业务经办员）。
定义检查清单：角色必须满足“职责聚焦、独立可复用、不附带非权限属性”三个约束。
2.2 角色层级结构
大型B端系统通常采用多级角色分层，以适配组织管理复杂度。常见分层模型如下：
| 层级 | 示例角色 | 权限范围 | 典型用户 |
|---|---|---|---|
| L1 平台级 | 超级管理员、系统审计员 | 全局配置、租户管理、系统日志 | 运维管理员 |
| L2 租户/组织级 | 组织管理员、组织安全官 | 本组织下用户、角色、资源管理 | 企业IT管理员 |
| L3 部门/项目级 | 部门经理、项目主管 | 部门内数据审批、任务分配 | 业务部门负责人 |
| L4 基础操作级 | 普通员工、外部协作员 | 自身业务操作、信息查看 | 一线员工 |
上述层级关系通过角色属性中的level字段标识，便于权限过滤与继承控制。以下SVG展示了典型的角色继承树结构：
2.3 角色继承关系
继承关系用于减少权限冗余，提高维护效率。核心规则：
- 单继承：每个角色只能有一个直接父角色，形成树状结构；避免多重继承导致的权限冲突。
- 权限累加：子角色默认继承父角色的全部权限，可在子角色上额外添加或移除（仅限白名单/黑名单模式）。
- 继承阻断：当父角色发生权限变更时，影响所有子角色；若需要隔离，可使用“快照复制”或“冻结继承”策略。
团队实践建议：建议将继承层级深度控制在4层以内，过深会导致权限溯源困难。使用“角色血缘图”定期审计继承链。
2.4 角色属性设计
角色实体应包含以下基本属性（字段定义供数据库与接口设计参考）：
| 属性名 | 类型 | 说明 | 示例 |
|---|---|---|---|
| roleId | UUID | 全局唯一标识 | r-00123-abc |
| roleName | String(100) | 角色显示名称 | 组织管理员 |
| roleKey | String(50) | 唯一业务编码，用于代码引用 | ORG_ADMIN |
| level | Integer | 层级标识（1-4），用于权限过滤 | 2 |
| parentId | UUID | NULL | 父角色ID，NULL表示顶层角色 | r-00000-root |
| description | Text | 角色职责描述 | 管理本组织所有用户和资源 |
| status | ENUM | 启用/禁用/归档 | ACTIVE |
| createdAt | DateTime | 创建时间 | 2025-03-01T08:00:00Z |
设计考量：
roleKey 用于权限矩阵与代码硬编码，建议使用大写字母+下划线；level 需与角色层级规范对齐，避免越级继承。
2.5 角色权限矩阵（示例）
以下矩阵展示不同角色的典型权限分配，基于RBAC+层级继承：
| 功能模块 | 超级管理员 | 组织管理员 | 部门经理 | 普通员工 |
|---|---|---|---|---|
| 用户管理-创建 | ✔ | ✔（本组织） | ✘ | ✘ |
| 用户管理-删除 | ✔ | ✔（本组织） | ✘ | ✘ |
| 角色管理 | ✔ | ✔（本组织内） | ✘ | ✘ |
| 数据报表-查看 | ✔（全局） | ✔（本组织） | ✔（本部门） | ✔（仅自己） |
| 审批流程-执行 | ✔ | ✔（本组织） | ✔（本部门） | ✘ |
| 系统配置 | ✔ | ✘ | ✘ | ✘ |
常见坑点：权限矩阵必须与角色继承规则联动，避免出现“父角色无权限，子角色却通过继承获得”的逻辑矛盾。建议在角色创建时自动校验继承链权限覆盖性。
2.6 落地风险与权衡
- 继承深度过深：超过5层后，权限生效路径复杂，可能导致性能下降和审计困难。建议限制层级+使用缓存预热。
- 权限爆炸：每个角色都自定义微调，导致角色数量膨胀。引入“角色模板”和“角色分组”来收敛。
- 角色与组织解耦不足：角色属性中包含过多组织上下文，导致复用性降低。应保持角色本身与组织无关，通过“角色-组织绑定”表实现范围限制。
对标业界：类似AWS IAM的角色分层设计（Account Admin → Organization Admin → Service Admin → User）可作参考，但其继承模型更为扁平，值得根据业务场景权衡。