**：
或者說使用者管理子系統如何設計，包括如何抽象以及相關的儲存。
大部分的應用中都會有使用者的概念，除非你的**全部是匿名訪問，不儲存使用者任何資訊。其實這也是不好的，因為你的**如果沒有使用者的概念，沒有設計使用者模組，就很難收集使用者資訊及使用者行為，也就很難有資料來分析使用者的喜好，也就少了一條給使用者提供更好服務的途徑。
現在是web2.0的時代，甚至是web3.0，使用者越來越在意**給自己帶來的內容，顯示的內容是否合適自己，而且使用者很想參與**的內容構建，想要對自己構建的內容進行聚合、管理。
說了這麼多，就是要說明使用者管理模組很重要，是個應用就應該考慮，而且還是重中之重。
先來看一下使用者資訊都包含哪些內容。
使用者還可能包括企業使用者，就會有：企業名稱，企業註冊號，企業工商號，企業營業執照號，法人，聯絡人，聯絡人職務等等企業資訊。
使用者會有很多的型別。
有的是個人，有的是企業。
有的有銀行賬戶資訊，有的沒有銀行賬戶資訊，現在沒有的，以後可能會有。
在使用者認證方面現在可能是username/password，以後可能需要支援第三方認證（例如：微博，twitter，qq），還可能需要sso。
單使用者模型，單錶儲存模型
最開始想到的是就是乙個使用者模型，然後把所有的屬性都建立在這個模型上，然後加上個使用者型別屬性區分一下。不同的使用者型別，使用不同的屬性。
在儲存方面就建立一張表，每個屬性來乙個字段。雖然有很多的字段在一些情況下會有浪費，甚至在使用者量巨大的情況下，是非常浪費的。但是好處就是從模型到儲存，都是唯一的，**唯一，省去一些獲取啊，型別轉換之類的麻煩。
但是也帶來另外的一些麻煩，就是在**中需要做很多的判斷。什麼型別，使用那些字段。
多使用者模型，多表儲存模型
上面的儲存太浪費了，而且不清晰，所有使用者都在一張表中，看起來有點不爽。
好吧，分開吧，根據使用者型別分開，每個使用者型別乙個模型，單獨儲存一張表。
個人使用者：登陸賬號，登入密碼，電子郵箱。
企業使用者：登陸賬號，登入密碼，企業名稱，組織機構**，企業法人。
這下好像清晰了一點，需要什麼型別的使用者就用那個使用者的模型，就去那張表找。
但是有幾個問題：
1.登陸都是用username/password，在兩張表，難道寫兩遍，但是都一樣啊。好吧，也有解決辦法，那就是寫乙個資料庫檢視，在檢視中連線兩張表，查詢檢視就可以了。這樣也解決了一些需要同時查詢所有使用者的場景，不錯。但是隨著使用者型別的增加，需要維護資料庫檢視，否則查詢結果就會產生誤差。但是查詢單個型別使用者的時候，是直接用表呢？還是用檢視呢？有點糾結了！
2.需要增加銀行賬戶資訊，有幾類使用者需要新增，有的不需要新增。好吧，開啟需要新增的表和模型，新增一下，但是有重複的工作量，是不是可以更好一點呢？
！！！其實我有一點感悟，就是你的**寫的和業務越是貼近，它的復用性就會越低，就是和某種業務繫結了，甚至是和某乙個業務點耦合了。
當然，有的時候會有這種需要，這段**就是為這個業務點來服務的。
但是有很多時候不是這樣的。
舉個例子吧。
乙個實體有很多的狀態，有幾個狀態來來決定是否能進行某個操作，你可能會寫這樣的乙個方法。
private boo canupdate(status status)
if(status==status.wait||status==status.finish)
return false;
當上面的wait和finish狀態還同時決定其他操作的時候，你可能又會寫乙個方法cando。這兩個方法就有一些重複，可能在定義乙個中間狀態，復用一下會更好也說不定。
這個例子也可能不太合適，也可能是命名的問題。這個地方還需要大家拍磚，最好是使勁兒的拍，拍醒我，拍明白我。
資訊模型，按資訊型別儲存
看到標題，很多人肯定是糊塗了，說著使用者怎麼就不提使用者的事兒了呢？
其實就是抽象一下，使用者就是一種資訊。
在經歷過幾次使用者資訊的擴充之後，思考一下，把所有的資訊都羅列出來，看看他們到底如何建立模型，如何設計儲存，才能更好的適應應用的發展。
從另外乙個角度，跳出應用，跳出業務劃分，單純的從資訊的屬性看看，是否有解決辦法。
我覺得可以這麼劃分
應用中的業務使用者型別，都可以從這幾種資訊中組合而來，而且隨時可以增加一類資訊。使用者資訊的底層基礎模型分為幾個，分開獨立儲存。
業務中中某一類使用者，需要哪些資訊，就從使用者資訊的底層模型中挑選那幾個，組合成乙個業務的使用者模型，進行業務的操作。
甚至底層基礎模型還可以做到對業務模型遮蔽儲存結構，儲存方式，儲存型別。
這麼做有幾個好處：
1.你可以把所有使用者的驗證資訊儲存在一起，這樣在username/password驗證，以及增加第三方驗證的時候，都會很方便。
2.大量消除空白字段，節約儲存空間。
3.大量消除重複字段，防止遺漏。
4.經過幾次重構之後，就可以最大化的實現使用者業務模型的組合、分離。上層業務模型清晰，底層基礎模型清晰，後台儲存模型也很清晰。
salesforce 架構設計 從架構設計到架構師
因為碎片化的時間多了，所以開始刷起某乎了，關注了架構相關的板塊，也順手回答了一些問題。發現有很多同道中人正在經歷著我前兩年經歷的階段，對於做架構沒有相對具象的一些理解，更沒有系統化的認識。所以把最近回答的一些內容整理一下，權當記錄，留給3年後的自己 按慣例，容許我裝x開頭 一 架構的定義 在軟體開發...
mysql架構設計 初識mysql架構設計
一 應用系統如何與mysql進行一次互動？最開始接觸jdbc的時候，我們系統如何完成一次sql操作呢？第一步，建立資料庫連線 第二步，操作sql 第三步，釋放連線。但是每次建立與資料庫的連線非常耗時和資源，所以我們加入了連線池的概念。第一步的獲取連線是從連線池中獲取乙個可用的連線，第三步的釋放連線不...
軟體架構設計和開發管理
整合平台的發展趨勢 從功能上可以將其劃分為 企業應用整合 和 業務到業務的整合 b2b 兩種。其中，eai 主要側重於企業內部的縱向整合，b2b 側重於支援企業間業務往來的橫向整合。面向服務的體系結構 service oriented architecture，soa 從應用的角度定義 是一種應用框...