感谢读者在周末打开这篇文章，可能读完有一个感觉：奇奇怪怪的知识又增加了一些！但是了解不同学科的经典思想，想必也会形成一种乐趣。
古人云：物尽其力，人尽其才；现代管理学也讲：让合适的人做合适的事。假如我们经过一番努力，今天成为了公司的主管，此时有位实习生小鲜肉加入部门，刚加入公司小鲜肉从简单的工作开始做起，慢慢带上道，而此时的你，经过多年努力已化身老腊肉，身经百战经验丰富，应对复杂的业务也能淡然处理。一套软件系统同时面对了小鲜肉和老腊肉，如何能发挥其全部能力。你的工作更为复杂，实习生操作起来很可能犯错，为了避免这些不必要的错误，实习生可操作的功能和可看的数据跟部门主管需要做区分，比如审核的功能只能给到主管，财务数据给主管能看到，在同一套系统考虑到小鲜肉和老腊肉的管理范围和数据保密不同的需求，这就需要软件系统的权限设计。本篇文章讲述的权限设计，作为业务系统的基础，权限设计到底是什么又是如何设计的。如果读者从事的是市场或业务方面，那么这篇文章值得收藏阅读，因为几乎所有的业务系统都做了权限设计，对于系统功能的安排了如指掌，业务领域会没有人比你更懂软件功能的设计！如果读者是软件工程师，本文总结了多年的设计经验，希望能对你的设计能起到一点帮助！划重点：
权限设计过程就是：把权限赋予角色，把角色赋予用户。
软件的权限设计包含两部分：功能权限和数据权限，权限设计的前置条件是合理的角色设计，更进一步的是理解公司的组织结构设计。角色，一般是从现实岗位中来，每个角色职责管理范围不同，比如仓库管理员，物资采购员；组织一般是公司的组织架构，从上而下包含哪些部门，直线职能式，事业部制等，比如小王是产品设计部门，小李是市场部，用户的账户信息都在这个组织架构之中。功能权限指的是各个角色可以操作的页面元素，查看页面信息，功能按钮和链接等，如果用户的角色没有该项权限，那么用户就无法访问这个元素。以【审核】按钮为例，如果没有这个权限，用户不仅当前页面看不到【审核】按钮，也应该无法访问【审核】跳转到审核页面，所以即使用户通过前端破解拿到了审核页面的链接url，用户的账号应也无法访问这个页面。数据权限指的是用户能看到的数据范围，一般有2种设计方式：将角色与数据权限关联；或将组织架构与数据权限对应，用组织架构来决定用户的数据权限。这种通过组织决定用户的数据权限，是现在后台系统主流的设计方式。
功能权限设计最常用的是基于角色的访问控制RBAC（Role Based Access Control）模型，每个用户都被赋予了一个或多个系统角色，每个角色又被赋予了一个或多个权限，最终用户拥有对应的操作权限。如果平台用户数量很多，那么给每个用户分配角色是一件低效率的事情，于是模型引入了用户组的概念，将角色赋予这个用户组，用户组内的全部用户同时获得这个角色。我们设计的时候，可以把将组织看作一个用户组，给组织赋予角色，那么这个小组织内的用户就会获得这个角色，当有新员工入职时，只需要把新员工加入到对应的组织中，这个新员工就拥有了这个用户组的角色，获得了相应的权限。同时，也支持继续对用户分配其他的角色，一个用户可以有多个角色。
图2.1 模型E-R图
图2.2 用户管理图图2.3 角色管理图
图2.4 权限授权角色图
图2.5 权限节点图
看到格力空调的广告，我想格力公司的高管应该思考过一个问题：格力有几千家分销商，如何让这几千家分销商在同一套系统中只能操作自己的订单，不能看到别人家的订单及各项数据，但是管理人员能看到自己负责区域的分销商数据。这就需要要求产品技术人员做数据权限控制。数据权限的设计有2种方式：
2.使用用户与组织的关联关系，通过组织结构来决定用户的数据权限。
RBAC1模型，是在原来模型里角色的扩充，增加了角色等级的概念，父角色拥有子角色的所有权限。设计在角色管理模块中，加入数据权限的选择，将数据权限赋予角色。
我自己的经验来看，我估计这个方法仅能满足小规模的用户角色场景。现在后台系统的主流设计方法是第二种方法，通过组织关系来决定用户的数据权限，假设以格力公司的分销商组织架构为例，本架构纯属虚构仅作研究使用：
数据权限的可视化规则：上级组织只能看到自己和自己下级组织的数据，看不到与自己平级的组织及其下级组织的数据。根据这个规则和组织结构，所以我们就知道格力总部中心的账号可以看到所有的分销商数据，华南区分公司的账号可以看到自己公司的数据和分销商A，分销商B，分销商C的数据，华南区公司无法看到与自己平级的华中区和西南区的数据，分销商ABC也只能看到自己的数据，看不到别人的数据。通过组织结构来管理数据权限，是现在主流的设计方法。权限设计的道路条条道路通罗马，每个工程师在设计开发时都面临着不同的环境，也很难说有一套放之四海而皆准的设计方法，但是该模型仍然值得强烈推荐，设计原理和思想是可以包容许多变化。最后，希望本文能对您有益!
