軟件架構作為一個概念，體現在技術和業務兩個方面。
從技術角度來說：軟件架構隨着技術的革新不斷地更新其內容，軟件架構建立於當前技術和一些基本原則
的基礎之上。 先說一些基本原則：
分層原則：分層是為了降低軟件深度復雜性而使用的關鍵思想，就像社會有了階級一樣，軟件有了層次結構。
模塊化原則：模塊化是化解軟件廣度復雜的必然手段，模塊化的目的就是讓軟件分工。
接口實現分離原則隨着軟件模塊化的不斷深入改進，面向接口編程而不是面向實現編程可以讓復雜度日趨增高的軟件降低模塊之間的耦合度，從而讓各模塊更輕松改進。從這個原則出發，軟件也從微觀進行了細致的規范化。
還有兩個比較小但很重要的原則：
細節隱藏原則很顯然把復雜問題簡化，把難看的細節隱去，能讓軟件結構更清晰。其實這個原則使用很普遍，java/c++語言中的封裝原則以及設計模式中的Facade（外觀）模式就很能體現這個原則的精神。 依賴倒置原則隨着軟件結構的進一步發展,層與層之間、模塊與模塊之間的依賴逐漸加深，而層、模塊的動態可插拔要求不端增大。依賴倒置原則可看視為接口實現分離原則的深化，根據此原則的精神，軟件進入了工具時代。這個原則有點類似於知名的好萊塢法則：Don't call us, we'll call you。
以上這些原則奠定了我們的軟件架構的價值指標。但軟件架構畢竟是建立在當前技術之上的。而每一代技術都有架構模式。過去的不再說了，讓我們現在就來看一下當前流行的技術，以及當前我們能采用的架構。 因為面向對象是當前最流行開發技術，且設計模式的大量使用使面向對象的走向成熟，而數據庫是當前最有效的存儲結構、web界面是當前最流行的用戶接口，所以當前最典型的三層次架構就架構在以上幾項技術的基礎之上，用數據庫作存儲層、用面向對象來實現業務層、用web來作為用戶接口層。我們從三層次架構談起：
因為面向對象技術和數據庫技術不適配，所以在標准三層次架構的基礎上，我們增加了數據持久層，來管理O-R雙向映射，但目前一直沒有最理想的實現技術。cmp和entity bean技術因為其實現復雜，功能前景有限，已接近被淘汰的邊緣。JDO及hibernate作為o-r映射的后期之秀，尤其是hibernate，功能相當完備。推薦作為持久層的首選
在業務層,因為當前業務日趨負載，且變動頻繁，所以我們必須有足夠敏捷的技術來保證我們的適應變化的能力，在標准j2ee系統中session bean負責業務處理，且有不錯的性能表現，但采用ejb系統對業務架構模式改變太大，且其復雜而昂貴，業務代碼移植性差。而spring 作為一個bean配置的輕量級架構，漂亮的IOC模式實現，對業務架構影響小，所以推薦作為中間層業務框架。
在用戶結構層,雖然servlet/jsp/jstl/javaBean 能夠實現MVC架構,但終究過於粗糙。struts對MVC架構的實現就比較完美，Taperstry也極好地實現MVC架構，且采用基於事件的方式，非常誘人，惜其不夠成熟，我們仍舊推薦struts作為用戶接口層基礎架構。
因為業務層是三層次架構中最有決定意義的，所以讓我們回到業務層細致地分析一下，在復雜的業務我們常常需要以下基礎服務的一種或幾種：事務一致性服務acid(tool:jta/jts)、並發加鎖服務
concurrent&&lock、池化管理服務cache、訪問控制服務(tool:jaas)、流程控制服務workflow、動態實現服務IOC，串行化消息服務(tool:jms)、負載平衡服務blance等。如果我們不采用重量級應用服務器(如weblogic,websphere,jboss等)及重量級組件(EJB)，我們必須自己實現其中一些服務。雖然我們大多情況下，不需要所有這些服務，但實現起來卻非易事。幸運的是我們有大量的開源實現代碼,但采用開源代碼卻常常是件不輕松的事。
隨着xml作為結構化信息傳輸和存儲地位日漸重要,一些xml文檔操作工具(DOM,Digester,SAX等)的使用愈發重要,而隨着xml schema的java binding工具(jaxb,xmlbean等)工具的成熟，采用xml schema來設計
xml文檔格式,然后采用java binding來生成java bean 會成為主要編程模式,而這又進一步使數據中心向xml轉移,使在中小數據量上,愈發傾向於以xquery為查詢語言的xml數據庫。最近還有一個趨
勢,microsoft,ibm等紛紛大量開發中間軟件如(microsoft office之infopath)，可以直接從xml schema 生成 錄入頁面等非常實用的功能。還有web service 的廣泛應用，都將對軟件的架構有非常重大的影響。至於面向服務架構(SOA)前景如何，三層次架構什么時候走入歷史，現在還很難定論。
aop的發展也會對軟件架構有很深的影響，但在面向對象架構里，無論aspectJ還是jboss-aop抑是aspectWerks、nanning都有其自身的嚴重問題:維護性很差,所以說它將很難走遠。也許作為一個很好的思想，它將在web service里大展身手。
rdf,owl作為w3c語義模型的標志性的語言,也很難想象能在當前業務架構發揮太大影響。但如果真如它所聲稱那樣，廣泛地改變着信息的結構。那么對軟件架構也會有深遠影響。 有關架構設計的一些忠告：
盡量建立完整的持久對象層.可獲得高回報
盡量將各功能分層,分塊,每一模塊均依賴假定的其它模塊的外觀
不能依賴靜態數據來實現IOC模式，應該依賴數據特征接口，靜態數據僅是數據特征接口實現方式之一 架構設計時xml是支持而不是依賴.但可以提供單一的xml版本的實現
從業務角度說：軟件架構應是深刻體現業務內部規則的業務架構，但因為業務變化頻紝，所以軟件架構很
難保持恆定不變，但業務的頻繁變化不應是軟件架構大規模頻繁變化的原因，軟件架構應是基於變化的架構。
一種業務有其在一段時間內穩定存在的理由(暫且不談)，業務內部有許多用例，每一種用例都有固定的規則，每一規則都有一些可供判定的項，每一項從某一維度來觀察都是可測量的，我們的架構首先必須保證完美適應每一項每一種測量方式，很多失敗的架構都是因為很多項的測量方式都發生變更這種微觀變化中。 每個用例都有規則，我們在作業務用例分析，常常假定一些規則是先驗的，持久穩定的，然而后來的業務改變常常又證明這種看法是錯誤的，然而常常我們的架構已經為之付出了不可挽回的代價。大量事實證明：規則的變化常常用例變化的根本原因。所以我們的架構要盡可能適應規則的變化，盡可能建立規則模版。 每個用例都關系着不同的角色。每一個用例的產生都必然是因為角色的變更（注意：不是替換，而是增強或減弱），所以注意角色的各種可能情況，對架構的設計有舉足輕重的意義。在我們當前的三層架構里，角色完美地對應接口概念。
在一個系統里很多用例都相互關聯,考慮到每個用例均有可能有不同的特例，所以在架構設計中，盡量采用依賴倒置原則。如架構許可可采用消息通信模式(JMS)。這樣可降低耦合度。
現在我們談一下業務穩定存在理由對業務的影響。存在即是合理，在這里當然是正確的。業務因人而存在，所以問業務存在的理由即是問不同角色的需要這項業務的理由以及喜歡不喜歡當前業務用例的理由，所有這樣的角色都應該在系統里預留。《待續》 在架構設計中有幾個原則可以考慮： 用例盡量細分 用例盡量抽象 角色盡量獨立 項測量獨立原則 追求簡單性
這里未提供相關的例子，例子會在以后的更新時提供。
業務和模式之間的關系
業務中的一些用例之間的關系常常和一些常規的模式很相似。但隨着時間的演化，慢慢地和先前的模式有了分歧。這是個正常的現象。但這對系統架構卻要求非常高，要求系統架構能適應一些模式的更替。在這里我們盡可能早地注意到用例之間的相互角色變化，為架構更新做好准備.
企業應用架構模式
《敏捷軟件開發原則、模式與實踐》 《UML精粹》 《快速軟件開發》 一、Java編程入門類
對於沒有Java編程經驗的程序員要入門，隨便讀什么入門書籍都一樣，這個階段需要你快速的掌握Java基礎語法和基本用法，宗旨就是“囫圇吞棗不求甚解”，先對Java熟悉起來再說。用很短的時間快速過一遍Java語法，連懵帶猜多寫寫代碼，要“知其然”。 1、《Java編程思想》
在有了一定的Java編程經驗之后，你需要“知其所以然”了。這個時候《Java編程思想》是一本讓你知其所以然的好書，它對於基本的面向對象知識有比較清楚的交待，對Java基本語法，基本類庫有比較清楚的講解，可以幫你打一個良好的Java編程基礎。這本書的缺點是實在太厚，也比較羅嗦，不適合現代人快節奏學習，因此看這本書要懂得取舍，不是每章每節都值得一看的，挑重點的深入看就可以了。 2、《Agile Java》中文版
這本書是出版社送給我的，我一拿到就束之高閣，放在書櫃一頁都沒有翻過，但是前兩天整理書櫃的時候，拿出來一翻，竟然發現這絕對是一本好書！這本書一大特點是以單元測試和TDD來貫穿全書的，在教你Java各種重要的基礎知識的過程中，潛移默化的影響你的編程思維走向敏捷，走向TDD。另外這本書成書很新，以JDK5.0的語法為基礎講解，要學習JDK5.0的新語法也不錯。還有這本書對於內容取舍也非常得當，Java語言畢竟類庫龐大，可以講的內容太多，這本書選擇的內容以及內容的多寡都很得當，可以讓你以最少的時間掌握Java最重要的知識，順便培養出來優秀的編程思路，真是一本不可多得的好書。
雖然作者自己把這本書定位在入門級別，但我不確定這本書用來入門是不是稍微深了點，我自己也准備有空的時候翻翻這本書，學習學習。
二、Java編程進階類
打下一個良好的Java基礎，還需要更多的實踐經驗積累，我想沒有什么捷徑。有兩本書值
得你在編程生涯的這個階段閱讀，培養良好的編程習慣，提高你的代碼質量。 1、《重構 改善既有代碼的設計》
這本書名氣很大，不用多介紹，可以在閑暇的時候多翻翻，多和自己的實踐相互印證。這本書對你產生影響是潛移默化的。
2、《測試驅動開發 by Example》 本書最大特點是很薄，看起來沒有什么負擔。你可以找一個周末的下午，一邊看，一邊照做，一個下午就把書看完，這本書的所有例子跑完了。這本書的作用是通過實戰讓你培養TDD的思路。
三、Java架構師之路
到這個階段，你應該已經非常嫻熟的運用Java編程，而且有了一個良好的編程思路和習慣了，但是你可能還缺乏對應用軟件整體架構的把握，現在就是你邁向架構師的第一步。
1、《Expert One-on-One J2EE Design and Development》
這本書是Rod Johnson的成名著作，非常經典，從這本書中的代碼誕生了springframework。但是好像這本書沒有中譯本。
2、《Expert One-on-One J2EE Development without EJB》
這本書由gigix組織翻譯，多位業界專家參與，雖然署名譯者是JavaEye，其實JavaEye出力不多，實在是忝居譯者之名。
以上兩本書都是Rod Johnson的經典名著，Java架構師的必讀書籍。在我所推薦的這些書籍當中，是我看過的最仔細，最認真的書，我當時讀這本書幾乎是廢寢忘食的一氣讀完的，有小時候挑燈夜讀金庸武俠小說的勁頭，書中所講內容和自己的經驗知識一一印證，又被無比精辟的總結出來，讀完這本書以后，我有種被打通經脈，功力爆增的感覺。
但是后來我看過一些其他人的評價，似乎閱讀體驗並沒有我那么high，也許是因為每個人的知識積累和經驗不同導致的。我那個時候剛好是經驗知識積累已經足夠豐富，但是還沒有系統的整理成型，讓這本書一梳理，立刻形成完整的知識體系了。
3、《企業應用架構模式》
Martin的又一本名著，但這本書我只是泛泛的看了一遍，並沒有仔細看。這本書似乎更適合做框架的人去看，例如如果你打算自己寫一個ORM的話，這本書是一定要看的。但是做應用的人，不看貌似也無所謂，但是如果有空，我還是推薦認真看看，會讓你知道框架為什么要這樣設計，這樣你的層次可以晉升到框架設計者的角度去思考問題。Martin的書我向來都是推崇，但是從來都沒有像Rod Johnson的書那樣非常認真去看。
4、《敏捷軟件開發原則、模式與實踐》
Uncle Bob的名著，敏捷的經典名著，這本書比較特別，與其說是講軟件開發過程的書，不如說講軟件架構的書，本書用了很大篇幅講各種面向對象軟件開發的各種模式，個人以為看了這本書，就不必看GoF的《設計模式》了。
四、軟件開發過程
了解軟件開發過程不單純是提高程序員個人的良好編程習慣，也是增強團隊協作的基礎。
1、《UML精粹》
UML其實和軟件開發過程沒有什么必然聯系，卻是軟件團隊協作溝通，撰寫軟件文檔需要的工具。但是UML真正實用的圖不多，看看這本書已經足夠了，完全沒有必要去啃《UML用戶指南》之類的東西。要提醒大家的是，這本書的中譯本翻譯的非常之爛，建議有條件的看英文原版。
2、《解析極限編程 擁抱變化》XP
這是Kent Beck名著的第二版，中英文對照。沒什么好說的，必讀書籍。
3、《統一軟件開發過程》UP
其實UP和敏捷並不一定沖突，UP也非常強調迭代，測試，但是UP強調的文檔和過程驅動卻是敏捷所不取的。不管怎么說，UP值得你去讀，畢竟在中國真正接受敏捷的企業很少，你還是需要用UP來武裝一下自己的，哪怕是披着UP的XP。
4、《敏捷建模》AM
Scott Ambler的名著，這本書非常的progmatic，告訴你怎么既敏捷又UP，把敏捷和UP統一起來了，又提出了很多progmatic的建議和做法。你可以把《解析極限編程擁抱變化》、《統一軟件開發過程》和《敏捷建模》這三本書放在一起讀，看XP和UP的不同點，再看AM是怎么統一XP和UP的，把這三種理論融為一爐，形成自己的理論體系，那么你也可以去寫書了。
五、軟件項目管理
如果你突然被領導提拔為項目經理，而你完全沒有項目管理經驗，你肯定會心里沒底；如果你覺得自己管理項目不善，很想改善你的項目管理能力，那么去考PMP肯定是遠水不解近渴的。
1、《快速軟件開發》
這也是一本名著。可以這樣說，有本書在手，你就有了一個項目管理的高級參謀給你出謀划策，再也不必擔心自己不能勝任的問題了。這本書不是講管理的理論的，在實際的項目管理中，講這些理論是不解決問題的，這本書有點類似於“軟件項目點子大全”之類的東西，列舉了種種軟件項目當中面臨的各種問題，以及應該如何解決問題的點子，你只需要稍加變通，找方抓葯就行了