來源：http://www.matrix.org.cn/blog/X-Brave/

　　在軟件開發中，我們對于軟件架構經常看到極端：要么不重視軟件架構，要么過分重視以至于她成了“天條”。我甚至碰到了這樣的事情：某公司強制推行某基于Struts的架構設計，然而到了項目組它卻處處遭到抵

制，非凡是分部基本上拋棄了這個架構設計。那么，這個原因在哪里呢？為什么一個成本高昂的架構設計沒有被接納呢？

　　實際上有時候一個良好的設計也未必會被接納，非凡是沒有java開發實際經驗甚至缺乏軟件開發經驗的項目經理試圖控制技術的時候更加如此。我們拋開這個可能的影響來看待這個問題。

　　我們發現，很多的設計人員在做軟件架構設計的時候忽略了幾個重要的問題：

　　1：軟件的架構在大的方向上是固定的。

　　這種固定依據某些基本固定的軟件模式（包括設計模式、編碼模式或者某些特定的約定）來強化和固定。這使得軟件開發在某種程度上具有某些可以明顯看得到的風格，這個風格被整個的項目貫穿和堅持，這樣當我們進入通常可怕的維護或者調整的時候，我們不會害怕我們在很多種不同的實現中經常迷失了方向。

　　2：軟件的架構在具體的應用中可以適度的可控靈活。

　　毫無疑問，軟件設計開發不可能沒有例外，在某種程度上保留一些適度的靈活時必要的。一方面，它符合軟件開發的實際；一方面，適度的可控靈活體現了一種對實現者的尊重和信任。然而，如何實現可控的靈活呢？通常，我認為可以考慮有限種類的設計選擇并通過有色彩的圖形來表明這種可選擇性。但即便如此，設計者很重要的要考慮這些不同選擇之間的關系，以及這些選擇和整體設計的兼容性，這個時候，面向接口的設計和適度的“粘合”設計是必要的。

　　3：架構設計的支撐。

　　架構設計通常會涉及到一些支撐設計，這些設計和實現水準直接的體現了系統的最有價值的部分，更細的劃分我們應該可以看到性能和結構相關的部分，以及必要的基礎類。通常，作為設計人員，我們應該能夠設計并實現系統的性能、結構、擴展、粘合等部分的工作，這部分的工作通常不應該離開設計人員的控制和把握，這些代碼的書寫或者至少積極的關注是設計人員必要的素質：我們不應該讓更多的看到我們無法寫出代碼來（我也反對沒有分工什么都做的設計人員！），實際上，這是軟件最困難也是最有樂趣的地方。非凡是在測試結果中發現這些設計實現帶來的性能的極大提高的時候是非常有成就感的事情。至于基礎類，應該是盡可能的減少依靠和耦合的。架構設計的支撐要盡可能的對客戶程序員隱藏不必要的中間細節，對基礎類要盡量簡單、穩定并真正需要。

　　通常，新興的技術會用在架構設計的支撐設計里面并被封裝以隱藏具體的實現，而通盤應用新興技術的風險是巨大的，并且對人員的獲得也是問題。有些技術是可以提供替代技術的，一些新興的技術實現也是可以參考的（但未必采用她的實現）。要記住軟件開發是需要速度、質量、可維護而不是技術表演，這個度應該由分析設計人員負責任的來把握。

　　4：面向業務還是面向頁面的。

　　也許這種說法會招致一些人的反對，認為自然而然的應該是前者，然而，實際的情況是，我們經常看到打著業務的幌子實現為面向頁面的系統，原因很簡單：后者更加的“簡單”并似乎有更少的代碼和工作量。這在某種程度上是對的。