軟件架構之美，之重要，致使多少人迷失其中。許多盲目追求者，甚至連架構、框架、模式三者之間的關係與區別都分不清，將架構與框架等同的誤解現象普遍存在。本人並非功力深厚的大師，卻也多多少少在此領域有了自己的體會與感悟，也曾如同大多數人在設計面前迷失，沉淪。只有堅持這個設計，懂得適當放棄過度設計的思想，方能跳出地獄，體會天堂的快樂。本文旨在簡要的幫助大家區分架構、框架、模式，與大家共同步入設計的天堂，一起感受設計之美，設計之優雅。
首先聲明，本文中的架構，指的是軟件架構
一、框架（Framework）
許多程序員從入門到熟悉到，會開始對衆多高手口中的架構、框架等等叫法產生濃厚的興趣，並且常常因爲使用高手們通過沉澱積累而得到的框架進行開發時感到格外輕鬆而興奮不已，因爲這些框架通常解決了常常碰到的基礎業務問題、開發維護問題。然後，這套被用來做開發的半成品，並不是架構(Architecture)，而是框架(Framework)。更爲簡單明瞭的說法，框架是一套半成品軟件系統，是一套代碼（有時可能也包括一些通用基礎業務的數庫表或者其它成形的設計）。而架構並不是代碼，是一種解決方案，是解決問題的綜合體，這在後面會說到。
我們說回框架，像struts、spring、hibernate這些非常著名的開源框架，它們都是針對某一方面的應用而提出解決問題的半成品軟件。比如說struts專門用於解決前端開發，是MVC實現的一種很好的解決方式。spring解決的範圍就廣了，它的web組件同樣用於解決前端開發，而ioc容器則用於解決對象之間的解耦與分離，AOP則更是將對象方法之間的協作問題提升到神不知鬼不覺的情況下解決掉（牛啊），當然，spring還有持久化，緩存，事務等方面的專門解決組件，是通過對其它著名框架的集成而得到的。這樣我們會發現，當我們想解決某一類問題時，我們不用從零開始編寫代碼，框架已經爲我們封裝好了一套解決方法，提供了API給我們使用。總之，框架並不是現成可用的應用系統。它只是一個半成品，需要後來的開發人員進行二次開發，實現具體功能的應用系統。
那麼，這些框架爲何如此優秀，是如何被設計出來呢？它們的優秀，在於一方面很好地解決了某一領域的問題（或多個領域），讓我們不再從零開始造輪子；另一方面也在於它們相對於其它同樣解決此問題的方法中，具有較好的性能。我想一個封裝得再好的框架，如果性能低劣差勁，是不會被人追棒的。真正封裝得好的框架，讓我們不必去關心這個框架究竟是怎麼產生的，只需調用api就能完成我們的開發，這纔是方便的框架。要設計出這樣的框架，我們就要有想法，有思路，有設計。而我們通過某種方法或某種思想來解決某種問題，這便是設計模式了。請看下面。
2、設計模式（Design Pattern）
通過上面那段話的介紹，我們就可以這樣理解，設計模式並不是什麼代碼，它，只是一種思想，一種解決問題的方法。大多數人以爲設計模式就是代碼，其實設計模式是一種思想，而代碼，僅僅是用來表達你的思想，將很抽象的思想上的東西用代碼活生生的形象的表達出來而已。而模式與框架，它們是軟件設計上的兩個不同的研究領域。但是，爲了得到一個優秀的框架，我們總要想方設法去進行抽象進行設計，以期達到可複用、易維護、低耦合等目標，因此我們需要利用適當的模式來進行設計，再用代碼給予實現。
當然，設計模式的作用並不是僅僅用來設計框架，那樣理解就過於片面。設計模式是給出了某一個單一設計問題的解決方案，並且這個方案可在不同的應用程序或者框架中進行應用。設計模式僅僅是一個單純的設計，這個設計可被不同語言以不用方式來實現，可以在不同應用中複用；而框架則是模式和代碼的一個混合體，編程者可以用各種方式對框架進行擴展，進而形成完整的不同的應用。
可是我們的開發並非是以模式和框架爲指導的，我們在不同的應用開發中，需要遵循不同的規約，這些規約包括了整體結構、層次劃分、不同部分之間的協作、功能邊界、系統性能處理、適當的技術選型、框架使用、模式應用、是否分佈式、代碼規範等等因素。而這些因素中的任何一個，都是非常重要的，這些因素綜合起來構成了我們的開發規約。而針對這些因素的綜合考慮，提出解決開發應用中問題的方案，便是架構。
3、架構(Architecture)
這可能說得不夠清晰，學術性點的表達就是，架構包括了一系列的部件、部件之間的關係、部件接口，它體現了對基礎原理的決策。架構是對軟件系統的系統組織，是對構成系統的構件的接口，行爲模式，協作關係等體系問題的決策總和。它不僅涉及到結構與行爲，而且還涉及到系統的使用、功能、性能、適應性、重用性、可理解性、經濟性和技術約束的權衡和美學考慮。一般而言，軟件系統的架構有兩個要素：
·它是一個軟件系統從整體到部分的最高層次的劃分。
一個系統通常是由元件組成的，而這些元件如何形成、相互之間如何發生作用，則是關於這個系統本身結構的重要信息。詳細地說，就是要包括架構元件（Architecture Component）、聯結器（Connector）、任務流（Task-Flow）。所謂架構元素，也就是組成系統的核心"磚瓦"，而聯結器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果，任務流則描述系統如何使用這些元件和聯結器完成某一項需求。
·建造一個系統所作出的最高層次的、以後難以更改的，商業的和技術的決定。
在建造一個系統之前會有很多的重要決定需要事先作出，而一旦系統開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關系統設計成敗的最重要決定，必須經過非常慎重的研究和考察。