如果您認為這篇文章主要講「我」的人生經歷，那就錯了，我很少寫感慨之類的文章。沒有譁眾取寵的意思，只是想說我是如何走上架構這條路的，以及架構的心得，並講述我目前正在架構的內容。也為以後的文章做乙個鋪墊。
主要講下面的幾件事情：n專案
à產品à平台的經過
n架構心得
n現在的架構內容
n架構的完美性
像很多人一樣做過很多的專案，不知別人怎麼樣想，我的感覺是做專案真的很累。為了趕時間，**倒是寫了不少，但總感覺形同散沙，不是乙個精巧的有機整體，偶爾會有一些靈機一動，但望著不可預期的改造成本而漸漸變得麻木。沉澱下來的是程式設計的經驗和對客戶的需求的把握上。然而不管怎麼樣或多或少的有了些可以重用的東西，也有一些小範圍內的抽象能力。
從專案到產品的過渡不是我刻意布的局，公司專案的產品化過程才是直接的原因。專案成熟後，當有新的需要與以前的專案差不多時，很自然地把專案改造放到了首選位置。然而重點不是在改造本身，而是專案的定製上。把一些變化的地方從整體中分離出來做活，為以後處理類似的專案打下基礎。久而久之產品也就形成了。此時變化點的分析及分離能力得到可觀的提高。
好的公司在不斷的成長，從單一產品發展到覆蓋某一領域的全套產品。這時，不同產品之間的互動及操作的一致性成為最重要的需求。公司為了進一步縮減開發成本，提高開發效率，應用整合便提到了日程上來。必須從乙個新的高度重新開始架構應用，以找出不同應用之間的共同點和變化點，這需要更高層次的抽象。**級別的重用已經不能解決這個層次的問題了。
現在大家都在討論
soa，這的確是乙個好東西，也許
soa的概念比較大，而我只是在不同的應用之間共享一些資料和服務。如統一的使用者系統，授權系統等。我不知道這是不是
soa，但精神是達到了，「面向服務」。這時重用的已經不是**了，而是服務。還好現在這個時代已經為我們做好了這方面的技術標準即
web services
技術，（題外話：其實我個人更喜歡
wcf成為行業的標準，不是跟微軟的屁股，確實他做的很好，把服務和通訊方式分離開來是乙個質的飛躍。）我們可以很方便地構建我們的服務。這些基礎的服務匯聚起來，應用平台的概念便產生了。
上面寫的是我個人的真實經歷，肚子裡沒東西，寫的不多，但整個過程是
12年，每個階段對我個人的成長有著不同的意義。想一想中間有很多浪費，當然不是說頹廢，只是走了很多的彎路。期間的意義在於，如果您一開始也打算走架構這一條道，希望我的文章能給您一些啟示。
如何能夠成為乙個好的架構人員，我不敢妄言，只說一下我自己的一些見解。想到哪說那，感覺層次不是很整齊，還望見諒。
l經驗，**於兩方面的經驗：
ø程式設計經驗：**一直寫下去，去理解物件導向技術及設計模式如何大刀闊斧的改造我們的**，只要努力，時間會給我們最好的印證。
ø專案經驗：了解哪些是重要的那些是次要的，用好
80-20
法則，做好多次迭代的準備。把握好抽象的粒度和深度。
l設計模式：
一定要看，不一定要記住。為了應用設計模式而去設計是錯誤的。從現有的具體情況出發，依據想要達到的目的去套用才是應用設計模式的好方法。
lweb services
服務（簡稱
ws），
ws本身並不難，難在給
ws**！我個人不建議直接將
ws公開出來給各種不同的應用使用，否則我們會有很多的麻煩：
ø我們無法了解應用的實現的好壞，可能會去公開一些本可以不用公開的一些方法。
ø安全方面的問題會使我們很頭痛。
ø不能干預網路傳輸的優化。
三層及多層的應用已經成為主流，要想給我們的
ws**，就需要多一層自己實現的客戶端，以取代各種應用對
ws的直接呼叫。這樣上面的問題都會在自己實現的客戶端裡得到很好的解決，而且簡化了應用呼叫介面的設計，並部分地封裝了應用的業務邏輯，即對應用本身也**了。另乙個重要的效果是，不同應用的操作一致性至少在平台基礎操作上得到了一致。
平台的建設在乙個大型的應用環境中是非常關鍵的，其基礎功能提供了的質量及數量直接影響多種應用的整合效果。最重要的是體現在客戶使用的方便性及部署，維護的簡易性上。
依據具體的實際情況，平台應涵蓋的內容是不同的，這裡講的架構內容具有一定的通用性，但不一定就適合你的需要！這裡只是概要說明，詳細說明留意後繼的文章。
l使用者系統：行業裡早已經有
passport
之類的東西，然而總是感覺功能不健全，部署複雜，擴充套件困難。這裡需要提供乙個可伸縮的，分級管理的使用者系統。包括使用者庫，使用者組兩個子系統。使用者組的儲存可以依據不同的應用有各獨立的儲存空間（資料表）。
l授權系統：
.net
裡也有類似的東西，還是不夠用。在這裡進行了高度的抽象，一切授權使用視作對某一特定資源的授權，包括高階別的管理許可權的分配。另外一點是儲存上的分布，每一種資源都有各自的授權資訊表，這種資源可以是儲存在物理上分布的多個物理庫內。
l許可證驗證系統：這個意思簡單不多說，唯一要說的是許可證為每個登入成功的人發放，並作為票據訪問ws，
ws依據該票據對客戶端進行身份驗證。
l服務驗證系統：為了保護
ws，與許可證驗證系統一起使用。
l服務位址冗餘系統：簡化客戶端對
ws訪問的配製過程，並提高系統的穩健性。
l資料庫冗餘系統：
ws和資料庫之間是分離的，通過該系統
ws可訪問到正確的資料庫，同時提高系統的穩健性。
l工作流系統：這個目前可能有些侷限性，只適合於審批流程。依賴於平台的使用者系統及容器系統（乙個通用設計的資料表，可以管理類似目錄樹，使用者組，各種分類資訊的平台基礎功能）。技術細節甚多，是基於
wf實現的，有意請參見我的部落格
。旨在提供乙個易用客戶端，客戶可圖形化設計流程的工作流平台。
l資料遷移：乙個大型的資料庫應用系統在上線後，隨著時間的推移，資料庫容量會是乙個不大不小的問題。應用的資料庫邏輯只有應用才可以清楚的描述，要做乙個與應用無關的資料遷移系統必須要有高度的可配置性，才可能真正的通用起來。這可以是乙個獨立的工具，也可以進行封裝以納入平台的資料庫管理。l……
追求完美是人的優秀品質，我本人也是乙個完美主義者，但完美會破壞
80-20
法則。有一句話我不知說的對不對：真正的完美在於她
80%的完美和
20%的遺憾。過分的通用會不會發展成一種新的「文字」！我的架構不是完美的，還有很多的東西需要做。但對我個人而言，她又是完美的，因為她確實能給應用帶來很多的實惠。
開啟我的程式設計人生
這是我第一次寫技術部落格，也不求要寫的多有學術價值，只求是對自己是一種激勵，也是一種知識管理的手段。之前也已經進行了10天左右python語言的學習，我使用的參考資料為 python核心程式設計 這是一本900多頁的大部頭，但是看著一點也不覺得累很輕鬆，無論是知識點的串講，還是實戰和課後題都可以幫助...
程式設計，我人生的起航路
好久沒寫自己的東西啦！發發心情 感慨！現已大二啦！學習程式設計有一段時間啦！或多或少都有一些感受吧！程式設計，是乙個充滿枯燥，又充滿激情的事情！對於它或多或少了解了不少，不會再像第一次接觸它的生疏吧 對於這一行業，對於這一前景，對於這一苦惱，或多或少懂的些！初識程式設計 才進入大學，不知何為程式設計...
松本行弘 我的程式設計人生
松本行弘 yukihiro matsumoto 1965年4月14日出生於日本鳥取縣。1984年，就讀於筑波大學第三學科資訊學系。2年後休學，成為末日聖徒耶穌 教會的宣 講師。大學復學後，加入中田育男教授的研究室。1990年大學畢業。後在島根大學攻讀博士課程，修滿學分後退學，未獲學位。現任株式會社n...