好的開始相當于成功一半
開始之初的架構設計決定著軟件產品的生死存亡。“好的開始相當于成功一半”。
開始的架構設計也是最難的，需要調研同類產品的情況以及技術特征，了解當前世界上對這種產品所能提供的理論支持和技術平臺支持。再結合自己項目的特點(需要透徹的系統分析)，才能逐步形成自己項目的架構藍圖。
比如要開發網站引擎系統，就從Yahoo的個人主頁生成工具?到虛擬主機商提供的網站自動生成系統，以及IBM?Webphere?Portal的特點和局限?從而從架構設計角度定立自己產品的位置。
好的設計肯定需要經過反復修改，從簡單到復雜的循環測試是保證設計正確的一個好辦法
由于在開始選擇了正確的方向，后來項目的實現過程也驗證了這種選擇，但在一些架構設計的細部方面，還需要對方案進行修改，屬于那種螺旋上升的方式，顯然這是通過測試第一的思想和XP工程方法來實現的。
如果我們開始的架構設計在技術平臺定位具有一定的世界先進水平，那么，項目開發實際有一半相當于做實驗，是研發，存在相當的技術風險。
因此，一開始我們不可能將每個需求都實現，而是采取一種簡單完成架構流程的辦法，使用最簡單的需求將整個架構都簡單的完成一遍（加入人工干預），以檢驗各個技術環節是否能協調配合工作(非常優秀先進的兩種技術有時無法在一起工作)，同時也可以探知技術的深淺，掌握項目中的技術難易點。這個過程完成后，我們就對設計方案做出上面的重大修改，豐富完善了設計方案。
設計模式是支撐架構的重要組件
架構設計也類似一種工作流，它是動態的，這點不象建筑設計那樣，一開始就能完全確定，架構設計伴隨著整個項目的進行過程之中，有兩種具體操作保證架構設計的正確完成，那就是設計模式(靜態)和工程項目方法(RUP或XP?動態的)。?
設計模式是支撐架構的一種重要組件，這與建筑有很相象的地方，一個建筑物建立設計需要建筑架構設計，在具體施工中，有很多建筑方面的規則和模式。?
我們從J2EE藍圖模式分類http://java.sun.com/blueprints/patterns/catalog.html中就可以很清楚的看到J2EE這樣一個框架軟件的架構與設計模式的關系。
架構設計是骨架，設計模式就是肉
這樣，一個比較豐富的設計方案可以交由程序員進一步完成了，載輔助以適當的工程方法，這樣就可保證項目的架構設計能正確快速的完成。
時刻牢記架構設計的目標
由于架構設計是在動態中完成的，因此在把握架構設計的目標上就很重要，因此在整個項目過程中，甚至每一步我們都必須牢記我們架構設計的總體目標，可以概括下面幾點：
1.?最大化的重用：這個重用包括組件重用?和設計模式使用等多個方面。
比如，我們項目中有用戶注冊和用戶權限系統驗證，這其實是個通用課題，每個項目只是有其內容和一些細微的差別，如果我們之前有這方面成功研發經驗，可以直接重用，如果沒有，那么我們就要進行這個子項目的研發，在研發過程中，不能僅僅看到這個項目的需求，也要以架構的概念去完成這個可以稱為組件的子項目。
2.?盡可能的簡單明了：我們解決問題的總方向是將復雜問題簡單化，其實這也是中間件或多層體系技術的根本目標。但是在具體實施設計過程中，我們可能會將簡單問題復雜化，特別是設計模式的運用上很容易范這個錯誤，因此如何盡可能的做到設計的簡單明了是不容易的。
我認為落實到每個類的具體實現上要真正能體現系統事物的本質特征，因為事物的本質特征只有一個，你的代碼越接近它，表示你的設計就是簡單明了，越簡單明了，你的系統就越可靠。更多情況是，一個類并不能反應事物本質，需要多個類的組合協調，那么能夠正確使用合適的設計模式就稱為重中之重。
我們看一個具備好的架構設計的系統代碼時，基本看到的都是設計模式，寵物店(pet?store)就是這樣的例子。或者可以這樣說，一個好的架構設計基本是由簡單明了的多個設計模式完成的。
3.?最靈活的拓展性：架構設計要具備靈活性?拓展性，這樣，用戶可以在你的架構上進行二次開發或更加具體的開發。
要具備靈活的拓展性，就要站在理論的高度去進行架構設計，比如現在工作流概念逐步流行，因為我們具體很多實踐項目中都有工作流的影子，工作流中有一個樹形結構權限設定的概念就對很多領域比較通用。
樹形結構是組織信息的基本形式，我們現在看到的網站或者ERP前臺都是以樹形菜單來組織功能的，那么我們在進行架構設計時，就可以將樹形結構和功能分開設計，他們之間聯系可以通過樹形結構的節點link在一起，就象我們可以在圣誕樹的樹枝上掛各種小禮品一樣，這些小禮品就是我們要實現的各種功能。
有了這個概念，通常比較難實現的用戶級別權限控制也有了思路，將具體用戶或組也是和樹形結構的節點link在一起，這樣就間接實現了用戶對相應功能的權限控制，有了這樣的基本設計方案的架構無疑具備很靈活的拓展性。
?關于文檔中觀點的補充：
1. 最大化的重用：
提高重用，需要架構中的構件具有較高的獨立性，構件的實現變更不導致其它構件的設計變更；另外一點是構件間接口的穩定性和可擴展性，如果因為實現新增需求必須對接口作變更，如果相關構件不支持這個新增需求，可以保持接口不變。
提高重用的另外一個手段，是利用類似已有的構件。理想的重用是只需從不同地方拿來構件，經過簡單的組合，可實現新的產品需求。
2. 盡可能的簡單明了
使設計簡單的方式可以是對系統做分層，分層可以是基于功能需求的。比如協議方面的分層：協議的編解碼、協議的可靠傳輸、協議的應用層適配。
要使分層基于功能需求，需要對原始需求做功能需求分析，把原始需求總結歸納成幾個或幾十個類似或相近的功能需求，以這些功能需求搭建系統的功能框架，以此功能框架為基礎，對原始需求在此功能架構上做運行分析。如果有需求不能實現，則調整架構。這個過程依賴于經驗和能力。
3. 最靈活的拓展性
靈活的拓展性，依賴于接口定義、模塊間的松耦合性。
開始之初的架構設計決定著軟件產品的生死存亡。“好的開始相當于成功一半”。
開始的架構設計也是最難的，需要調研同類產品的情況以及技術特征，了解當前世界上對這種產品所能提供的理論支持和技術平臺支持。再結合自己項目的特點(需要透徹的系統分析)，才能逐步形成自己項目的架構藍圖。
比如要開發網站引擎系統，就從Yahoo的個人主頁生成工具?到虛擬主機商提供的網站自動生成系統，以及IBM?Webphere?Portal的特點和局限?從而從架構設計角度定立自己產品的位置。
好的設計肯定需要經過反復修改，從簡單到復雜的循環測試是保證設計正確的一個好辦法
由于在開始選擇了正確的方向，后來項目的實現過程也驗證了這種選擇，但在一些架構設計的細部方面，還需要對方案進行修改，屬于那種螺旋上升的方式，顯然這是通過測試第一的思想和XP工程方法來實現的。
如果我們開始的架構設計在技術平臺定位具有一定的世界先進水平，那么，項目開發實際有一半相當于做實驗，是研發，存在相當的技術風險。
因此，一開始我們不可能將每個需求都實現，而是采取一種簡單完成架構流程的辦法，使用最簡單的需求將整個架構都簡單的完成一遍（加入人工干預），以檢驗各個技術環節是否能協調配合工作(非常優秀先進的兩種技術有時無法在一起工作)，同時也可以探知技術的深淺，掌握項目中的技術難易點。這個過程完成后，我們就對設計方案做出上面的重大修改，豐富完善了設計方案。
設計模式是支撐架構的重要組件
架構設計也類似一種工作流，它是動態的，這點不象建筑設計那樣，一開始就能完全確定，架構設計伴隨著整個項目的進行過程之中，有兩種具體操作保證架構設計的正確完成，那就是設計模式(靜態)和工程項目方法(RUP或XP?動態的)。?
設計模式是支撐架構的一種重要組件，這與建筑有很相象的地方，一個建筑物建立設計需要建筑架構設計，在具體施工中，有很多建筑方面的規則和模式。?
我們從J2EE藍圖模式分類http://java.sun.com/blueprints/patterns/catalog.html中就可以很清楚的看到J2EE這樣一個框架軟件的架構與設計模式的關系。
架構設計是骨架，設計模式就是肉
這樣，一個比較豐富的設計方案可以交由程序員進一步完成了，載輔助以適當的工程方法，這樣就可保證項目的架構設計能正確快速的完成。
時刻牢記架構設計的目標
由于架構設計是在動態中完成的，因此在把握架構設計的目標上就很重要，因此在整個項目過程中，甚至每一步我們都必須牢記我們架構設計的總體目標，可以概括下面幾點：
1.?最大化的重用：這個重用包括組件重用?和設計模式使用等多個方面。
比如，我們項目中有用戶注冊和用戶權限系統驗證，這其實是個通用課題，每個項目只是有其內容和一些細微的差別，如果我們之前有這方面成功研發經驗，可以直接重用，如果沒有，那么我們就要進行這個子項目的研發，在研發過程中，不能僅僅看到這個項目的需求，也要以架構的概念去完成這個可以稱為組件的子項目。
2.?盡可能的簡單明了：我們解決問題的總方向是將復雜問題簡單化，其實這也是中間件或多層體系技術的根本目標。但是在具體實施設計過程中，我們可能會將簡單問題復雜化，特別是設計模式的運用上很容易范這個錯誤，因此如何盡可能的做到設計的簡單明了是不容易的。
我認為落實到每個類的具體實現上要真正能體現系統事物的本質特征，因為事物的本質特征只有一個，你的代碼越接近它，表示你的設計就是簡單明了，越簡單明了，你的系統就越可靠。更多情況是，一個類并不能反應事物本質，需要多個類的組合協調，那么能夠正確使用合適的設計模式就稱為重中之重。
我們看一個具備好的架構設計的系統代碼時，基本看到的都是設計模式，寵物店(pet?store)就是這樣的例子。或者可以這樣說，一個好的架構設計基本是由簡單明了的多個設計模式完成的。
3.?最靈活的拓展性：架構設計要具備靈活性?拓展性，這樣，用戶可以在你的架構上進行二次開發或更加具體的開發。
要具備靈活的拓展性，就要站在理論的高度去進行架構設計，比如現在工作流概念逐步流行，因為我們具體很多實踐項目中都有工作流的影子，工作流中有一個樹形結構權限設定的概念就對很多領域比較通用。
樹形結構是組織信息的基本形式，我們現在看到的網站或者ERP前臺都是以樹形菜單來組織功能的，那么我們在進行架構設計時，就可以將樹形結構和功能分開設計，他們之間聯系可以通過樹形結構的節點link在一起，就象我們可以在圣誕樹的樹枝上掛各種小禮品一樣，這些小禮品就是我們要實現的各種功能。
有了這個概念，通常比較難實現的用戶級別權限控制也有了思路，將具體用戶或組也是和樹形結構的節點link在一起，這樣就間接實現了用戶對相應功能的權限控制，有了這樣的基本設計方案的架構無疑具備很靈活的拓展性。
?關于文檔中觀點的補充：
1. 最大化的重用：
提高重用，需要架構中的構件具有較高的獨立性，構件的實現變更不導致其它構件的設計變更；另外一點是構件間接口的穩定性和可擴展性，如果因為實現新增需求必須對接口作變更，如果相關構件不支持這個新增需求，可以保持接口不變。
提高重用的另外一個手段，是利用類似已有的構件。理想的重用是只需從不同地方拿來構件，經過簡單的組合，可實現新的產品需求。
2. 盡可能的簡單明了
使設計簡單的方式可以是對系統做分層，分層可以是基于功能需求的。比如協議方面的分層：協議的編解碼、協議的可靠傳輸、協議的應用層適配。
要使分層基于功能需求，需要對原始需求做功能需求分析，把原始需求總結歸納成幾個或幾十個類似或相近的功能需求，以這些功能需求搭建系統的功能框架，以此功能框架為基礎，對原始需求在此功能架構上做運行分析。如果有需求不能實現，則調整架構。這個過程依賴于經驗和能力。
3. 最靈活的拓展性
靈活的拓展性，依賴于接口定義、模塊間的松耦合性。
![[Oracle]快速構造大量數據的方法](http://pic.xiahunao.cn/[Oracle]快速構造大量數據的方法)
