用户管理设计

下图是版本一。

 

 

 

1. 权限：Privilege

权限应具有上下级关系，也就是管理级别。下面通过例子来说明

系统管理

      用户管理

          查看用户

          新增用户

                修改用户

                删除用户

我把权限细分为三种类型，”角色权限“，组织权限，“一般权限”，我没有写成继承，而是用了一个枚举属性，因为我觉得他们没有明显的继承关系。

 

2. 角色Role

我觉得角色也可以有上下级关系，那样父角色就能拥有子角色的所有权限。但为了简单起见，没那么设计，树形结构不好维护。

 

3. 组织OrganizationUnit

组织就是一堆用户的分类。组织也具有上下级关系。

如果要做的通用，我觉得用户和组织之间应该是多对多的关系。

我是这么考虑的：例如我属于技术部，也属于北京分公司，也属于某个总公司。如果是多对一，那我是放在哪个组织下面好呢。当然应该放在技术部下面。如果要查询北京分公司下所有技术部的用户，还得首先知道这两个组织之间有几个父子关系。

 

4. 用户User

用户可以拥有多个权限，可以归属于多个角色，可属于多个组织。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组织具有的权限的合集。

 

下图是版本二

 

 

 

1. 权限Privilege

权限有名称，描述，类型三个属性。

2. 角色Role

角色是权限的聚合。有名称，描述，两个属性。

3. 组织OrganizationUnit

组织就是一堆用户的聚合。组织也具有上下级关系，是树形结构。

4. 用户User

用户可以有多个角色，属于一个组织，并有一个管理组织，默认为当前组织。

 

比较：

 

下面开始说明为什么版本二比版本一好很多。首先设计的原则是简单通用。越简单当然会越通用。版本二看起来比版本一简单很多。也比较直观，权限聚合成角色，角色聚合成用户，用户聚合成组织。组织有上下级关系。

 

关于权限。权限是一个独立的个体。可以单独存在。角色包含权限，而不应该是权限包含角色。组织和权限不应该关联，这样关联后系统会很复杂，可以在用户里加一个属性managerOrgnization来解决问题。另外权限不用设计成树形结构。树形结构只会让系统越来越复杂。而且一组权限的parent可以理解成某个角色。

 

关于角色。角色是权限的聚合。

 

关于组织。这个很好理解。企业系统里必然会有上下级别的关系，为什么其他三个model没有设计成树形，而在这把OrganizationUnit设计成树形。从上面的聚合箭头可以看出，最终聚合到OrganizationUnit这。中间任何地方设计成树形结构都只会增加系统的复杂度。

 

关于用户。用户不用设计成树形结构，应该用户所属的组织已经有了树形。另外用户不应该直接和权限关联。当然某些特殊的系统需要把权限分配到用户上。那只在某些权限比较分散的系统里，而且权限没有像样的分组，那才需要把权限分配到用户，比如maven私服，svn。否则把权限分配到角色，在有个管理组织属性，基本就能满足大部分需求了。