前段時間剛剛看完了《Microsoft .Net企業級應用架構設計》一書，以後陸續的分享作者在書中的精華，簡明扼要的進行總結和概述。同時這本書推薦給有興趣的童鞋。

軟體架構到底是什麼

每次遇到軟體專案時，我們都會建立一個解決方案。這個過程就叫做架構設計，而架構設計的最終產物就是軟體架構。在軟體領域，架構就是指為客戶構建系統。

軟體架構分為隱式和顯式兩種。隱式架構可以看作是一系列原有經驗，其他類似專案中學到的技巧以及將抽象概念進行組織並應用到手頭的能力。若專案干係人（專案干係人的定義是所有對建立系統感興趣或關注的人，包括系統的建立者架構師、開發人員、測試人員、以及產品接受方、終端使用者、分析師、審計人員、資訊長等。）想法過於精細，以至於無法用經驗和頭腦中的想法來處理，則需要用顯式架構。

優秀的架構

軟體架構的關鍵點是軟體應該符合專案干係人的期待。期待可以分為功能性和非功能性需求兩種。若想讓軟體系統滿足目標，我們必須遵守一種架構上的約定。這個架構的約定就是你要認識到無論對於何種系統，一些重要的決定必須在開發的初期確定，如同在城市的規劃建設中一些關鍵決策一樣，例如，不能在應該造橋的地方建造摩天大樓。軟體系統必須著眼於系統的組織以及系統基礎設施的分佈，隨後即可對系統進行設計和描述。設計需要在早期作出一些重要決定，而描述系統則需要給出多角度下系統的樣子，每個描述都會覆蓋到系統的一些職責。

系統不能脫離上下文，且上下文也通過開發以及操作上的決策影響系統的設計。系統是為了解決問題並滿足專案干係人要求而存在的。專案干係人的要求分為功能性（功能性需求是指系統需要做的事情，即系統需要為完成特定的任務和達到使用者的目的提供那些功能，並且這個軟體需求必須“清晰、正確、避免二義、明確且可檢驗”）和非功能性（非功能性需求是指那些最終系統整體上的需求，但這些需求並不屬於功能方面）兩種，以及諸如安全性、可測試性、效能、可靠性、和可擴充套件性等其他方面。

架構的核心在於其包含的元件和型別，以及最終對映成的二進位制檔案、相互的關係和依賴、使用場景和關鍵操作的操作流程。描述架構的最流行的方法就是使用UML圖表。通過UML的一系列使用，即可對架構進行不同角度的描述，並抓住其核心部分。

什麼屬於架構，什麼不屬於

在設計架構之初，最需要明白的是什麼屬於架構，什麼不屬於！很多系統都會被設計成一系列的元件，元件與元件之間有著不同的通訊方式和依賴關係，所以首先我們要不斷的拆分各個子系統通訊的過程，最小化系統的結構和關係。其次我們需要定義結構和現實之間的邊界，這個過程非常重要，邊界定義了開發團隊中不同成員的職責，也就是給出了架構師和開發者之間工作的區別。在得到了一個個封裝了特定行為的黑盒以後，我們也就達到了架構和現實之間的邊界，封裝特定行為的黑盒是一小段功能，其實對其重構也不會對整個架構傷筋動骨。而在封裝特定行為的黑盒之上，應該是架構相關的內容，這可能屬於預先定義的、不會輕易改變的決定。最後就是處理不會輕易改變的決定，一旦進入開發流程，軟體系統中總有一些方面和功能不會輕易改變，若你發現有些東西比你想象中更加易於改變，那麼它就不再屬於架構了。

在架構過程中，架構師的主要職責是接受需求、拆分系統、確定並評估技術以及編寫詳細說明書。

1.接受需求：在一個軟體專案中，有幾件事情在架構師參與之前就開始做，很多分析師，IT專案經理，和主管人員聚在一起，開會、討論、評估、並協商，隨著版本的更新和資金到位，分析師會根據其對業務、公司流程、上下文、以及終端使用者反饋的瞭解來編寫需求。完成需求後，會將該需求對架構師交付，架構師將接受需求，隨後努力讓其可以實現，並給出設計。

2.拆分系統：拆分系統時架構師需要評估各種架構模式，分層是其中最常見的，分層能夠將功能按照水平方式拆分開。分割槽則是另一種技術，所有的部分都在同一個邏輯層次上，圍繞著一些共享的實體。最紅產生的結構必須滿足通用的指導規範，而最終的架構同時也由一些非功能性決定，例如安全性、可伸縮性等，這些都會影響和約束架構師在設計解決方案時的選擇。

3.確定並評估技術：初步確定了架構接下來確定並評估技術，需要注意的是架構師並不選擇技術，只是根據其掌握的技術給出提議。那麼誰決定最終使用哪項技術、哪個產品呢？一般來說，這是由專案經理或者管理預算的人決定的。架構師的提議可能會被接受，也可能會被拒絕。

4.編寫詳細說明書：架構師最終負責系統的開發，在這個過程中，架構師需要與開發者溝通，也需要與專案經理和分析師溝通，或許還要和使用者溝通。因此架構師很重要的一個技能就是語言要明確清晰。（突然感覺架構師是一個比開發更苦逼的位置）

ps：微軟公司定義了四種架構師：企業架構師、基礎架構師、特定技術架構師、解決方案架構師。從文字表面即可看出特定所指，不做解釋。

軟體開發模型

在開始軟體專案之前，首先應該選擇一種適合專案，且能夠配合專案相關人員水平和態度的開發方法。一個軟體開發方法就是一系列應用到軟體開發過程中的最佳實踐。軟體開發方法能夠幫助人們管理並實現專案。

談到最佳實踐，讓我想到《黑客與畫家》一書中充滿諷刺的一段描述：【在大型組織內部，有一個專門的術語描述這種跟隨大多數人的選擇的做法，叫做“業界最佳實踐”。這個詞出現的原因其實就是為了讓你的經理可以推卸責任。既然我選擇的是“業界最佳實踐”，如果不成功，專案失敗了，那麼你也無法指責我，因為做出選擇的人不是我，而是整個“業界”】。

言歸正傳。當前存在兩種主流的開發模型：傳統模型和敏捷方法。當然，現在很多團隊都宣稱自己是敏捷開發，到底是不是，天知地知，他自己知。

瀑布模型是最被人們熟知，也是最傳統的方法。瀑布模型的設計理念和城市規劃一樣。也就是說在開始編寫程式碼之前，設計必須全面完成，且不能更改。瀑布模型是一種簡單且紀律性強的方法。對於一些絕大多數專案而言，有些不切實際，因為你幾乎不可能在專案開始就得到所有的需求，並且還會發生一些不可避免的情況。考慮到這些，瀑布模型多年來有一些改進，其中設計和實現這兩個步驟有著一部分的重疊。

敏捷方法作為瀑布模型的改進，迭代開發是一個迴圈的過程，它主要強調漸進的方式開發軟體。迭代開發是敏捷開發的基石。敏捷方法中，人是作為專案中最重要的部分。正如敏捷宣言描述，敏捷方法更關注於在一起工作和交流的人。有時客戶和開發者在一起工作，因此敏捷流程就是敏捷的應對變化。

軟體開發中較為流行的敏捷方法就是極限程式設計。Scrum是另一種流行的敏捷方法，不過與編寫程式碼相比，他更加關注於專案的管理，Scrum並沒有限定與之配合的軟體開發模型，卻能夠很好的配合XP來編寫程式碼。

對架構師的誤解

1.架構師等於分析師：架構師也許會參與到專案干係人的討論，但僅此而已。通常而言，分析應該屬於專案領域中的專家。在小公司有可能一個人身兼兩職，也就是說，公司裡的某個人足夠了解業務，還能寫出功能需求並將其轉換成為開發者所使用的詳細說明書。不過兩者的角色和職責仍舊是不同的，雖然這兩種技能可能會同時出現在一個人身上。

2.架構師就是專案經理：架構師負責系統的架構和協調，並在開發過程中提供指導。專案經理作為專案干係人，管理專案的進行。兩者分工截然不同。不過身兼數職也不罕見，這種情況在大公司少見，小公司很常見。

3.架構師從不編寫程式碼：一種看法認為架構師在需要的時候才會出現自開發團隊中；另一種開發是架構師都是天生的開發者。實際上架構是可能不會編寫太多的產品程式碼，但確實會寫很多其他程式碼。在軟體領域中，架構師和開發者的成長途徑十分相似。開發者的經驗越豐富，他就會越喜歡一些設計方面的問題，並有著充分的理由。架構師越是不經常程式設計，就會越加失去他在開發者眼中的威信，這就形成了一個惡性迴圈，但是使用敏捷開發方法，情況就會好很多。

相關部落格：