产品的权限设计
权限设计在B端的管理系统里比较常见。一般的场景是不同类型的人员需要在一个系统里协同完成某项业务操作，他们分别具有不同的权限，操作不同的资源。在C端产品里，也能够看到权限的设计的存在，相对管理系统来讲的话，要简单一些。
两个例子
先从简单的说起吧，比如，微信群里，有两个角色，群主和普通成员，分别有不同的权限。
普通成员：添加群成员，一般发言等
群主：删除群成员，设置群公告，群主管理权转让。
群主不仅有普通成员所有的权限，还有一些特殊权限，这些权限是普通成员所没有的。下图是根据微信的权限例子画的一个简单权限结构模型。
对系统来说，不论是群主还是普通成员，他们都是用户，但各自的权限不相同，但软件设计不可能根据不同的类型的用户单独去配置功能。如果后期增添了某一功能，岂不是需要分别对不同类型的用户配置相应功能。不管这个操作后期是不是让电脑来操作完成，都达不到功能灵活配置的需要。
权限控制本质是用户与资源的的配置，但是我们不可能为每个用户都要去配置权限。引入了角色对象，是为了将用户与权限隔离开，降低两者之间的耦合度，也就是两者之间的关系。通过角色来控制用户的权限分配，做到弱化用户与权限之间关联。比如，某个角色因需求的变化引起权限的增加或减少，我们只需要控制需求变动对用户角色的影响即可。
微信群的例子里面，群主与用户面向的资源有重叠的部分，也有差异的部分。不管是重叠的部分也好，还是差异的部分也好，他们对权限都是通过功能的有无控制来实现。比如说，当群成员较少的时候，群内每个人都可以改群名称，他们都有这个功能。但群成员的删除，只有群主有，群成员无。这里未涉及到不同用户角色拥有同一个功能，但操作的资源的广度不一样。所以说，这里权限设计通过功能的控制已经满足系统设计的需要。
但在一些较为复杂的例子里面，仅仅从功能上考虑是不够的，还要考虑到数据范围的控制。
举例说，公司内部管理系统软件的权限设计，根据业务类型划分，使用产品的用户角色有：
- 管理员。主要负责系统不同角色人员的管理。
- 财务。主要负责财务的管理与审核。
- 销售。主要负责销售业务。
- 人事。主要负责人事安排。
按照上面业务类型的划分，他们抽象的功能划分结构是这样的：
接着考虑下面的例子，在一个部门里，有不同级别的职位，不同的职级的人功能权限相同，但操作的数据范围是不一样的。比如说，销售部门的某一个副总监，能查阅到公司在整个华南地区的业务数据，他下属带的一个的业务员，负责广州地区业务，那么他就只能看到广州的业务数据，他上级的总监，不仅能查阅到华南地区的业务数据，还能查到其它地区的业务数据。总监，副总监，业务员都有查阅数据功能，但职位不同，所能够查看的数据范围也就一样。
不在一个部门里，同样会需要这样的考量。财务部门的财务总监，因为财务审计，可能需要查看所有地区的业务数据，他就需要有查看销售部门负责的所有地区的业务数据。产生这种需求是由公司的职能结构决定的。
功能权限和数据权限
上面的两个例子可以看到，对于业务不复杂的产品，仅从功能去设计是足够的。当系统变得复杂的时候，就需要在功能限制的基础上，加上数据范围的限制。可以认为，数据权限是对功能权限的补充。两者并不是独立的分类。
在权限的设计上，我是从两个方向来分解的，横向和纵向，横向对应的即是功能权限的设计，纵向对应的是数据权限的设计。其划分的原则：
横向（功能权限）。在B端产品上，按组织的内部业务主体结构类型来划分。这种参照的现实依据是公司在实际业务运转中对在内部已经作了分割。比如，公司A内部，有部门a，b，c，d。一般情况下，a，b，c，d各自的内部数据是无法相互查阅的，业务操作都是相互独立，彼此因为没有对方的功能权限而无法进行相应的业务操作。C端产品上的会员制，等级制也都是功能权限的体现。
纵向（数据权限）。纵向的划分的建立在功能基础上的，通常是反映的是不角色的等级关系的。在B端产品上，数据权限的划分往往基于组织架构的，这是为了满足管理的需要。比如说，销售部门里，销售总监和普通销售业务在一些重叠的功能上，看到数据范围不一样，前者显然要比后者大。
权限设计的难度在角色和资源的分配上，因为不同角色不仅在资源有业务交叉，不同角色之间在业务的又有交叉，最终反映的是功能权限和数据权限的设计。如果处理好功能权限和数据权限对资源的分割，那么不同用户角色的划分及用户角色之间的关联就有较为清晰的划分，也会为后期的产品迭代提供足够的空间。附权限设计的思路：
上图是个人对权限设计的总结，把系统看作一个完整的资源，不同角色处于不同位置，占据的资源不同。其中把握的核心点就是，从两个方向解构：
- 先横向做功能分解，再纵向做数据分解。数据分解是对功能分解的补充，不是真正意义上的另一个维度的分解。
- 横向以业务类型或业务模块划分来从功能上分解。
- 纵向上以职级或组织架构来进行数据划分，是对功能权限进行补充。
用户与角色
用户与用户角色是多对多的关系。一个用户可以有多个角色，一个角色可以对应多个用户。每个角色对应不同的权限，管理员可以对用户进行角色编辑和权限的分管理与分配。
一般情况下，系统对角色的扩展和权限的扩展都是有一定需求的：
- 增加角色。系统可根据自己需要来自定义角色。
- 修改权限。系统可以随时更改角色相应的权限。
- 权限的扩展。系统新增业务时，保证权限能够同步到相应的角色里。
最理想权限设计的是能够从业务上与职级上对权限进行打包，然后将权限赋给某一用户，只要是后期公司在业务结构上不做大的调整，都能满足自身角色变化之后权限所需的相应更改，并不需要考虑使用用户角色来满足权限的扩展。
实践中的思考:
功能权限和数据权限的区分是什么，各自的边界在哪里？
权限是对资源的控制和约束，如果只从这一点来出发，就难以去划分功能权限和数据权限的区别。起初，我的理解是数据权限是在数据上做的限制，功能权限是在功能操作上的限制，两者是独立的，这么理解似乎是对的。可是在后面梳理的时候发现了问题，销售部与生产部两个不同的业务部门，那么在权限控制上是归类到数据权限呢还是功能权限呢？还是说两者同样适用。如果说两者都能通用，那么两者的概念定义有问题，是不是应该去掉一项呢？如果我们在产品设计上，标尺是不清晰的，多面的，那么最终产品结构肯定混乱的，无法适应后期的扩展。这也是促使我去思考并决心找到两者的切入问题的出发点，以期达到「庖丁解牛」。所以我先从QQ群的例子来着手分析，在业务并不复杂的情况下，只考虑功能权限已足够达到权限管理的需要。在管理系统的例子里面，才有了数据权限的引入。也因此有了前面对权限的理解，先横向进行功能权限分解，在功能权限分解不能满足产品设计的需要，再考虑数据权限的补充。
