關於軟體的架構設計

好的開始相當於成功一半

開始之初的架構設計決定著軟體產品的生死存亡。“好的開始相當於成功一半”。

開始的架構設計也是最難的，需要調研同類產品的情況以及技術特徵，瞭解當前世界上對這種產品所能提供的理論支援和技術平台支援。再結合自己項目的特點(需要透徹的系統分析)，才能逐步形成自己項目的架構藍圖。

比如要開發網站引擎系統，就從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. 最靈活的拓展性
靈活的拓展性，依賴於介面定義、模組間的松耦合性。