為什麼寫這篇文章？
寫這篇文章的目的有兩個：一個原因是，由於最近將近兩年都在接觸大型的系統，我有幸作為一個軟件實施方的一員，接觸並瞭解了幾個大型的項目，並自己也主導設計了一款軟件系統，我對於軟件的後臺設計有了一定程度的瞭解，有能力闡述清楚這個問題。另外一個原因是，曾經我作為一個軟件小白，想要在網上找到相應的資料，發現，大部分的文章都來自與開發人員，他們偏向於從技術層面進行闡述，讀起來晦澀難懂，很少從業務和原理上進行闡述，還有一部分文章闡述的層面較為淺顯，淺嘗輒止，並沒有從整體到部分進行完整的闡述，我這篇文章力求簡單明瞭，完整全面，任何人都通俗易懂。
系統後臺一般包括哪些內容，有什麼用處？
系統後臺一般是管理者進行系統管理的一個模塊。根據軟件的不同用途，其管理的內容各不相同。舉個簡單的例子：今日頭條、騰訊視頻、頭條號等內容平臺，一般其後臺都會有內容審核功能，用戶賬號管理、權限分配等等。用戶發佈一篇文章，後臺進行審核，通過後，方可進行展示。
我今天所闡述的系統後臺，指的是更為核心的東西，是一個系統的心臟。指的是權限數據管理，這一個部分的設計最為複雜也是系統設計最難最基礎的部門。
權限包括兩個部分：一個是操作權限，一個是數據權限。
操作權限又包括兩個部分：一個是菜單權限，另外一個是按鈕權限。
菜單權限。舉個例子來說：我們使用同一個辦公軟件系統，你是HR，你有招聘模塊的菜單，可以進行招聘相關的操作，我是財務，我有費用報銷模塊的菜單，而你沒有。這樣我們的菜單是不一定的。我們都可以使用辦公軟件，但是我們的職位不同，所以分配的菜單是不一樣的。
按鈕權限。舉個例子：我們兩個都是人資部門的人，你是招聘專員，我是人資經理。我們雖然都有招聘菜單，但是你沒有招聘需求審批的按鈕，你沒有相應的權限操作，只有我可以進行招聘需求的審批。
數據權限，說起來就比較簡單容易理解了，比如拿快消行業來說，我是上海區的省區經理，你是江蘇大區的省區經理，我們職位相同，我們都是省區經理，我們擁有的操作權限也是一樣的，但是我們看到的數據是不一樣的，我是上海地區的經理，只能允許看到上海的銷售數據，江蘇地區的銷售數據我是看不到的，同理，江蘇區的省區經理也是一樣的。所有這些，都是可以通過數據權限進行控制的。
怎麼進行權限的控制？
我主要介紹一種常見的權限控制方法，也是比較常用的權限設計方式，這種是對小型或大型企業都非常適用。我們是以企業的角度設計這款系統的，所以在設計之初就有許多“不確定的因素”，我在這裡就一一介紹一下。
自上而下設計模式
這種模式貫徹了系統權限管理，我們將企業分為公司—部門—崗位—角色—用戶，分層管理逐級降低，使權限管理條理清晰。
當公司—部門—崗位—角色—用戶都設定好了我們就可以設置權限了，我們主要是在角色—用戶設置了功能權限—數據權限。
角色—功能權限—數據權限
他的設計原理是：把操作權限分配給角色，這樣新增一個新的角色以後，就會給這個新增的角色分配相應的操作權限，包括操作按鈕和操作菜單。數據權限也細分開來，不同角色崗位有獨立數據庫也可以共享數據。
用戶—功能權限—數據權限
用戶和角色的權限的差不多，只是增加更多的功能對用戶的控制。
有人覺得公司—部門—崗位有什麼用呢？我在這裡解釋一下，公司和部門是必需的，我們為企業長久發展設計了總公司及子公司，方便企業的管理。部門可以看做一個個類群，對用戶用戶進行分類管理。這崗位就涉及到了工作流引擎和流程引擎。
這種權限設計方案適用於OA、ERP、MIS、CRM、電商平臺等系統，他可以根據企業的規模進行調整，幫助企業在任何時候都有一個舒適的管理環境。
這樣設計有什麼好處呢？
舉個例子說吧：當一個員工離職了，只需要停用該員工的用戶賬號，把職位移除，如果新來一個員工替代他，只需要給新員工新建一個用戶賬號，同時把用戶導入角色就OK了，不需要重新分配數據權限和操作權限。
再舉個例子吧：當兩個員工A和B進行跨部門職位調崗時，該怎麼操作呢？先把A和B的部門調換，然後把他們所在的崗位中移除了，再分配的其他崗位上，在用戶界面重新分配數據庫。
如果有考慮有工作流的情況，就需要考慮流程節點處理對象，可以按照工作流崗位、角色和具體用戶三個維度進行配置，流程可以設定成整個企業也可以具體到某個角色。
此外，對於，有相應人員編制的企業來說，可以保證職位的固定，只會有用戶的增減，職位可以始終保持不變，這樣編制就得以控制了。
閱讀更多 力軟信息 的文章
