轉自：
http://tech.it168.com/a2009/0417/272/000000272586.shtml
如何更好地進行軟件架構設計，這是軟件工程領域中一個永恒的重點話題。過去幾十年來，國際軟件工程界在軟件架構設計方面已經獲得了長足發展，大量圖書、文章和文獻記載了這方面的成熟經驗與成果。軟件架構設計往往是一件非常復雜的工作，涉及到很多細節和方方面面，可探討的話題也非常之多。囿于篇幅限制，以下只能根據筆者個人理解，遴選出軟件架構設計的個別要點，結合當前流行的敏捷軟件工程思想，與大家分享一下自己在軟件架構設計方面的心得和體會。
架構決定成敗
軟件架構是軟件產品、軟件系統設計當中的主體結構和主要矛盾。任何軟件都有架構，哪怕一段短小的HelloWorld程序。軟件架構設計的成敗決定了軟件產品和系統研發的成敗。軟件架構自身所具有的屬性和特點，決定了軟件架構設計的復雜性和難度。
這幾年流行一個說法（管理諺語）：“細節決定成敗”，這句話其實只說對了一半。細節確實很重要，很多項目、產品就輸在細節的執行上。一方面，戰術細節固然很重要，但另一方面，戰略全局也同樣重要，對應的我們可以說：“戰略決定成敗”。戰略性失敗，就好比下一盤圍棋，局部下得再漂亮、再凌厲，如果罔顧大盤，己方連空都不夠了，還有官子（細節）獲勝的機會嗎？必然是中盤告負。
類似地，正確的軟件架構設計，應該既包括戰略全局上的設計，也包括戰術細節（關鍵路徑）上的設計。有一種錯誤的觀點認為，軟件架構設計只要分分層和包，畫一個大體的輪廓草圖，就完事了。這種“紙上談兵”型的架構師行為是非常有害的。事實上，既然軟件架構是軟件建筑的主體結構、隱蔽工程、承重墻和要害部位，那么軟件架構也必然要落實到實際的算法和代碼，不但要有實現代碼，還要包括對這部分架構進行測試的代碼，以保證獲得高質量的、滿足各種功能和非功能質量屬性要求的架構。除了完成概念、模型設計外，軟件架構師一定要參與實際的編碼、測試和調試，做一位真正的hands-on practitioner，這已經成為了敏捷軟件工程所倡導的主流文化。
兩個架構
我們在日常的軟件產品和系統開發中，實際上會遇到兩種、兩個部分的軟件架構，即待開發的應用部分的軟件架構（簡稱“應用架構”），以及既有的基礎平臺部分的軟件架構（簡稱“基礎架構”）。這兩部分架構之間是互為依賴、相輔相成的關系，它們共同組成了整個軟件產品和系統的架構。
基礎架構的例子包括：.NET和J2EE等主流的基礎平臺和各種公共應用框架，由基礎庫API、對象模型、事件模型、各種開發和應用的擴展規則等內容組成。我們只有熟悉基礎架構的構造細節、應用機理，才能有效地開發出高質量、高性能的上層應用。然而，開發一個面向最終用戶的軟件應用系統和產品，僅僅掌握一般的計算機高級編程語言知識和基礎平臺架構、API的使用知識顯然是不夠的，我們還需要根據客戶應用的類型和特點，在基礎架構之上，設計出符合用戶要求的高質量應用軟件。
熟悉OOA、OOD抽象建模技術、設計原則以及架構模式和設計模式等等方法技術，不但有助于我們更好地理解和利用基礎平臺架構，也有助于我們設計開發出更高質量的應用軟件架構。
風險驅動、敏捷迭代的架構設計與開發
軟件架構將隨著軟件產品和系統的生命周期而演化，其生命期往往超過了一個項目、一次發布，甚至有可能長達數年之久，因而軟件架構無論對于客戶還是開發商來說都是一項極其重要的資產。
軟件架構的設計應該遵循什么樣的開發過程？或者說，有沒有更好的、成熟的軟件架構設計和開發過程？回答是，21世紀的軟件架構設計應該優先采用敏捷迭代的開發方式和方法。與傳統做法不同，敏捷迭代開發主張軟件架構采用演進式設計（evolutionary design），一個軟件產品或系統的架構是通過多次迭代，乃至多次發布，在開發生命周期中逐步建立和完善起來的。
好的軟件架構不是一蹴而就的。在架構設計開發過程中，我們應該盡量避免瀑布式思維，通過一個“架構設計階段”來完成系統的架構設計乃至詳細設計，然后再根據架構圖紙和模型，在“編碼實現階段”按圖索驥進行架構的編碼與實現。這種傳統做法的錯誤在于認為軟件架構就是圖紙上的模型，而不是真正可以高質量執行的源代碼。幾十年的軟件工程實踐表明，沒有經過代碼實現、測試、用戶確認過的架構設計，往往會存在著不可靠的臆想、猜測和過度設計、過度工程，極易造成浪費和返工，導致較高的失敗率。
風險是任何可能阻礙和導致軟件產品/系統研發失敗的潛在因素和問題。軟件架構是軟件產品和系統研發的主要矛盾和主要技術風險，軟件架構的質量決定了整個軟件系統和產品的質量。不確定性往往是軟件架構設計當中一種最大的潛在風險。因此，軟件架構的設計與開發應該遵循風險驅動的原則，在整個開發生命周期內至始至終維護一張風險問題清單，隨著迭代的前進，根據風險的實時動態變化，首先化解和處理最主要的架構風險，再依次化解和處理次要的架構風險。
架構設計的可視化建模
軟件架構設計的難度源于軟件設計問題本身的復雜性，一個復雜的軟件系統往往存在大量復雜的、難于被人類所理解的細節和不確定因素。抽象與建模是人類自誕生以來就已掌握的理解復雜事物的方法，因而人類所從事的軟件設計工作本質上也是一個不斷建模的過程。我們可以通過各種抽象的模型和視圖，從各個不同層次、宏觀和微觀的角度來理解復雜的軟件架構，以保證作出正確和有效的設計。
有人認為：“軟件架構就是源代碼（source codes）”以及“源代碼就是設計”。這種說法其實是片面的。什么是真正的軟件？我們知道，最終可以在電腦上執行的真正的軟件其實是二進制代碼0和1，借助編譯器我們把高級編程語言翻譯成底層的匯編語言、機器語言等，沒有人能直接、完整地看到二進制程序在CPU上的實際運行狀況（runtime），人們大多只能通過各種調試工具、窗口視圖等方式來間接地動態觀察這些真正的軟件的運行片段。因此，Java、C#、C++ 等等設計時（design time）源代碼在本質上也是一種模型，雖然是一種經處理后可執行的靜態模型，但顯然它們并不是真實軟件和軟件架構的全部。可見，源代碼模型（有時也叫實現模型）與UML模型其實都是軟件架構的一種模型（邏輯反映），差別就在于抽象層次的不同。完整的軟件架構（建筑）不僅僅包括源代碼（實現模型），還包括了需求模型、分析模型、設計模型、實現模型和測試模型等等許多模型，軟件架構本身就是一組模型的集合。
UML、SysML是當前國際上流行的軟件/系統架構可視化建模語言。在編寫實際的代碼之前，利用包圖、類圖、活動圖、交互圖、狀態圖等等各種標準圖形符號對軟件架構進行建模，探討和交流各種可行的設計方案，發現潛在的設計問題，保證具體編碼實現之前抽象設計的正確性，被實踐證明是一種非常有效和高效、敏捷的工作方式。
架構設計的重用
重用（Reuse）是在軟件工程實踐中獲得高效率、高質量產品和系統開發的一種基本手段和主要途徑，通過有組織的、系統和有效的重用，我們往往可以獲得10倍率以上的效率提升。而一個優秀的、有長久生命力的軟件架構（比方主流的一些框架軟件），其本身或其組件被重用的次數越多，其體現的價值也就越大。
軟件重用有各種不同的范圍、層次、粒度和類型，從函數重用、類重用、構件/組件重用、庫（API）重用，到框架重用、架構重用、模式重用，再到軟件設計知識、思想的重用等等，重用的效能和效果各有不同。
軟件工程經過幾十年的發展，已經積累了大量的軟件架構模式和設計模式，它們記載、蘊藏了大量成熟、已經驗證的軟件設計知識、思想和經驗。我們平時對各種基礎平臺、主流框架和API的應用和調用，本身就是一種最為普遍的重用形式。而一個優秀、成熟的軟件研發組織，必然會在日常開發中注意收集各種軟件設計知識和經驗，建立和維護基于架構模式和設計模式等內容的軟件重用知識庫，積極主動和頻繁地運用各種軟件模式來解決實際工程問題。
框架（Framework）是一類具有高可重用度的軟件，針對某一類應用或領域，它們具有非常靈活的、高度可擴展的軟件架構。那么，如何才能設計出可重用的軟件架構或其組件？借助于OOA、OOD等抽象分析和設計技術是一種重要的方法。人們在實踐中發現，往往越抽象的東西，其適應面也就越廣，可重用度也就越高；相反，越具體的東西，其適應面也就越窄，可重用度也就越低。重用，意味著充分利用現成、既有的東西、成果來解決新問題或重復的問題，以“不變”應“萬變”。在軟件架構設計中，應該主動地區分軟件架構中的“不變”與“可變”之處，系統地管理好這些穩定點和變化點以適應未來的變化，這也是提高軟件架構重用度、獲得高質量框架設計的一種重要方法。
架構設計的權衡
與其它所有工程行業一樣，軟件工程本質上也是一門講究權衡的科學和藝術。軟件架構設計的最難之處往往在于如何在各種相互競爭、矛盾的制約條件之下，作出巧妙的最佳權衡。軟件架構設計的權衡水平，也是最能體現軟件架構師的設計經驗、能力和技巧的地方。
在軟件開發和軟件架構的設計過程中，從選擇平臺，到選擇語言，選擇框架，選擇設計模式，選擇工具…等等，我們無時不刻都需要權衡，對各種候選項作出合理評判。在架構師帶領下，軟件研發團隊往往還需要對近期目標與遠期目標、質量與速度和效率、質量與成本、功能與性能、靈活性與復雜性…等等許多彼此矛盾的設計選項、因素和約束進行細致、小心和理性的權衡。
理性權衡意味著科學決策。進行有效的架構設計權衡，離不開科學的方法，也就是如何運用定量分析和定性分析相結合的方法、因果邏輯和根源分析等等技術，找到最終的甜點（Sweet Spot）。許多時候，能否在很短的時間內作出迅速、果斷而正確的科學權衡與取舍決策，構成了一個軟件研發團隊核心競爭能力的一部分。