A. 什麼是應用架構
應用架構，系統架構，軟體架構三者含義基本一致。
從1985年開始,在過去的二十多年裡，關於什麼是「軟體架構(Software Architecture)」已經基本得到了軟體工程領域普遍的認同。其中一些重要的定義介紹如下。
「軟體架構代表了系統的組織結構。這包括將系統分解為不同的部分、界定它們之間的連接、確定它們之間的交換機制、並且為後續的設計提供指導性的原則」 ---出自UML的著名原創者James Rumbaugh、Grady Booch 及 Ivar Jacobson (即架構界俗稱的「三個火槍手」)。
「軟體架構表述了一個系統的一個或一系列組織結構。這包擴了軟體構件、這些構件的外部可見特徵，以及這些構件之間的關系。」 ---出自Bass Len、Paul Clements、Rick Kazman 在2003年出版的經典的《架構的實踐》一書。
IEEE在2004年4月公布的「IEEE Standard 1471」中，提出了IEEE自己對軟體架構的定義：「軟體系統架構是根據具有參考意義的實踐而定義出來的。主要表述了有一個系統的基本組織結構、基本組成構件和互相的關系，以及構件於外部環境間的關系。同時，軟體系統架構為後續的設計和架構演化提供了指導性原則」 。IEEE Standard 1471也澄清了架構領域的許多其他感念，例如架構描述、架構標准等。
可以看出，上述諸多不同用詞的「軟體架構」的定義，其實都表達了近乎一致的思想。我們可以引用Frank Buschmann 的經典論述來定義一個架構師：「一個軟體系統的架構師是一個要擔負起軟體系統的定義、架構的實現、系統的實施、系統架構演化和系統演化的人。換句話說，是一個要為系統整個生命周期負責的人 。」
但有意思的是，軟體工程領域基本上沒有一致的有關「軟體架構師(Software Architecture)」的定義。很多公司也沒有這樣的職位；有些公司雖然有這樣的職位，但卻說不清楚這個職位所要求的技能和工作職責；另外但我們對比不同公司關於該職位的描述時，也能看到其中的不一致，例如Microsoft公司與Motorola公司對架夠師的職位表述就很不一樣。更常見的是這些職位描述嚴重混淆了很多概念，例如：當年的Rational公司就混淆了「軟體架構師」與「高級程序員」的概念。
這樣的現象，無論是在國內還是國外都很相似。這也導致了我們可以見到大量的不同職位名稱出現在軟體工程行業中的觀象，例如有解決方案架構師、系統架構師、軟體架構師、企業架構師、總工、首席架構師、Java架構師、微軟架構師及.NET架構師。
B. 什麼是軟體系統架構設計
軟體架構（software
architecture）是一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。 軟體架構是一個系統的草圖。軟體架構描述的對象是直接構成系
統的抽象組件。各個組件之間的連接則明確和相對細致地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向
對象領域中，組件之間的連接通常用介面_(計算機科學)來實現。
軟體體系結構是構建計算機軟體實踐的基礎。與建築師設定建築項目的設計原則和目標，作為繪圖員畫圖的基礎一樣，一個軟體架構師或者系統架構師陳述軟體構架以作為滿足不同客戶需求的實際系統設計方案的基礎。
軟體構架是一個容易理解的概念，多數工程師（尤其是經驗不多的工程師）會從直覺上來認識它，但要給出精確的定義很困難。特別是，很難明確地區分設計和構架：構架屬於設計的一方面，它集中於某些具體的特徵。
在「軟體構架簡介」中，David Garlan 和 Mary Shaw
認為軟體構架是有關如下問題的設計層次：「在計算的演算法和數據結構之外，設計並確定系統整體結構成為了新的問題。結構問題包括總體組織結構和全局控制結
構；通信、同步和數據訪問的協議；設計元素的功能分配；物理分布；設計元素的組成；定標與性能；備選設計的選擇。
但構架不僅是結構；IEEE Working Group
on Architecture 把其定義為「系統在其環境中的最高層概念」。構架還包括「符合」系統完整性、經濟約束條件、審美需求和樣式。它並不僅注
重對內部的考慮，而且還在系統的用戶環境和開發環境中對系統進行整體考慮，即同時注重對外部的考慮。
在Rational Unified Process 中，軟體系統的構架（在某一給定點）是指系統重要構件的組織或結構，這些重要構件通過介面與不斷減小的構件與介面所組成的構件進行交互。
從和目的、主題、材料和結構的聯繫上來說，軟體架構可以和建築物的架構相比擬。一個軟體架構師需要有廣泛的軟體理論知識和相應的經驗來事實和管
理軟體產品的高級設計。軟體架構師定義和設計軟體的模塊化，模塊之間的交互，用戶界面風格，對外介面方法，創新的設計特性，以及高層事物的對象操作、邏輯
和流程。
一般而言，軟體系統的架構（Architecture）有兩個要素：
它是一個軟體系統從整體到部分的最高層次的劃分。
一個系統通常是由元件組成的，而這些元件如何形成、相互之間如何發生作用，則是關於這個系統本身結構的重要信息。
詳細地說，就是要包括架構元件（Architecture Component）、聯結器（Connector）、任務流（Task-flow）。
所謂架構元素，也就是組成系統的核心"磚瓦"，而聯結器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果，任務流則描述系統如何使用這些元件和
聯結器完成某一項需求。
建造一個系統所作出的最高層次的、以後難以更改的，商業的和技術的決定。
建造一個系統之前會有很多的重要決定需要事先作出，而一旦系統開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關系統設計成敗的最重要決定，必須經過非常慎重的研究和考察。
C. 什麼是軟體架構
當你去了解一個東東的時候，第一步要做的，就應該去知道這個東東的定義，對於軟體架構也是如此，經過網上查詢和書籍的幫助，我大概理清了一個輪廓。
軟體行業是一個熱衷於製造‘名詞’的行業，如果退回15年，估計沒幾個人知道‘軟體架構’是什麼，在上個世紀80年代，隨著軟體開發的規模不斷擴大，軟體開發成為一個行業，初期，隨之而來的是越來越多的軟體項目的失敗，造成項目失敗的原因很多，但主要集中在開發過程，所以軟體工程應運而生，CMMI等流程標准也是一茬接著一茬的冒個不停。
在軟體工程初具規模的時候，軟體開發還是以數據結構+演算法的形式存在，進入20世紀最後10年，隨著面向對象技術、設計模式等在開發過程中的成功應用，軟體架構也走進了大家的視野。
軟體架構在定義上分為‘組成派’和‘決策派’兩大陣營，分別描述如下：
’組成派‘認為軟體架構是將系統描述成計算組件及組件之間的交互
。它有兩個非常明顯的特點：
關注架構實踐的客體——軟體，以軟體本身作為描述對象。
分析了軟體的組成，說明軟體不是一個‘原子’意義上的整體，而是有不同的部分經過特定的介面進行連接組成的一個整體，這對軟體開發來說很重要。
‘決策派’認為
軟體架構包含了一系列的決策
，主要包括：
軟體系統的組織
選擇組成系統的結構元素和它們之間的介面，以及當這些元素相互協作時所體現的行為
用於指導這個系統組織的架構風格：這些元素以及它們的介面、協作和組合
軟體架構並不僅僅關注軟體本身的結構和行為，還注重其他特性：使用、功能性、性能、彈性、重用、可理解、經濟以及技術的限制和權衡等。
‘決策派’有以下兩個顯著的特點：
關注軟體架構中的實體——人，以人的決策為描述對象。
歸納了軟體架構決策的類型，指出架構決策不僅包括關於軟體系統的組織、元素、子系統和架構風格等幾類決策，還包括關於眾多非功能性需求的決策。
按照‘組成派’的觀點，軟體架構關注的是軟體整體的分割和交互，之所以分割，是因為不同的部分在邏輯或物理上相對獨立，通過‘分而治之’的原則進行分割可以更好的理解整個系統，把握用戶的需求，但是雖然整個軟體可以分割成多個模塊或子系統，但是模塊和子系統之間的通信和交互也是很重要的，我想按照這種觀點，架構師的主要任務是將軟體分割成不同的模塊，並定義模塊之間的介面。
按照‘決策派’的觀點，軟體是一個在很多限制下產生的產品，這些限制包括用戶和技術兩方面，用戶方麵包括功能需求、性能需求、硬體需求等，技術方麵包括技術選擇、可擴展性、可重用性、可維護性等。我想按照這中觀點，架構師的主要任務就是作出上述個各種限製作出選擇或決策。《軟體架構設計》 溫昱
D. 軟體架構和系統架構的區別是什麼
不同的架構方法論，會將架構分為不同視圖，每個視圖側重某一個方面、領域的問題。
比如希賽推的ADMEMS架構體系，分為以下幾種視圖：
1. 數據架構：描述數據的存儲結構、格式等方面。
2. 物理架構：描述機器的物理部署、網路拓撲方面。
3. 運行架構：描述運行期線程、進程間的交互工作機制。
4. 邏輯架構：指如何將代碼分成不同模塊、組件，以及之間的職責分配、交互行為。
5. 開發架構：主要指開發工具的選擇，程序單元的劃分，開發管理規范流程等方面。
例如分為哪些工程、項目，源代碼管理，自動化編譯構建、測試、部署等。
目前國際上運用比較廣泛的是TOGAF架構體系，他把架構分為業務架構、數據架構、應用架構、技術架構等幾個方面。
想詳細的了解這些架構視圖，可以參考這些架構體系相關的書、資料。
另外有很多人無緣無故的抨擊架構概念，不知道是出於調侃還是無知。
埃及的金字塔、神廟的建設，不是幾個平常的泥瓦匠聚在一起就能夠造出來的。
像SAP、Oracle ERP，國內的金蝶等大規模的系統，以及空間站、火箭的控制系統等，沒有系統性的架構方法、規范、流程，結果只能是悲劇。
當規模、復雜度沒有達到一定程度，比如在一些小的團隊、產品中，架構過程可能融入到老闆、經理、組長、資歷較深的一些開發者中，融入在大家的日常工作中，以至於感覺不到架構的存在。
就算遇到一些問題，因規模不大、復雜度不高，也比較容易調整。
當這些前提條件發生變化時，架構的作用和必要性就逐步的體現出來。
總的來說，一說到架構，如果懂軟體，那麼會了解為一個軟體系統，這個軟體設計的組成結構，如哪些是基礎支持組件，哪些是完成A業務，哪些完成B業務……但說道企業架構的時候，就會問，該企業架構的幾個架構如業務架構、數據架構、業務架構、技術架構，以及如何鏈接在一起。
倒覺得，一個企業確實需要這樣的架構，但不要神話它，最主要的是業務如何最終體現到軟體中和流程中。
而採取分離式設計時，最容易的錯誤就是各自為政，集成困難。
那麼以數據為中心的架構設計，會自然提供集成的基礎。
提到過，企業最重要的資產是數據，甚至不是信息，是數據。
企業的業務流程會變，IT系統會變，所需要的信息與知識會變，唯有數據能夠積淀下來。
這有點象自然演進，考古那種，啥都
E. 什麼是軟體架構師
軟體架構師是軟體行業中一種新興職業，工作職責是在一個軟體項目開發過程中，將客戶的需求轉換為規范的開發計劃及文本，並制定這個項目的總體架構，指導整個開發團隊完成這個計劃。架構師的主要任務不是從事具體的軟體程序的編寫，而是從事更高層次的開發構架工作。他必須對開發技術非常了解，並且需要有良好的組織管理能力。可以這樣說，一個架構師工作的好壞決定了整個軟體開發項目的成敗。
軟體架構師的職責是把需求轉換為軟體世界的模型。4+1視圖中以use case作為核心，其中功能性需求以及部分非功能性需求會被軟體架構師通過分析和設計，映射為各種軟體設計模型。從OOA/OOD角度說，use case 在這個過程中是要轉換為各種UML，其中類圖，序列圖，狀態圖是最常用到的。這個轉換過程是需要智慧的，use case是目的，各種OO的原則是指導，設計模式是經驗，靈活運用是能力。裡面蘊涵了設計的美感，我覺得這個過程是衡量一個軟體架構師的最重要的指標。
當然這個過程是迭代和反饋的，我覺得概要設計和詳細設計只是思考同一個問題的粒度不同而已。
另外就是我們要熟悉語言，詳細設計是要轉換為代碼的，而且跟語言是有關系的。語言比如java/c++等，詳細設計的模型是有很多不同的。就需要軟體架構師有過這個過程，並且是非常良好的映射。
除了語言就是要熟悉某個技術領域，比如J2EE/DOTnet.從J2ee來說，可能需要了解比如jsp/servlet/ejb/jndi/jta/jdbc等。還需要了解各種web framework,o/rmapping,ioc/aop容器等等。還有的就是一些技術組件和業務組件，不如workflow,rules engine等等。另外比如各種database.熟悉這些東西的目的，是把這些軟體和組件合理並且有機的組織起來成為一個開發的架構。這個過程是需要創造力和想像力的。可能很多人認為這個地方正是軟體架構師體現能力的地方。