ierryw 说得不错，我现在要做的系统也有这样的困惑---角色的泛滥。

我现在有个想法就是，一个人有多个角色，登陆时，权限取角色们的权限集合。当然有个前提，即每个角色登陆后的界面一致。

我还有个问题：机构（部门）的作用。

我觉得，部门是权限的另一种集合，这个集合大于等于任何在这个部门的角色的权限集合。也就是说，一个部门有某些权限，而在这个部门的角色的权限，仅限于这个部门的所有权限。
或者，部门是角色的集合？

我仔细又看了一下，有几个问题

1 部门和角色之间是什么关系，如果是强耦合那么和人员和角色之间的关系区别在哪里？？？

2 人员和角色，部门和角色之间的关系是不是重复（问题如1）

3 部门有继承，那么对应的角色是不是继承关系？？如果继承那么有些时候不一定角色之间是继承关系

我觉得我们可以参考数据库的权限设计，把权限分为低耦合的元权限，然后再要么直接赋给用户，要买赋给角色，然后把角色赋给用户。

个人觉得其实很多困惑都源于概念和层次的不清晰。

a 机构(部门)、岗位、员工及相应的组织机构关系是属于业务层面的。
b 用户(操作员)、角色、权限是属于系统层面(也可以称应用层面)。

举个例子来讲：宝钢集团
宝钢集团有很多应用系统，共用一套组织机构，也就是前面提到的a。
每套应用系统拥有各自的权限控制，也就是b。
在设计上a和b应该是松耦合关系。

至于职务只是员工的一个属性，不应该在组织机构树里讨论。
而我们通常讲的组织机构树仅仅是“隶属关系”。事实上机构、岗位、员工这三者之间及各自之间都存在着其他形式的关联关系。如果要灵活的定义这样的关系，可以参见Party模型(可以在网上搜到)。

至于角色权限，代文龙的文章及RBAC都说的比较透彻，关键在于你自己的理解。

我也在思考中，确实比较麻烦，好在我这里有个work flow可以帮我省去不少审批流转的过程。人员，职责，岗位，组织，集团等问题，hr模块定义好，可以根据不同的组织来定义，手段--弹性域，另外在做工作流时，
又引进一些对象，在流程的不同阶段，改变这些对象的属性就可以了。
这样比较清晰些，我接触的大型erp大部分都这么搞的。

爽，看到这么好的帖子，不枉此生，先做个标记，慢慢看

dunel 你好

能不能按你的想法发把数据库设计也帖出来
有什么表 ,表里有什么字段,表之间的关系

有没有一个具体实现的例子？

真的是好贴。看了上面的讨论，从中学到了很多好的思路！

深有感触，受益非浅

2个属于层次2个属于信息， 我想可以在一个行为中对这个功能任务进行判断~~~所以一切届资源

2个信息类提供判断功能，服务类中提取出层次类后然后调用信息类判断功能，然后转到不同的部门执行

角色太多 我想可以采取高优先级判断，避免多次判断的，还有就是可以采用没有就绝对不允许策略
具体设计肯定比较复杂，不过这中模式应该很多可考