近期浏览blog的时候，看到这篇文章通用权限的思路。带有数据库关系图. 现在虽然没有勇气来开这么一个大题目（通用权限系统）来研究，但发表一下感受还是没有问题的。
说的比较杂，欢迎拍砖。
- 确定目标 - 为什么而做
- 建立前提条件 - 由什么限制或基于什么样的理念等
- 规定系统范围 - 能做什么，不能做什么等
- 设计系统模型 - 概念定义（术语），概念描述，行为定义等
我想没有一个程序开发人员不把自己当成程序设计师在看（无论他现在是或者将来是），所以，我觉得良好的设计思路可以帮助我们慢慢走出属于自己路。上面四个步骤是前期设计工作的重要几步。我很理解一个程序员希望很快把自己的想法转换为具体的软件，但大多数时候，冲动是魔鬼。而且我也不反对，我们可以用XP思路的创建一个小模型，但我想说的是，如果我们站的高一点，思路开阔一些，是不是意味我们可以选择更好的路呢？
就像我们在程序中，设计接口（interface）一样，我们不急于完成实现，而是先定义抽象概念（程序依赖抽象而不要依赖实现 - 《Head First 设计模式》），再去完成实现。
这是我曾经给公司PDM/PLM 写了一个概念描述性文档,（12页，仍然觉得有需要修改的地方，限于保密条款不能给出全文）
核心描述 2
物件（Item Base） 2
虚拟物件（virtual Item） 3
关联关系（relationship） 4
分类（Category Base） 4
物件模板（Item Template） 5
属性块（partBase） 5
属性定义（propertybase） 5
属性中的引用 6
属性表现（property presentation） 6
选择框selectBox 6
方面（aspect） 7
改动（ChangeBase） 7
状态点StateNode 7
用户组（UserGroup） 8
用户审核结果（AuditResult） 8
审核用户选择器（auditorSelector） 8
改动与表单填写内容的联系 9
用户、角色、权限的问题 10
用户（User） 10
角色组（RoleGroup） 10
权限（Access） 10
用户登录时序图 11
登录和权限控制 12
登录模块（login Provider） 12
业务表现层（Biz presentation） 12
模块定义（Module） 12
应用程序授权检查（license） 13
整篇文章就是讲述概念，就是讲述具体的系统抽象出来为什么样子。我想，只有深刻理解了这些东西才能把正确的它转化为要实现的系统，而且即使在设计或实现过程中，它仍然是被修改，被丰富的一个过程。
我觉得我们在设计时候必须要由一个好的模型，而模型不是几张图就搞定了（图是为了更好的理解），也要概念描述。理清这些概念，搞清楚之间的关系，建立一个合适的模型，我觉得很重要。
在设计讨论会上面的时候大家可以说说： 什么是这个系统的关键词？这些相似关键词之间由什么差别？关键词之间由什么样的联系，我们怎么来描述这些联系？什么是这个系统的关键行为，我们把它们归纳到哪一些关键词里面去？等等
因此，我觉得对于角色系统来说，当前重要的不是数据表，而去理清系统所涵盖的概念和模型。
一点建议：可以再预备2到3种权限,以后扩展，这样更通用些。另外，排序也是一种权限，这个也可以考虑在内。
咋一听好像是加一个排序权限比较好。仔细一下，其实有点问题，首先，我们的系统开发出来是为了帮助客户来提高工作效率，那么，在此基础/前提，我们返回来看看“排序”是否能纳入到权限范围来？ 我个人认为不能。因为几乎没有一个系统会定义这个权限来限制用户。[仅做讨论无意打口水战]
既然谈到了权限系统，我也说说一个权限系统包括那些概念（See，Why don't I say Let's talk about systems?）
验证 - 在英语里面我们讲 Authentification， 容易跟Authorization（授权）搞混。不要一套系统一套验证系统，（我以前的公司有域验证，自定义验证，各种系统都拥有一套独立验证的模块，用户密码记一大推）请考虑一下，我们的设计前提，我们的系统是拿来提供用户工作效率，提升价值的。这么说，验证是否是独立开来？right！
再说说，用户信息（user profile），首先，部门信息和员工信息是不是在权限系统去掉后，没有什么影响？right！ 因此，拿掉它们。那么，我需要在系统使用这些信息怎么办？特别是授权的时候，总不能看一个用户Id授权吧？ OK！ 建立一个User Profile的实体类，而由Employee系统来实现IUserProfileProvider接口（罪过，罪过，怎么谈到实现了呢？）是的，我们的权限系统依赖的是接口，依赖的是抽像，而不是实现。
接着说说架构师吧，
架构师也分为几个等级，牛人的大家自然可以去google一下，拿来学习。我这里只谈谈自己的看法。
指导一个方向
首先，他很有经验，站在框架之上，能够正确评估设计中遇到的问题，给出解决问题的方向。
发挥团队的力量
其次，人无完人，架构师也有犯错的时候，因此，发挥群体的力量是必须，即便在架构的时候，也应该多让队员参与，既可提高队员的设计能力，其实同时也可以锻炼自己的组织能力和业务水平。（三人行，必有我师焉）
具有较强的建模能力
建模的第一步需要设计者能够抽象问题，从繁杂的用户需求中提升和过滤，得到问题的核心概念和基础模型。这些既依赖于设计者的软件水平和经验，也依赖他对行业认识。
总感觉随笔写的过于随便了，不过，我会重构的， I promise！