今天面試一個牛人，跟我們談起了他做過從UML到生成代碼的工作，而這正是俺發展的目標－架構設計。所以當時我就問了下他跟架構設計密切相關的設計模式的一個－橋接模式，他沒接觸過。

         晚上回來，我本來想把個系統源碼再研究下，好方便下一步的工作，但總覺得自己少做了些什么。

         架構設計決定著軟件產品。

         這是我以前經常聽到的一句話，但現在的項目，對于我來說，就是把一些比較出名穩定的開源架構拼接起來，比如SSH(spring+struts+hibernate)，很慚愧，這就是我的架構。

          大家都說開始的架構是最難的，需要調研同類產品的情況以及技術特征，了解當前世界上對這種產品所能提供的理論支持和技術平臺支持。再結合自己項目的特點(需要透徹的系統分析)，然后逐步形成自己項目的架構。

          然而，做項目的我們，都深有體會，總是抱怨客戶的需求老是在改變。往往問題本身并不是很困難，但是代碼維護性的要求總是很高 ，但往往我們做到后期就很難去重新架構自己的項目（導制這方面的因素很多）、豐富完善了設計方案。

        工程項目方法（RUP或XP ）為我們提供了架構設計的正確完成保證。

         運用成熟的模式設計進行架構設計成為了必然，設計模式成為支撐架構的一種重要組件，但如果為了模式而架構又會成為你項目的絆腳石，所以，如何正確的應用又成為了一個很重要的課題，但這些前提都是以熟悉各種設計模式為前提的，這其中最重要的一點就是：時刻牢記架構設計的目標。

         把握目標的點，我從網上扣了過來（哈哈～～～，有網絡就是好）

         1. 最大化的重用：
         這個重用包括組件重用和設計模式使用等多個方面。
         比如，我們項目中有用戶注冊和用戶權限系統驗證，這其實是個通用課題，每個項目只是有其內容和一些細微的差別，如果我們之前有這方面成功研發經驗，可以直接重用，如果沒有，那么我們就要進行這個子項目的研發，在研發過程中，不能僅僅看到這個項目的需求，也要以架構的概念去完成，這個可以稱為組件的子項目。

         2. 盡可能的簡單明了
         我們解決問題的總方向是將復雜問題簡單化，其實這也是中間件或多層體系技術的根本目標。但是在具體實施設計過程中，我們可能會將簡單問題復雜化，特別是設計模式的運用上很容易范這個錯誤，因此如何盡可能的做到設計的簡單明了是不容易的。

        落實到每個類的具體實現上要真正能體現系統事物的本質特征，因為事物的本質特征只有一個，你的代碼越接近它，表示你的設計就是簡單明了，越簡單明了，你的系統就越可靠。更多情況是，一個類并不能反應事物本質，需要多個類的組合協調，那么能夠正確使用合適的設計模式就稱為重中之重。

        我們看一個具備好的架構設計的系統代碼時，基本看到的都是設計模式，寵物店(pet store)就是這樣的例子。或者可以這樣說，一個好的架構設計基本是由簡單明了的多個設計模式相互配合完成的。

        3. 最靈活的拓展性
        架構設計要具備靈活性 拓展性，這樣，用戶可以在你的架構上進行二次開發或更加具體的開發。而要具備靈活的拓展性，就要站在理論的高度去進行架構設計。

        比如現在工作流概念逐步流行，因為我們具體很多實踐項目中都有工作流的影子，工作流中有一個樹形結構權限設定的概念就對很多領域比較通用。樹形結構是組織信息的基本形式，我們現在看到的網站或者ERP前臺都是以樹形菜單來組織功能的，那么我們在進行架構設計時，就可以將樹形結構和功能分開設計，他們之間聯系可以通過樹形結構的節點link在一起，就象我們可以在圣誕樹的樹枝上掛各種小禮品一樣，這些小禮品就是我們要實現的各種功能。有了這個概念，通常比較難實現的用戶級別權限控制也有了思路，將具體用戶或組也是和樹形結構的節點link在一起，這樣就間接實現了用戶對相應功能的權限控制，有了這樣的基本設計方案的架構無疑具備很靈活的拓展性。