建議初學者閱讀「程式設計規則」，資深者閱讀「軟體之道」
最近看了幾本關於架構的書籍，看來架構做為乙個概念和體系還很年輕，還不是很清晰。
首先架構的概念太寬泛，各領域都有架構的概念，僅就軟體領域而言，也包括：
業務架構、應用架構、技術架構、資料架構等。
本文僅就技術架構而言，有認為架構只是過程而非結果的，有認為架構只是圖表的，有認為架構是路線和思想的。我認為這只是概念層的架構，實在的、落地的、具體的、科學的架構才是美麗的架構，否則只是「浮雲」啊。
因此我認為：架構是支援某種型別軟體執行的虛擬機器和構建器。參考：「應用架構的特徵」、「平台之美」
架構不是面向具體功能的，而是面向全部需求的需求(元需求)，關注設計的設計（元設計），解決開發之共性，簡化開發之過程，提**用之舞台，可謂應用之母也。
架構是體系化的，完備的，能夠滿足一類軟體全部元需求的執行平台和構建平台，具體功能執行於其上，可以做到一通百通。
我預言：未來二十年將是各類架構平台軟體誕生並逐步成熟的年代。它將逐步超過資料庫、中介軟體的軟體市場份額。
下面給出乙個富客戶端企業技術架構的簡圖供參考：
一般架構為三層，即表示層，領域層和資料層，但真實的企業級軟體架構要求更細緻，領域層會進一步分解為中颱和後台，中颱會實現諸多企業級應用系統的元需求，如：檔案傳輸、訊息發布、錄入複核、工作流轉、執行監控等非業務性需求。
虛擬ae層實現架構與具體技術的隔離，這是保障應用不受具體技術環境影響的重要設計。
參閱：軟體領域十大命題
有朋友希望推薦架構方面的書，我在這裡回答一下，首先如果你搞開發不滿3年，建議你先不要研究架構，認真學習一下「**整潔之道」或「
程式設計規則
」（該文就借鑑了許多該書的觀點），這對你成長為架構師會有幫助，能夠寫出結構優美的**是成為架構是的第一步。
另外，架構師需要很綜合的能力，要了解軟體、硬體、網路、資料庫、中介軟體、工作流等的基本原理，欣賞繪畫、閱讀歷史、研究哲學，這樣你才能夠逐步具備進行企業級應用架構設計的能力，學習一下「系統架構設計師教程」也是不錯的選擇。
事實上，在許多國際水準的軟體企業，有10年開發經驗的，才有資格進入產品開發部，有15年經驗才允許做架構層面的設計，但在我國10年還在搞開發的人幾乎不存在了，10年如果還在搞開發會被很多人認為是沒出息的！這幾乎形成了一種文化，這應該給我們深刻的啟發和反省。
目前「架構」還很年輕，概念還比較亂，確切地說還沒有很好的書籍（有些書籍甚至會誤導你，書不是看的越多越好，一定要選擇，要看經典，「人月神話」、「人件」一定要看，不過「人件」讀起來比較澀，你可以參考我為此書寫的精簡版，你最好把它推薦給你的老闆，讓他明白軟體開發人員是智力工作者，不是「碼工」）。「架構之美」並沒有名字那麼美，尤其不要被前面幾位寫推薦序的忽悠了，該書1~30頁是值得認真閱讀的。
什麼是大資料技術架構
大資料的應用開發過於偏向底層，具有學習難度大，涉及技術面廣的問題，這制約了大資料的普及。現在需要一種技術，把大資料開發中一些通用的，重複使用的基礎 演算法封裝為類庫，降低大資料的學習門檻，降低開發難度，提高大資料專案的開發效率。大資料在工作中的應用有三種 與業務相關，比如使用者畫像 風險控制等 與決...
什麼是架構？
什麼是軟體系統的架構 architecture 一般而言，架構有兩個要素 它是乙個軟體系統從整體到部分的最高層次的劃分。乙個系統通常是由元件組成的，而這些元件如何形成 相互之間如何發生作用，則是關於這個系統本身結構的重要資訊。詳細地說，就是要包括架構元件 architecture component...
什麼是架構
什麼是架構 前言 軟體設計師中有一些技術水平較高 經驗較為豐富的人，他們需要承擔軟體系統的架構設計，也就是需要設計系統的元件如何劃分 元件之間如何發生相互作用，以及系統中邏輯的 物理的 系統的重要決定的作出。在很多公司中，架構師不是乙個專門的和正式的職務。通常在乙個開發小組中，最有經驗的程式設計師會...