.NET企業級架構解決方案:架構師和架構
引言
在計算機的早期，大概是1960年左右，硬件的花費在軟件之上，是占主導地位的。40年之后，我們發現情況發生了極大的變化。因為工業的進步，硬件的成本急劇的下降。另一方面，軟件開發的成本因為個性化企業級應用開發的復雜性而急劇上升。對公司來說，便宜的硬件使得為他們的信息系統增加越來越多的功能是值得的。最初一些獨立的系統，相互之間沒有連接，也很少會共享數據，在多年之后，變成了復雜的系統，功能和模塊之間相互連接。
這種情況創造了一個需求，在進行這樣的系統設計的時候，需要一系列的規范來指導工程師。
從建筑行業借用過來，“架構”一詞用來描述計劃、設計、實現軟件系統的技能，是合適的。然而，在軟件開發中，架構不像在建筑行業中需要那么多的藝術性質。設計良好的建筑對眼睛和功能來說，是令人愉快的。軟件架構在主觀方面會少一點。
正文
1、什么是軟件架構
“架構"一詞最初被用于軟件工業中，是表達在進行代碼開發之前需要計劃和設計。但是，在架構一個可用的軟件系統和架構一個適于居住的建筑之間還是有本質的區別的。
很明顯的，在架構建筑的過程中，我們會考慮建筑是否會砸到人。但是在軟件中，通常有大量的金錢可以改寫一個架構。在建筑業中，設計一定要以極其詳細的計算和藍圖為基礎，才能完成。在軟件開發中，你可能會傾向于更加敏捷。在十幾年前，預先設計的方法在軟件行業也是非常普遍和流行的。但是，十幾年過去了，這種方法增加了開發成本。因為在部署之前，軟件可以進行高效和安全的測試，相比預先設計，敏捷占了上風。
今天，建筑行業的架構和軟件行業的架構已經不像很多年前那么相似了。在很多字典中，軟件架構被描述為：在一個計算機系統中，組合、整合、多個組件之間的聯系。但是，他還是比較抽象的。
軟件行內人通常會接受另一個解釋：將系統分解為很多小塊，然后放在環境中。
2、誰是架構師
架構設計基于對需求的分析。分析可以確定系統需要做什么，架構可以確定如何做。架構師是需求和詳細設計之間的紐帶，但是架構師的職責是什么呢？需要哪些技能呢？
2.1架構師的職責
根據ISO標準中定義，架構師是對系統架構負責的人、團隊或者是組織。架構師與分析人員和項目經理相互配合，對系統評估和提出建議，協調一隊開發人員。
架構師參與開發的整個過程，包括分析需求和架構設計、代碼實現、測試、集成和部署。
主要的職責包括：
1）理解需求
在軟件項目中，在架構師參與之前會發生一些其他事情。一群分析人員，IT部門的管理者，行政部門會開會、討論、評估、商量。一旦一個新系統的需求被確定下來，預算到位，分析人員就會基于自己的業務知識、企業的流程、環境和終端用戶的反饋引出典型的需求。
需求列表準備好之后，項目經理就會和架構師碰頭，將需求交給架構師，“這就是客戶想要的，你去構建一下”。
架構師理解需求，盡力在設計中滿足和采納它們。
2）分解系統
在需求的基礎上，架構師將系統分解為多個子系統。在這種情況下，架構師會展望一下邏輯層和服務層。然后基于環境，確定層之間的接口，和其它層之間的關系，系統需要的服務級別。
整體設計與企業的目標和需求保持一致。在一些特殊地方，由需求來驅動整體設計，而不是整體設計領導需求。
架構會包括一些通用的指導原則，要求最小化模塊之間的耦合，保持模塊的高內聚，保證每一個模塊有一個清晰的職責。
架構的結果還會滿足一些非功能的需求，例如:安全、伸縮性。最后架構師還會指定一些戰略性的東西，例如：每一個開發者的任務、或者是團隊的任務，或者是子系統的組件。
3）確定和評估可用的技術
在理解了需求和設計了系統的層次之后，下一步就是用具體的技術和產品計劃邏輯組件。架構師應該清楚和項目有關的產品和技術的成本和好處。架構師推薦一些對于項目來說，性價比較高的產品和技術。架構師不決定技術，只是以自己的知識為基礎，推薦技術。
那么誰來決定使用架構師推薦的那種技術呢？顯然是項目經理，或者是預算的管理者。架構師的建議可能被接受或者被否決。
4)明確詳細設計
架構師最后的職責就是確定詳細設計，詳細設計是架構師和開發者進行交流的結果。詳細設計可以以多種形式存在，UML圖、文檔、Viso圖，甚至是原型。溝通對于一個架構師來說是至關重要的。溝通發生在架構師和開發者之間，也發生在架構師和項目經理以及業務分析人員之間，但是不是和用戶。對架構師來說，一個良好的技術就是語言清晰。
結論
架構是一個被廣泛使用的詞匯，擁有相當多的定義。
架構設計從功能和非功能需求出發，功能由業務分析員收集，架構師理解。
原文標題：用微軟.NET架構企業解決方案 學習筆記（一）
鏈接：http://www.cnblogs.com/virusswb/archive/2010/08/05/architecture-microsoft-net-solution-1.html
【編輯推薦】
