架構的概念
在軟件行業，架構的概念一直沒有一個完整、統一的定義，軟件架構的概念分爲主要量大派別：組成派和決策派。組成派認爲軟件架構是：軟件系統的架構將系統描述爲計算組件及組件之間的交互，“組件”是廣泛意義上的元素，並不是指具體的技術組件。組成派的定義關注架構實踐中的客體——軟件，以及軟件本身爲描述對象；另外分析了軟件的組成，即軟件由承擔不同計算任務的組成組件，這些組件通過相互交互完成更高層次的計算。而決策派認爲，軟件架構保護了軟件設計過程中一些列問題的重要決策，軟件架構並不僅僅關注軟件本身的結構和行爲，還注重其他特性：使用、功能、性能、彈性、重用、可理解性、經濟、和計算限制、權衡、以及美學等。決策派的定義更關注架構實踐中的主體——人，以人的決策爲描述對象，並且歸納了架構決策的類型，指出架構決策不僅包括關於軟件系統的組織、元素、子系統和架構風格等幾類決策，還包括關於衆多非功能需求的決策。
說的更通俗一點，組成派關注架構的結果，而決策派關注架構的過程。而筆者認爲，架構的是一個演進的過程，沒有一成不變的架構，也沒有一蹴而就的架構，架構需要根據業務的發展而進行相應的調整，所以我們應該更加關注架構演進的過程和原因，以及在當時背景下的做出的權衡和妥協。沒有完美的架構，架構也沒有一個標準的解決方案，因爲面對不同的業務需求，面對不同的客觀因素，有不同的架構設計方案，也就是有不同的設計決策。組成派和決策派的架構概念並不矛盾，它們只不過是所站的角度不同罷了：在具體的軟件架構實際中，總是同時體現這兩“派”的架構概念。
架構決策是分層次依次展開的，決策制定的順序往往是先制定技術無關的決策，後製定技術相關的決策，後者在前者的指導下進行。架構師一定要考慮更多的實際開發中要涉及到的技術問題，從而不斷細化架構方案，這樣才能爲開發人員提供更多的指導和限制，也才能真正降低後續開發中的重大技術風險。所以，架構師的架構方案不是高來高去的，而是需要能夠落地的，並且在落地的過程中遇到的技術細節問題，架構師是需要參與解決的。這樣架構師才能與開發人員無縫對接，架構方案才能指導開發人員進行開發。
子系統、框架和架構
好的架構必須使每個關注點相互分離。把變化點錯落有致地封裝到軟件系統的不同部分（筆者感悟：封裝的思想在軟件工程中，無處不在啊！），爲此，必須進行關注點分離。通過關注點的分離來達到“系統中的一部分發生了變化，不會影響其他部分”的目標。可以通過如下的一下手段：
1、 通過職責劃分來分離關注點。面向對象設計的關鍵所在，就是職責的識別和分配。無論是對象、模塊，還是子系統，它們所承擔的職責都應該具有高內聚性，否則對象之間的鬆耦合性就失去了基礎，成爲空談。所以我們一直在提“高內聚、低耦合”，高內聚纔是低耦合的基礎。而我們經常使用的設計模式和架構模式爲特定上下文中重複出現的問題提供了通用的職責劃分方案，也是問題解決方案。
2、 利用軟件系統各部分的通用性的不同進行關注點分離。不同的通用程度意味着變化的可能性不同。這一點與面向對象設計裏面的重用發佈等價原則異曲同工。
3、 先考慮大粒度的子系統，而暫時忽略子系統是如何通過更小粒度的模塊和類組成的。避免陷入過多的細節當中，所謂“忘卻是一種能力”，就是指架構師必須有在更高層面思考的能力。
根據職責分離關注點、根據通用性分離關注點、根據不同粒度級別分離關注點是3種位於不同“維度”的思維方式，我們可以綜合運用這些手段。
無論是架構模式還是設計模式，重點關注的都是如何提供一個“協作模型”，這個協作模型通過明確協作中不同的角色鎖擔任的職責，達到“爲特定上下文的問題提供解決方案”的目的。
框架技術有助於把通用關注點和專用關注點分離開來，結果是帶來了更好的易修改性和可重用性。
作爲架構師，必須思考“軟件單元是如何組成粒度更大的整體的”這一問題。類、模塊、子系統、系統、集成系統，都是軟件單元的具體形態，只不過粒度不同罷了。軟件系統越複雜，不同粒度的分解層次就越多。這裏所謂的系統，是指由多個元素組成的邏輯實體，它完成一組特定的目標或負擔一定的職責。系統可以僅包含軟件，也可以僅包含硬件，或者兩者都包含。子系統是特殊的系統，只不過在特定的上下文中，這個系統作爲更大系統的一部分出現。系統需要架構設計，而子系統如果足夠複雜，則也需要架構設計。而不同類型的軟件系統需要不同的軟件架構設計，一個系統的不同子系統也應當有不同的軟件架構。
當然，一個系統的粒度是具有相對性的，同一個軟件單元，在不同場景下，我們會以不同的粒度看待它。所有的系統都有子系統，而所有系統都是更大系統的子系統。實踐不同場景使得軟件組成單元具有遞歸性。懂得了細節是相對而言的這一點，軟件架構師才能夠遊刃有餘地根據情況忽略應該被忽略的細節，抓住設計大局。
框架的概念，框架是一種半成品。是可以通過某種回調機制進行擴展的軟件系統或子系統的半成品。框架從某種程度上來說，是爲了軟件重用。而軟件重用本身又有一對內在的矛盾，即重用機率和重用價值，重用機率大小和重用帶來的價值大小之間的矛盾。軟件單元的粒度越大，可重用的機率就越小，但其重用所帶來的價值就越大，相反，軟件單元的粒度越小，可重用機率就越大，但其重用所帶來的價值就越小。框架的智慧就在於此：爲了追求重用所帶來的價值最大化，將容易變化的的部分封裝成擴展點，並輔以回調機制將它們納入框架的控制範圍之內。
對軟件架構的誤解，其中一個最爲普遍的就是，將架構（Acrchitecture）和框架（Framework）混爲一談。框架是軟件，而架構不是軟件。框架是一種特殊的軟件，它並不能提供完整的解決方案（準確說，是不提供業務應用的完整解決方案，而框架本身也是爲解決某一類問題而出現的），而是爲構建解決方案（這裏的解決方案即是業務應用的解決方案）提供良好的基礎，所以說，框架是半成品。框架中的服務可以被最終應用直接調用，而框架中的擴展點是供應用開發人員定製的“可變化點”。而軟件架構不是軟件，而是關於軟件如何設計的重要決策。軟件架構決策涉及到如何將軟件系統分解成不同的部分、各部分之間的靜態結構關係和動態交互關係等。這些架構決策將體現在最終開發出的軟件系統中。引入軟件框架之後，整個開發過程變成了分兩步走，而架構決策往往會體現在框架之中。軟件架構是比具體代碼高一個抽象層次的概念。架構勢必被代碼所體現和遵循，但任何一段具體的代碼都代表不了架構（這裏說的有點絕對，某一段具體的代碼，代表不了整個架構，有時卻可以代表某一個架構決策）。框架技術和架構技術的出現，都是爲了解決軟件系統日益複雜所帶來的困難而採取“分而治之”的思想。先大局後局部，就出現了架構；先通用後專用，就出現了框架。架構是問題的抽象解決方案，它關注大局而忽略細節；框架是通用半成品，還必須根據具體需求進一步定製開發才能變成應用系統。當然，框架也有架構，而且很重要。框架和架構既有區別又有聯繫，前者是複合組件特例，後者是複合組件的大局設計。軟件架構需要落地，需要了解細節，但也沒有必要將所有設計決策事無鉅細地落實，而是重點關注“重要決策”。軟件架構設計的決策範圍，應該着重放在“影響全局”的設計上，而不是所關注所有設計細節。
對面向對象開發而言，類庫和框架有很多共同之處，但它們確確實實又是不同的。類庫是類的集合，這些類之間可能是相互獨立的。與類庫相比，框架和類庫有着相似的形式，即框架也往往是類的集合，但不同之處在於，框架中的各個類不是孤立的，而框架中的業務邏輯代碼是將不同的類“連”在一起，在它們之間建立協作關係。框架通過封裝處理流程的控制邏輯，使它對開發者透明，來簡化開發工作。這種封裝也是框架和類庫的區別之一。
框架可以分爲應用框架、中間件框架和基礎設施框架三大類，形成了“應用軟件——中間件——基礎設施”的宏觀格局。框架也可以分爲技術框架和業務框架。技術框架又稱爲水平框架，業務框架有稱爲垂直框架。框架的整個開發過程，包括四個主要階段，即分析、設計、實現和穩定階段。和應用開發一樣，框架開發首先要確定框架的範圍和目標。對特定領域框架層和跨領域框架層都要識別出通用點和擴展點，其次，爲框架設計架構，將它用作實現階段的藍圖。在設計階段，也可以創建應用程序框架原型，然後在其上構建一個樣本應用，並洞察框架設計中潛在的可改進之處。框架開發的穩定階段還應提供相應的框架文檔。面向對象技術的發展極大提夠了框架的能力，並推動了框架技術被普遍接受。面向對象框架的組成部分包括具體類、抽象類和接口。抽象方法是面向對象支持“多態”的關鍵，面向對象框架藉助抽象方法實現逆向控制。許多面向對象框架在利用抽象方法支持擴展的同時，還會藉助“配置驅動”來降低使用框架的難度。框架也需要架構設計，但反過來，可以通過架構框架化，達到“架構重用”的目的。
軟件架構的作用
軟件架構對後期的軟件維護，乃至改動力度比較大的軟件升級都起着重要作用。因爲軟件架構給出了軟件系統的一個全局的視角。對軟件系統不斷的修改會使系統架構慢慢變得混亂，因爲業務的發展，是會慢慢腐蝕現有的系統架構的，所以架構需要根據業務的發展進行演進。
軟件架構設計爲什麼這麼難？因爲它是跨越現實世界與計算機世界之間鴻溝的一座橋。從面向業務的需求，到最終的面向技術的軟件系統，要跨越很大的鴻溝。軟件架構設計就是要完成從面向業務到面向技術的轉換，在鴻溝上駕起一座橋樑。軟件架構包含了結構、協作和技術等方面的重要決策，爲系統化的開發活動建立了基礎。
架構的作用包括如下幾個方面：
1、 上承業務目標：擔負着完成業務目標而進行大局規劃的職責。
2、 下接技術決策：軟件架構師將面向業務的需求轉化爲面向技術的軟件架構設計方案，爲後面的技術開發工作提供了切實的指導和限制。
3、 控制複雜性：先進行架構設計，後進行詳細設計和編碼實現，運用了“基於問題深度分而治之”的理念，利用控制複雜性。
4、 組織開發：軟件架構爲開展系統化的團隊開發奠定了基礎，它規定了軟件系統的各元素如何彼此相關的設計決策，從而可以把不同模塊分配給不同小組分頭併發進行，而軟件架構設計方案在這些小組中間扮演了“橋樑”和“合作契約”的作用。
5、 利用迭代開發和增量交互
6、 提高質量：清晰的軟件架構將各個模塊的職責劃分得有條不絮，每個模塊都有清晰的接口，這相當於間接降低了開發難度。
軟件架構會“磨損”——隨着對軟件系統不斷地修改，軟件架構將變得混亂。
所謂軟件架構重構，是指對軟件架構進行比較大的修改和調整，使它適應新需求及開發和維護的需要。軟件架構重構屬於“再工程”的一種情況，一般會經歷逆向工程、重新規劃、正向工程三個步驟。只有充分理解原有架構的設計思路，才能評估它在現在需求情況的“利”和“弊”，把合理的設計保留下來，把不妥的設計修改掉。
