权限往往与特定的问题域紧密相关， 设计权限系统第一个要解决的问题就是什么样的操作是需要权限控制，什么样的是业务方法。他们之间本来是没有明确的区分，任何权限从某种角度上说可以是一种业务方法。为了以后管理和控制以及适应变化等我们从概念上需要将权限和业务明确划分出来！
判断“Who 对What(Which)进行How的操作”的逻辑表达式是否为真
Permission可以通过以下几个要素说明：
名称（name）
类型（type）
动作 (action)
掩码（mask）
以上是我们从使用的角度来观察我们的权限系统
好的权限业务模型能够很大的降低系统管理和开发的复杂性
如何将User和Permission建立起关联：授权和权限系统管理
原子权限模型复杂到一定程度，如何解决粒度太小和权限的组织问题，引入领域模型Role
这是一个抽象的概念，可以看作是原子权限的集合或者组织方式
在复杂的原子权限模型系统中设计正确的Role –Permissions关系模型能够很大简化系统。
这时候我们的系统演化为：
在较大的系统中，User概念模型也会变得比较复杂，如组织结构，我们网站会员类型等，为了简化系统，这时候我们通常引入Group领域对象
通常是一个实体，可以看作是User的集合或者组织方式
抽象的粒度不一样
这样在特定的问题域下面一个复杂的权限系统模型如下：
有些细粒度的权限控制，和特定的上下文和具体的instance相关，基于一定的规则，我们可以抽象成rule-based acl，需要对权限模型在进行一些补充
如：控制发布产品数量：需要指导当前用户已经发布了多少和能够发布多少
首先时候应该将此类纳入权限系统
ü 易于管理和分配
ü 简单灵活
ü 具备一定的重用性
这时候权限系统控制的就不是使用系统的用户，而是这个具体用户和相关控制项，称作Subject,这个细节没有定
权限表达式的右边中原子权限模型也需要调整，如：
这时候权限逻辑表达式为：
当When(Where)的时候，Who对What(Which)进行How的操作
从以上分析看，对特定问题域设计相关的权限控制系统系统模型的演化都很类似
但是为什么我们开发出来的权限系统无法实现通用性，不同在哪里？
AclSource不一样，有数据库，内存，XML文件等
AclPolicy在不同的问题域中策略也不一样。
原子权限模型和组织部一样，即Role和Permission的实体只能适用特定的问题域
用户和组织模型也不同，User,Group的实体只能适用特定的问题域
在特定的问题域设计权限系统都没问题，同样的系统却不能通用！
问题我想是不是我们系统建立概念模型的时候把问题域划分在系统范围之外了，在系统中没有映射到问题域这个概念的东西，所以引入Domain，将我们的系统范围扩大到问题域，也就是正对类似所有的问题域，这样我们抽象出关于问题域的对象模型Domain
这个概念模型代表我们的问题域模型
这时候我们的系统逻辑表达式为：
在XXX系统中， Who 对What(Which)进行How的操作
{User, Permission} = f (Domain)
这三个对象构成了整个权限系统的三个维度，在不同的Domain下，我们可以有不同的User-Permission模型
这样我们根据domain的不同可以选择不同的数据源（AclSource）和权限策略(AclPolicy)
系统活动图如下：
1285
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
