银杏叶落尽，只留下淡黄的记忆，浸润着北国的风光。
这个世上，说喜欢你的人很多，能陪你到最后的至多只有一个。
这个世上，嚷嚷着要旅行追求诗和远方的人很多，能做到的少之又少。
同样，说起阅读，很多人都把它写在了爱好一栏。倘若你要让其拿出几个得意的作品，能拿出来的很少。
把写作当成生活一部分，坚持下来的更是寥寥无几。
任岁月荏苒，任世事沧桑。
我亦微笑，我亦无悔。岁月静好，念你如初。
一、"缘起"
上周的专栏——后台系统产品设计之《用户权限系统》，发布后，有很多小伙伴分享转发文章，在此一并谢谢，也有小伙伴加我微信好友，交流一些用户角色权限这块的内容。比如收到鹅厂的小伙伴来信：
涉及to b用户权限角色管理这块跟to c最大的差异化是什么呢？
正如图片中内容一样，当时在现场，没能来得及回复，后来也只是简单回复了下，今天在这里详细说说吧。
权限设计在B端的各类后台管理系统里比较常见。一般的场景是不同类型的人员需要在一个系统里协同完成某项业务操作，他们分别具有不同的权限，操作不同的资源。
在C端产品里，也能够看到权限的设计的存在，相对B端的各类后台管理系统来讲的话，要简单一些。
比如，微信群里，有两个角色，群主和普通成员，分别有不同的权限。
普通成员：添加群成员，一般发言等
群主：群聊邀请确认，删除群成员，设置群公告，群主管理权转让。
群主不仅有普通成员所有的权限，还有一些特殊权限，这些权限是普通成员所没有的。下图是根据微信的权限例子画的一个简单权限结构模型。
二、理论
对系统来说，不论是群主还是普通成员，他们都是用户，但各自的权限不相同，但软件设计不可能根据不同的类型的用户单独去配置功能。如果后期增加了某一功能，岂不是需要分别对不同类型的用户配置相应功能。不管这个操作后期是不是让电脑来操作完成，都达不到功能灵活配置的需要。
权限控制本质是用户与资源的的配置，但是我们不可能为每个用户都要去配置权限。引入了角色对象，是为了将用户与权限隔离开，降低两者之间的耦合度，也就是两者之间的关系。通过角色来控制用户的权限分配，做到弱化用户与权限之间关联。比如，某个角色因需求的变化引起权限的增加或减少，我们只需要控制需求变动对用户角色的影响即可。
微信群的例子里面，群主与用户面向的资源有重叠的部分，也有差异的部分。不管是重叠的部分也好，还是差异的部分也罢，他们对权限都是通过功能的有无控制来实现。
比如说，当群成员较少的时候，群内每个人都可以改群名称，他们都有这个功能。
但群成员的删除，只有群主有，群成员无。这里未涉及到不同用户角色拥有同一个功能，但操作的资源的广度不一样。所以说，这里权限设计通过功能的控制已经满足系统设计的需要。
三、后台权限设计
但在一些较为复杂的B端后台管理系统例子里面，仅仅从功能上考虑是不够的，还要考虑到数据范围的控制。
举例说，某公司内部管理系统软件的权限设计，根据业务类型划分，使用产品的用户角色有：
管理员。主要负责系统不同角色人员的管理。
财务。主要负责财务的成本管理与结算。比如下图中的受理工号1。
营运。主要负责操作中心配送业务。比如下图中的受理工号2。
质控。主要负责质控考核，配送履约数据分析。比如下图中的受理工号3。
按照上面业务类型的划分，他们抽象的功能划分结构是这样的：
接着深入思考一下，在一个部门里，有不同级别的职位，不同的职级的人功能权限相同，但操作的数据范围是不一样的。比如说，操作中心山东片区的的某一个总监，能查阅到公司在整个山东地区的配送数据，他下属带的一个的城市经理经理，负责鲁东地区业务，那么他就只能看到鲁东的业务数据，他上级的总监，不仅能查阅到鲁东地区的业务数据，还能查到其它地区的业务数据。总监，副总监，城市经理都有查阅数据功能，但职位不同，所能够查看的数据范围也就不一样。
不在一个部门里，同样会需要这样的考量。财务中心的财务总监，因为财务结算，可能需要查看所有地区的业务数据，他就需要有查看操作中心负责的所有地区的业务数据。产生这种需求是由公司的职能结构决定的。
上图是个人对权限设计的总结，把系统看作一个完整的资源，不同角色处于不同位置，占据的资源不同。其中把握的核心点就是，从两个方向解构：
先横向做功能分解，再纵向做数据分解。数据分解是对功能分解的补充，不是真正意义上的另一个维度的分解。
横向以业务类型或业务模块划分来从功能上分解。
纵向上以职级或组织架构来进行数据划分，是对功能权限进行补充。
网友评论