最近对就有系统人员权限升级计划――也谈人员权限的设计。
前言：
人员、机构、角色、权限对象间组织关系的重新抽象；
人员、机构、角色、权限；
这四个经过抽象的对象原型经过事实证明还是比较成功的；
这几个对象不会有大的变动；
但是实际中也碰到了问题，就是这些对象之间关系的不确定性；
下面描述以下四个对象新的关系结构；
1 核心思想：
1。人员在系统中总是扮演某种角色的；
例如：小张在属于办公厅这个部门，以前我们都倾向于认为办公厅聚合了小张。
其实考察一下实际情况，办公厅下面有个办公厅人员这个角色，而小张只是扮演了这个角色而已；
考虑一下如果当小长被调动另外一个部门时候那种抽象更容易处理。
2。业务逻辑希望面对的是系统中的角色，而非扮演角色的具体的人。
例如：以工作流示例，一个公文的下一步流转的对象是组织部部长，他不关心谁扮演这个部长，人员权限模块知道就行了。
2 抽象关系描述：
.人员和机构之间的松耦合（通过角色耦合）
目的：改变糟糕地人员和机构之间的强聚合关系。
人员和部门通过角色进行耦合；
人员和部门的关系可以容易的变化，不会产生大的影响。
.人员和角色间变成强聚合关系；
目的：强调人员在系统中必须扮演角色，起码扮演某个机构的人员这个角色；
人员的角色又可以同时扮演的，也有互相排斥的。
排斥的角色就是不能同时扮演的，登录以后可以选择的角色；
由管理员规定人员的那些角色是相互排斥的；
.机构和权限点之间没有直接关系；
目的：让机构的抽象更清晰化，机构和权限的关系通过角色体现；
.机构和角色之间强聚合关系；
目的：明确部门的作用是行使某种特定职能的。
说明：
部门和部门之间还有从属关系；
部门可以专门设置部门管理员用于管理下级的机构和人员，使分级管理在模型上成为可能；
部门拥有的角色有写是系统规定的，如：部门人员，部门管理员；
部门可以自定义自己的角色，并由部门管理员管理；
.角色之间的继承关系；
目的：更好的处理角色和权限点之间的关系；
说明：
角色之间拥有继承关系如上图所示。
可以被继承的角色是由系统管理员制定的，部门管理员不能制定；
3 总结：
经过考虑，我认为 人员、机构、角色、权限 的关系应该做成可以改变的插件，系统初始时候进行选择不同组织方式；
也就是说，上文描述的 人员、机构、角色、权限 的关系还有原有关系都做成的插件，并不抛弃原有的人员权限关系。
