許可權，但凡做應用軟體幾乎沒有不用到的，卻遲至今日才來仔細整理這方面的思路，慚愧得緊哪。
總體感覺，都是偏技術方面的東西，與應用的結合不算很緊密。
嘗試梳理一下這方面的思路，很亂，一時理不清楚。做了個思維圖，先放在這裡: https://p-blog.csdn.net/images/p_blog_csdn_net/oldcrane/entryimages/20080717/privilege-2008-07-16.gif。
總的來說，我是想從應用的角度、實施的角度來看許可權這個問題：
1、許可權這個概念的定義是什麼，它的範疇、邊界是什麼
許可權與業務邏輯的關係是什麼？兩者是否會重疊？
應用開發中經常會用到工作流，工作流和許可權之間，又會發生什麼樣的關係？
2、許可權資料管理
許可權的描述，可以抽象為 who, what, how，即 誰，對什麼物件，能進行什麼操作
對此，在資料描述上，有不同的方式。但不管如何處理，我們一定可以將涉及的資料分為兩大類。
第一類，可稱之為「定義資料」，主要包括：系統中有哪些物件，對每個物件有哪些操作。這類資料一般由開發人員或者部署人員來管理。在需求不發生變動的情況下，不會變化。
第二類，可稱之為「授權資料」，可以包括：許可權的擁用者或主體，其所擁有的許可權。這類資料資料，在系統執行過程中經常會發生變動，其變動不需要開發人員和部署人員的參與，一般由使用者方的系統管理員完成。
由於兩類資料變動的頻率、資料管理的負責人不同，資料管理的需求不同。
對於「定義資料」，重點保障許可權管理的靈活性、可配置性，保障使用者的許可權管理需求可以得到滿足，並考慮可預見的許可權管理變更需求，提供合理的資料介面。
對於「授權資料」，重點則是邏輯清晰，操作簡捷。需要從業務的角度來描述許可權，許可權判斷邏輯清晰易懂，常見的人員調整、許可權設定不會導致大量的資料操作（人工操作）。
這兩類資料，分別如何描述，分別會產生多大的資料量？
這兩類資料的邊界如和確定？
程式＝資料結構＋演算法
就許可權管理而言，哪些資訊應當放在資料中，哪些資訊可以固化在程式中，是否有一定的規律可循？
發散一下。
考慮一下ejb的概念，把開發和部署，明確地分成了兩個階段。部署階段的工作，不只限於配配伺服器端口、資料庫連線池而已。前端通過面向介面的方式呼叫後台服務，而後台服務的具體實現，是通過部署環境來完成配置的。也就是說，在部署的時候，才將各個模組組裝成為乙個完成的系統。spring等輕量級的框架，在這一點上與ejb是一致的。
這對於開發過程、開發模式是有影響的，我們需要去考慮，把哪些交給開發人員來決定，哪些又交給部署人員來決定。（當然，不考慮也是一種選擇）
3、領域模型和最佳實踐
對於許可權管理這一點，一方面是個系統都需要考慮，另一方面，每個系統許可權管理方面的需求又各不相同。
這樣的話，是否可以找到某些常見的領域，對各個領域提供不同的最佳實踐呢？
從設計的角度，則是在不同的層面上，提供不同的復用水平。
繼續做功課。
要向馬未都先生學習，要堅持。
ps:昨天簡單看了一下acegi security的文件，提供兩種方式擷取請求，進行許可權校驗。一是filter，一是method level的aop攔截。感覺合理，適於不同顆粒度的許可權控制需求選擇不同的攔截方式。不過，在具體專案中，把哪些邏輯作為許可權，這個問題依然存在，屬於最佳實踐的問題。繼續做功課，看文件。
也談軟體專案管理
今天得空看了看osgeo上的gdal開發資源。開源專案的管理也比商業專案完善的多，大的軟體專案真不是幾個牛人就能搞出來的，除非做的是一次性的專案。管理在大型專案開發中的作用怎麼強調都不為過，我們基本上都是做的不夠。冗長的 簡短的文件，大多數專案離開原班開發者後就成了雞肋，離開 加入新人都是超級費勁的...
艾偉也談專案管理，架構組織管理
架構組織管理的五大原則 構想 節奏 預見 協作和簡化 架構組織的三在概念 準則 模式和反模式 準則 為了把原則運用到實踐中，需要實施細節。準則把廣泛的原則翻譯成是否和如何執行原則的細節。模式 描述了開發或者使用軟體架構時可能遇到的常見問題的解決方案。反模式 反模式描述了組織在實踐中可能遇到的陷阱，描...
也談武媚娘
前段時間電視熱播 武媚娘 老婆天天晚上看。我不大喜歡看各種誇張和粉飾的歷史劇，但是對歷史還是喜歡一些，所以就利用閒餘的時間搜尋一下，看看唐朝的那些事。正好把自己的搜尋和感慨整理記錄下。唐朝是乙個中國發展的乙個鼎盛時期，即便如此，也是乙個多事的朝代。李世民宣武門弒兄，自己逼迫父親成為了太上皇，兒子李志...