權限設計在B端的管理系統里比較常見。一般的場景是不同類型的人員需要在一個系統里協同完成某項業務操作，他們分別具有不同的權限，操作不同的資源。在C端產品里，也能夠看到權限的設計的存在，相對管理系統來講的話，要簡單一些。
兩個例子
先從簡單的說起吧，比如，微信群里，有兩個角色，群主和普通成員，分別有不同的權限。
普通成員：添加群成員，一般發言等
群主：刪除群成員，設置群公告，群主管理權轉讓。
群主不僅有普通成員所有的權限，還有一些特殊權限，這些權限是普通成員所沒有的。下圖是根據微信的權限例子畫的一個簡單權限結構模型。
對系統來說，不論是群主還是普通成員，他們都是用戶，但各自的權限不相同，但軟件設計不可能根據不同的類型的用戶單獨去配置功能。如果后期增添了某一功能，豈不是需要分別對不同類型的用戶配置相應功能。不管這個操作后期是不是讓電腦來操作完成，都達不到功能靈活配置的需要。
權限控制本質是用戶與資源的的配置，但是我們不可能為每個用戶都要去配置權限。引入了角色對象，是為了將用戶與權限隔離開，降低兩者之間的耦合度，也就是兩者之間的關系。通過角色來控制用戶的權限分配，做到弱化用戶與權限之間關聯。比如，某個角色因需求的變化引起權限的增加或減少，我們只需要控制需求變動對用戶角色的影響即可。
微信群的例子里面，群主與用戶面向的資源有重疊的部分，也有差異的部分。不管是重疊的部分也好，還是差異的部分也好，他們對權限都是通過功能的有無控制來實現。比如說，當群成員較少的時候，群內每個人都可以改群名稱，他們都有這個功能。但群成員的刪除，只有群主有，群成員無。這里未涉及到不同用戶角色擁有同一個功能，但操作的資源的廣度不一樣。所以說，這里權限設計通過功能的控制已經滿足系統設計的需要。
但在一些較為復雜的例子里面，僅僅從功能上考慮是不夠的，還要考慮到數據范圍的控制。
舉例說，公司內部管理系統軟件的權限設計，根據業務類型劃分，使用產品的用戶角色有：
- 管理員。主要負責系統不同角色人員的管理。
- 財務。主要負責財務的管理與審核。
- 銷售。主要負責銷售業務。
- 人事。主要負責人事安排。
按照上面業務類型的劃分，他們抽象的功能劃分結構是這樣的：
接著考慮下面的例子，在一個部門里，有不同級別的職位，不同的職級的人功能權限相同，但操作的數據范圍是不一樣的。比如說，銷售部門的某一個副總監，能查閱到公司在整個華南地區的業務數據，他下屬帶的一個的業務員，負責廣州地區業務，那么他就只能看到廣州的業務數據，他上級的總監，不僅能查閱到華南地區的業務數據，還能查到其它地區的業務數據。總監，副總監，業務員都有查閱數據功能，但職位不同，所能夠查看的數據范圍也就一樣。
不在一個部門里，同樣會需要這樣的考量。財務部門的財務總監，因為財務審計，可能需要查看所有地區的業務數據，他就需要有查看銷售部門負責的所有地區的業務數據。產生這種需求是由公司的職能結構決定的。
功能權限和數據權限
上面的兩個例子可以看到，對于業務不復雜的產品，僅從功能去設計是足夠的。當系統變得復雜的時候，就需要在功能限制的基礎上，加上數據范圍的限制。可以認為，數據權限是對功能權限的補充。兩者并不是獨立的分類。
在權限的設計上，我是從兩個方向來分解的，橫向和縱向，橫向對應的即是功能權限的設計，縱向對應的是數據權限的設計。其劃分的原則：
橫向（功能權限）。在B端產品上，按組織的內部業務主體結構類型來劃分。這種參照的現實依據是公司在實際業務運轉中對在內部已經作了分割。比如，公司A內部，有部門a，b，c，d。一般情況下，a，b，c，d各自的內部數據是無法相互查閱的，業務操作都是相互獨立，彼此因為沒有對方的功能權限而無法進行相應的業務操作。C端產品上的會員制，等級制也都是功能權限的體現。
縱向（數據權限）。縱向的劃分的建立在功能基礎上的，通常是反映的是不角色的等級關系的。在B端產品上，數據權限的劃分往往基于組織架構的，這是為了滿足管理的需要。比如說，銷售部門里，銷售總監和普通銷售業務在一些重疊的功能上，看到數據范圍不一樣，前者顯然要比后者大。
權限設計的難度在角色和資源的分配上，因為不同角色不僅在資源有業務交叉，不同角色之間在業務的又有交叉，最終反映的是功能權限和數據權限的設計。如果處理好功能權限和數據權限對資源的分割，那么不同用戶角色的劃分及用戶角色之間的關聯就有較為清晰的劃分，也會為后期的產品迭代提供足夠的空間。附權限設計的思路：
上圖是個人對權限設計的總結，把系統看作一個完整的資源，不同角色處于不同位置，占據的資源不同。其中把握的核心點就是，從兩個方向解構：
- 先橫向做功能分解，再縱向做數據分解。數據分解是對功能分解的補充，不是真正意義上的另一個維度的分解。
- 橫向以業務類型或業務模塊劃分來從功能上分解。
- 縱向上以職級或組織架構來進行數據劃分，是對功能權限進行補充。
用戶與角色
用戶與用戶角色是多對多的關系。一個用戶可以有多個角色，一個角色可以對應多個用戶。每個角色對應不同的權限，管理員可以對用戶進行角色編輯和權限的分管理與分配。
一般情況下，系統對角色的擴展和權限的擴展都是有一定需求的：
- 增加角色。系統可根據自己需要來自定義角色。
- 修改權限。系統可以隨時更改角色相應的權限。
- 權限的擴展。系統新增業務時，保證權限能夠同步到相應的角色里。
最理想權限設計的是能夠從業務上與職級上對權限進行打包，然后將權限賦給某一用戶，只要是后期公司在業務結構上不做大的調整，都能滿足自身角色變化之后權限所需的相應更改，并不需要考慮使用用戶角色來滿足權限的擴展。
實踐中的思考:
功能權限和數據權限的區分是什么，各自的邊界在哪里？
權限是對資源的控制和約束，如果只從這一點來出發，就難以去劃分功能權限和數據權限的區別。起初，我的理解是數據權限是在數據上做的限制，功能權限是在功能操作上的限制，兩者是獨立的，這么理解似乎是對的。可是在后面梳理的時候發現了問題，銷售部與生產部兩個不同的業務部門，那么在權限控制上是歸類到數據權限呢還是功能權限呢？還是說兩者同樣適用。如果說兩者都能通用，那么兩者的概念定義有問題，是不是應該去掉一項呢？如果我們在產品設計上，標尺是不清晰的，多面的，那么最終產品結構肯定混亂的，無法適應后期的擴展。這也是促使我去思考并決心找到兩者的切入問題的出發點，以期達到「庖丁解牛」。所以我先從QQ群的例子來著手分析，在業務并不復雜的情況下，只考慮功能權限已足夠達到權限管理的需要。在管理系統的例子里面，才有了數據權限的引入。也因此有了前面對權限的理解，先橫向進行功能權限分解，在功能權限分解不能滿足產品設計的需要，再考慮數據權限的補充。
