[轉]如何按部就班向dotnet架構師發展

微軟的DotNet開發絕對是屬於那種入門容易提升難的技術。而要可以成爲DotNet架構師沒有三年或更長時間的編碼積累基本上是不可能的。特別是在大 型軟件項目中，架構師是項目核心成員，承上啓下，所以RUP方法論也認同以架構爲核心，體現4+1視圖在整個軟件開發過程當中的重要做用。架構人員既要精通 技術，又要熟悉業務，並且基本對軟件生命週期各階段的相關技術都須要有相關的積累和知識儲備，而這些不通過多年的磨練是很難達到這個高度的。

要成爲一個合格的架構師首先必須是一個合格或優秀的編碼人員，對於開發來說編碼始終都是最重要的一項技能，在編碼過程當中只要本身善於去思考和分析問題，就 能夠多學到不少相關的知識和技術。因此咱們在開發過程當中必定要注意新知識和新技術的學習，前人經驗和成果的學習。編碼過程當中應該去思考的一些問題有：

1.在編碼過程當中本身是否作單元測試，是否使用相關工具作單元測試，若是沒有的話是什麼緣由沒法把單元測試作起來？
2.本身編碼的泄露率狀況，編碼泄露的BUG的緣由分析
3.是否有意識的對代碼進行重構，重構過程當中是否引入了相關設計模式的思想？
4.是否對C#語言的一些高級特性進行學習，如反射調用，異步處理等。
5.是否對Remoting和WebService兩種分佈式技術作過研究和對比分析？
6.是否常常研究開源項目和開源代碼，如Duwamish，PetShop，NUnit,Enterprise Library，Nant等
7.是否對對象持久化機制和O/R Mapping等相關技術作過相關的研究
8.平時在編碼過程當中是否注重公用組件和公用類的複用和抽取
9.本身在平時工做和學習中是否常常開發些小工具提升工做效率，鞏固學習知識

設計和編碼實際上是密切而不可分的，對於嚴格將設計和編碼分開的瀑布模型通常也僅僅在大型項目中應用。而及時編碼和設計分離，也不是將編碼人員不須要思考， 編碼活動始終是一項創造性的勞動，若是否認這個觀點那就表明編碼過程徹底不須要人員介入而能夠徹底自動化。所以在這裏談設計主要仍是指設計人員的系統化思 維能力，設計人員應該比開發人員站高一個層次來分析和思考問題。設計人員最重要的一個技能就是現實->抽象的轉換，而這個就須要談到方法論的問題 了，技術人員須要積累面對對象分析和設計或結構化分析知識的積累，須要有較強的數據庫分析和設計能力。一個設計可否成爲很好的架構師關鍵就在這種積累的深 度和廣度上面了。

所以在設計過程當中應該考慮的問題有：
1.你如今分析和設計能力可否勝任大中型的應用系統仍是隻是獨立功能分析和設計？
2.設計過程當中是否有意識的考慮到組件的複用和相關接口設計準則。是否可以很天然的將分析模式，設計模式的相關內容應用到本身的設計過程當中。
3.是否對XP，RUP，面向對象，結構化等方法論都有過較系統化的學習和思考。
4.是否真正理解系統功能需求和非功能需求對系統設計的不一樣的指導做用。
5.對本身設計的功能是否會根據後期的變動來反思本身的設計爲什麼不能很好的適應變動？
6.是否在設計過程當中常常本身開發些原型來對本身的設計思路進行驗證？
7.是否專一技術的同時開始專業業務流程的分析，關注業務建模？

若是咱們在設計和開發過程當中常常關注這些知識和技能的話，成爲一個合格的架構師是遲早的事情。平時可以勝任工做開發用到的知識和技能是微不足道的，若是自 己不是有意識的去學習這些知識的話，那技能是很可貴到進一步提升的。我參加過兩次微軟的架構師培訓，在北京的微軟架構峯會上也有機會專門參加了 P&P Workshop的學習，培訓老師是微軟總部SmartClient Architecture and Design Guide一書的做者Edward A.Jezieski，讓我感覺最深是老外深入的技術底蘊，對程序開發的執著。

對於DotNet架構常常用到的知識和技能儲備有
1.RUP方法論，4+1視圖。用例驅動業務建模->分析模型->設計模型
2.用例模式->分析模式->設計模式
3.經常使用的分佈式技術
4.對安全，異常，日誌，性能等非功能性需求的關注
5.對應用系統總體業務的關注

相關的一些參考書籍(微軟網站和電驢均可如下載到)

微軟網站提供的參考書籍
Enterprise Solution Patterns Using Microsoft .NET
.NET Data AccessArchitecture Guide
Application Architecture for .NET:Designing Applications and Services
Caching Architecture Guide for .NET Framework Applications
Designing Application-Managed Authorization
Smart Client Architecture and Design Guide

其它架構方面的參考書籍
Software Architecture In Practice
Pattern-Oriented Software Architecture
The Art Of Software Architecture
Beyond Software Architecture

模式方面的書籍
Analysis Patterns
Design Patterns - Elements of Reusable Object-Oriented Software
Applying UML and Patterns
Design Patterns Explained

===================================================
2015年8月，增長架構設計和概要設計的區別

架構設計

架構設計包括了功能性架構和技術架構設計兩個部分的內容，功能性架構解決業務流程和功能問題，而技術架構解決非功能性需求等問題。兩種架構都包括了動態和靜態兩個方面的內容，對於功能性架構中動態部分爲業務流程驅動全局用例，用例驅動的用例實現等；對於技術架構中動態部分爲架構運行機制，而靜態部分爲框架，分層等方面的內容。

功能性架構包括了全局用例設計，這個自己是用例分析和設計的一個延續，而全局用例分析建議的思路仍然是業務流程，業務用例建模到系統用例建模的過程。全局用例分析清楚後能夠開始考慮子系統和模塊的劃分，造成系統的功能架構圖，固然在劃分過程當中必定要考慮到經過CRUD矩陣等分析方法來分析模塊如何劃分合理，如何保證模塊自己高內聚和鬆耦合。

在全局用例分析完成後涉及到數據模型的設計，數據建模仍然從業務驅動，從最初的業務對象和單據入手，到最終的數據概念模型和邏輯模型等。架構設計中全局數據模型不必定覆蓋全部的數據對象和數據表；可是核心的主數據，核心業務單據數據必定要覆蓋到，模型到的層次到邏輯模型便可。若是用面向對象的分析方法，這裏須要出的是UML建模中的概念模型和邏輯模型，體現核心對象和類，核心對象和類之間的關係。

將全局用例分析和數據模型創建融合在一塊兒，能夠看到這二者結合起來會造成一個系統完成的領域模型層。一直認爲領域模型思路應該引入架構設計，只有領域模型纔是真正關注功能性架構，而不用立刻關注到具體的技術分層和技術實現。

前面二者作完後能夠看到一個大系統被分解爲了多個子系統或模塊，那麼接着要考慮的就是模塊間的集成架構，分析完集成架構模塊間的接口基本就出來了。接口設計應該是架構設計的另一個核心內容。要明白架構設計一個重要做用就是架構設計完成後各個模塊能夠並行開始概要設計，詳細設計和開發工做。只要你們都遵循架構設計約定的接口規則便可以了。

集成架構考慮完另一個核心內容就是公共可複用組件的抽取和識別，包括了功能組件和技術組件，須要識別出來哪些是可複用的，如何進行復用。對於複用層次自己又包括了數據層複用，邏輯層組件複用，界面層UI組件的複用等。複用是架構價值體現的的另一個關鍵點。

這些都作完後，接着一個步驟應該在架構設計階段作的就是對架構輸出成功進行模擬驗證，前面完成了分解動做，必須經過模擬驗證來看看後續分解內容可否很好的集成和組裝。不少時候咱們作架構設計的時候每每不作這塊內容，致使架構設計一些內容變成空中樓閣，沒法落地。

再回來看技術架構設計，首先談下靜態部分的內容。這裏面就包括了軟件開發的分層架構，開發框架等內容，包括開發規範約定，技術平臺和語言的選擇，使用的規約等都須要考慮。不少時候咱們看到談架構的時候說到的三層或多層架構，僅僅是完整架構設計裏面很小的一部份內容。

除了分層架構外，接着考慮的就是各類非功能性須要，咱們在架構上須要如何設計。這裏麪包括了事務，緩存，異常，日誌，安全，性能，可用性，容錯能力等。這些逐個點都要在架構設計中說清楚如何考慮，因爲這些自己就屬於一個應用系統中技術平臺要考慮的內容，所以應該設計爲較爲公用的技術組件供上層的業務組件使用。要明白不少時候爲什麼談到AOP或可插拔架構，只有這樣去考慮問題，纔會考慮真正的功能性架構設計和功能實現和非功能性技術架構這塊充分解耦，實現進一步的靈活裝配。

再回到架構設計視圖層面，還須要考慮的就是整個應用系統的部署架構，部署架構自己也包括了邏輯視圖和物理視圖，應用最終開發出來瞭如何進行部署，這涉及到了IT基礎架構方面的細化，也須要考慮清楚。

概要設計

概要設計首先要明白的是根據架構設計的內容進一步對某個模塊的設計進一步細化。架構設計在系統級，而概要設計在子系統或模塊級。拿建築來比喻，架構設計是把一個建築的框架結構所有定清楚，包括地基要挖多深，核心框架和承重結構如何，每一層的結構圖如何，應該分爲幾個大套間這些內容都應該定下來。每一個大套間的水，電，氣等管道接入點在哪裏等。而概要設計要作的是拿着一個套間，來考慮這個套間內部該如何設計，如何劃分功能區域，如何將水電氣接入點進一步在房間內延伸，哪些地方須要進一步增長非承重的隔斷等。

基於以上思路咱們看到在架構設計的時候，除了不多部分的核心用例咱們會談到具體的用例實現完，大多數功能咱們都不會談到具體的用例實現層面。而到了概要設計則須要進一步的分解我這塊模塊究竟須要實現哪些功能點，具體的每一個功能點究竟如何實現都必需要考慮到。

嚴格的概要設計，咱們但願是到了概要設計的某個功能模塊，模塊所涉及到的核心的類所有會出來，類關係圖所有會出來。數據庫設計也進一步細化到該模塊的數據庫物理模型。對於用例進行用例實現分析，在實現分析過程當中能夠看到每一個類核心的public方法所有會分析識別出來。

拿着架構設計的接口，概要設計也須要進一步細化，細化出接口具體的輸入輸出和使用方法，包括模塊應該使用哪些外部接口，模塊自己又提供哪些接口出去都必須細化清楚。作概要設計的時候必定要清楚當前作的這個模塊在整個應用系統架構中的位置，和外部的集成和交互點。

概要設計不用到詳細設計這麼細化，包括類裏面的私有方法，public方法的具體實現步驟和邏輯，僞代碼等。可是咱們要看到概要設計裏面對於核心的業務邏輯必需要設計清楚如何實現，實現的機制和方法。不少時候咱們到了概要設計畫uml的時序圖，不少時候一看沒有任何意義，全是跨層的簡單的交互和調用。這個應該在架構設計的架構運行機制說清楚便可。設計到多個業務類間的交互調用纔是重點，一個簡單的功能增刪改查，徹底沒有必要畫什麼時序圖。

其次架構設計中給出了各類安全，性能，緩存的設計。那麼在概要設計中出來另一個問題，即架構給出的各類實現方案和技術，咱們在概要設計中如何選擇，如何使用。不是全部功能都須要緩存，那就要說清楚哪些功能根據分析須要緩存，須要緩存哪些對象，緩存自己的時效性如何設置等問題。

概要設計做爲咱們要達到一個目的，就是不管是誰拿走概要設計來作，最終實現出來的功能模塊不會走樣，功能模塊最終實現出來可能有性能，易用性等方面的問題，可是整個功能實現的大框架必定是定了的。

============================================================
2015-10月更新，架構思考

組件劃分和服務接口

組件化開發思路在很早之前就已經提出，只是當時的組件間交互更多的談接口而非服務，同時也沒太關心單個組件自己的全生命週期管理。談組件的時候必定不要先談開發和技術框架，而是真正從業務架構和應用架構出發去考慮整個業務系統的組件劃分，其中包括了業務組件和技術組件，各自應該暴露業務和技術服務能力。業務能力組件化和組件能力服務化也是一直強調的SOA核心思想。

在組件劃分清楚後，須要優先考慮組件間的交互而須要暴露出來的服務接口，即組件之間只能經過服務進行協同以進一步實現組件間的鬆耦合。其次纔是考慮單個組件在實現的時候，結合分層開發技術框架涉及到分層，在這裏能夠進一步參考領域模型驅動和設計的思路，不然很容易實現爲數據庫表驅動功能而不關心領域模型設計和領域邏輯的實現，即雖然技術框架分層了可是職責不清，邏輯混亂並多處實現。

組件內部的實現一個重點就是應用層和領域層之間的關係，即在應用和領域層之間增長了一個服務層，服務層重點是服務接口和服務的組合等工做，而具體業務規則和數據處理的邏輯在倉儲類和規則類裏面來實現。注意對於組件內部應用層和領域層交互的服務並不必定要作爲分佈式的Service服務，也能夠直接使用內部的API服務接口便可。將服務層服務接口具體的邏輯實現分離的一個重點就是在後期很容易將服務接口發佈爲一個供其它組件遠程調用的服務方法。

開源組件和技術

對於單一的技術每每很難知足互聯網業務場景下不一樣的功能需求和非功能性需求，對於不一樣的功能或技術實現每每都須要選擇大量的開源組件或技術進行集成。可是這些獨立的技術組件如何集成爲一個高效的總體就變得至關重要。任何技術的選擇都必須爲了業務需求服務，模式分析是選擇技術的一個重點，即在什麼樣的業務場景下，面對什麼問題咱們究竟應該選擇什麼樣的開源技術來實現最合適。

首先是開發技術框架層面的，即常說的基於MVC模式的多層框架，用的最多的估計仍是SSH框架，其中在數據庫層面又有Hibernate或iBatis多種實現，在控制層自己又有struts和spring mvc多種實現。在展示層相關的技術點更多，包括了一些前端基於javascript和jquery的框架引入，Ajax實現，包括當前互聯網各類前端響應式框架，Html5技術等。技術框架的選擇看似和業務無關，可是卻須要進行業務場景分析，包括當前開發的應用是否須要同時支撐web端和移動app端，是否存在和外部集成和服務接口暴露，在業務交互和易用性層面有哪些要求，這些都須要考慮進去。

其次是實現核心技術能力的技術組件，其中包括了緩存，消息，流程引擎，搜索，安全，任務，日誌等諸多內容，這些當前每每都有現成比較成熟的開源技術來實現。如經過memcached或redis來實現緩存，經過rabbitMQ或zeroMQ來實現消息和事件管理，基於lucence的全文檢索引擎，開源的ETL技術實現數據集成，開源的jbpm流程集成等。在選擇這些技術的時候要注意和前面總體技術框架的集成，技術組件應該保持其高內聚和獨立性，僅僅技術組件的能力經過服務暴露出去實現和上層應用的集成。要作到這一點每每就須要對開源組件進一步進行封裝和定製，以和技術框架造成一個完整的總體，同時又不要把底層技術組件的複雜度暴露給業務功能的開發過程當中。還有就是互聯網應用還涉及到外部技術服務能力的引入，如外部的郵件通知服務能力，地圖能力，支付能力，各個外部開放平臺開發的各類內容提供服務能力引入等。對於外部服務能力的引入建議是要在技術平臺層單獨進行管理和封裝，即在技術能力層有獨立和統一的服務代理。

最後是數據庫和持久化層，包括常見的關係數據庫，半結構化和基於key-value的redis，mongoDB等數據庫，還有就是徹底基於hdfs的非結構化文件存儲能力。對於不一樣的業務場景和業務對象，每每須要底層不一樣的數據和存儲能力進行支撐，如何造成一個完整能力的數據庫服務能力層是架構設計時候須要考慮的。

去IOE化

對於去IOE化是這兩年互聯網架構設計談得最多的問題，即去掉小型機，集中存儲和商用數據庫。若是簡單來講下去IOE化的核心就是基於開源的相似Mysql數據庫和集羣技術，經過X86服務器硬件資源來實現和原來使用IOE架構時候一樣的性能和高可用性。在以前淘寶有開源的corba基於mysql數據庫來實現分佈式數據庫和集羣，如今有開源的MyCat來實現，核心就是提供一個DaaS服務層和封裝，來實現高性能和高可用的數據庫中間件產品。

對於去IOE的熱度在當前已經有所降低，這裏面有兩個緣由一個是自己技術成熟度和CAP原則約束，一個方面的緣由就是在去IOE和引入DaaS數據庫中間件後自己是增長了架構複雜度和應用開發難度。一個方面是因爲DaaS層引入導入的分佈式事務問題和對於跨庫查詢和Sql語句自己的約束增長。一個是在架構設計中就須要考慮前端業務如何進行組件化，業務對於的數據存儲如何進行分區和分片，究竟如何進行水平拆分和垂直拆分。

能夠講在架構設計中的去IOE設計和前面講到的組件化和服務化設計思路密不可分，同時在去IOE下的組件化是完全的組件化，即組件自己對應的數據庫也是獨立的，組件能夠擁有徹底獨立的硬件資源和全生命週期管理。所以若是組件沒有劃分，在後期業務功能實現中就可能致使大量的跨庫操做和分佈式事務問題。這些都應該在架構設計階段就思考清楚並制定清晰的架構設計約束，任何架構設計都不會有普適性的通用架構存在，架構約束定義是一個架構要發揮其高效能力的關鍵。

去中心化 首先來看一個最簡單的場景，即客戶和請求端是A，服務提供端是B，對於服務提供端已經實現爲了分佈式集羣即(B1,B2,B3...Bn)，在這種場景下能夠看到對於請求會轉發不一樣的集羣節點進行處理。可是對於這種分佈式架構來看，集羣是能夠徹底平滑彈性擴展的，可是問題關鍵點在於A的請求究竟應該轉發到哪一個B節點去處理，這裏面就有一個控制層或管理節點，而對於大多數分佈式應用來說管理節點自己是很難集羣化擴展的。及時當前不少分佈式架構實現過程當中已經實現了消息請求和數據傳輸的分離，可是仍然存在對於管理節點沒法水平擴展的問題。 對於水平彈性擴展問題的解決，每每會引入集羣技術和硬件負載均衡，可是這不是一個徹底意義上的去中心化架構，當前咱們說的去中心化架構都是沒有統一的管理節點，徹底分佈式，只有在這種架構下才是徹底的去中心化。要作到去中心化就涉及到幾個關鍵點的引入，一個是請求經過sdk包在客戶端的植入進行前移，即客戶端發起請求的時候就已經判斷清楚；其次是對於管理職責後移，即管理端後續重點是從各個集羣節點準實時採集數據再進行分析。要實現第二點每每又涉及到高性能的消息中間件的引入。

做者：何明璐 連接：http://www.zhihu.com/question/19841397/answer/13707640 來源：知乎 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。