用户管理设计
下图是版本一。
?
?
?
1. 权限：Privilege
权限应具有上下级关系，也就是管理级别。下面通过例子来说明
系统管理
? ? ? 用户管理
? ? ? ? ? 查看用户
? ? ? ? ? 新增用户
? ? ? ? ? ? ? ? 修改用户
? ? ? ? ? ? ? ? 删除用户
我把权限细分为三种类型，”角色权限“，组织权限，“一般权限”，我没有写成继承，而是用了一个枚举属性，因为我觉得他们没有明显的继承关系。
?
2. 角色Role
我觉得角色也可以有上下级关系，那样父角色就能拥有子角色的所有权限。但为了简单起见，没那么设计，树形结构不好维护。
?
3. 组织OrganizationUnit
组织就是一堆用户的分类。组织也具有上下级关系。
如果要做的通用，我觉得用户和组织之间应该是多对多的关系。
我是这么考虑的：例如我属于技术部，也属于北京分公司，也属于某个总公司。如果是多对一，那我是放在哪个组织下面好呢。当然应该放在技术部下面。如果要查询北京分公司下所有技术部的用户，还得首先知道这两个组织之间有几个父子关系。
?
4. 用户User
用户可以拥有多个权限，可以归属于多个角色，可属于多个组织。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组织具有的权限的合集。
?
下图是版本二
?
?
?
1. 权限Privilege
权限有名称，描述，类型三个属性。
2. 角色Role
角色是权限的聚合。有名称，描述，两个属性。
3. 组织OrganizationUnit
组织就是一堆用户的聚合。组织也具有上下级关系，是树形结构。
4. 用户User
用户可以有多个角色，属于一个组织，并有一个管理组织，默认为当前组织。
?
比较：
?
下面开始说明为什么版本二比版本一好很多。首先设计的原则是简单通用。越简单当然会越通用。版本二看起来比版本一简单很多。也比较直观，权限聚合成角色，角色聚合成用户，用户聚合成组织。组织有上下级关系。
?
关于权限。权限是一个独立的个体。可以单独存在。角色包含权限，而不应该是权限包含角色。组织和权限不应该关联，这样关联后系统会很复杂，可以在用户里加一个属性managerOrgnization来解决问题。另外权限不用设计成树形结构。树形结构只会让系统越来越复杂。而且一组权限的parent可以理解成某个角色。
?
关于角色。角色是权限的聚合。
?
关于组织。这个很好理解。企业系统里必然会有上下级别的关系，为什么其他三个model没有设计成树形，而在这把OrganizationUnit设计成树形。从上面的聚合箭头可以看出，最终聚合到OrganizationUnit这。中间任何地方设计成树形结构都只会增加系统的复杂度。
?
关于用户。用户不用设计成树形结构，应该用户所属的组织已经有了树形。另外用户不应该直接和权限关联。当然某些特殊的系统需要把权限分配到用户上。那只在某些权限比较分散的系统里，而且权限没有像样的分组，那才需要把权限分配到用户，比如maven私服，svn。否则把权限分配到角色，在有个管理组织属性，基本就能满足大部分需求了。
?
?
