737
《Microsoft.NET企業級應用架構設計（第2版）》——1.2 誰是架構師
本節書摘來自異步社區《Microsoft.NET企業級應用架構設計（第2版）》一書中的第1章，第1.2節，作者： 【意】Dino Esposito（埃斯波西托） , Andrea Saltarello（索爾塔雷羅）著，更多章節內容可以訪問雲棲社區“異步社區”公眾號查看
1.2 誰是架構師
如你所見，架構通常是關於難以更改的決定。需要有人做出這些決定。
架構設計基於需求分析。分析確定係統要做什麼；架構決定如何去做。需要有人了解這個“什麼”來確定這個“如何”。
架構師正是把需求和規範關聯起來的專家。但架構師的職責是什麼？需要哪些技能？
1.2.1 架構師的職責
根據ISO/IEC 42010標準，架構師是負責係統架構的個人、團隊或組織。架構師與分析師和項目經理互動，評估和提議係統方案，以及協調開發團隊。
架構師參與開發流程的所有階段，包括需求分析和架構設計、實現、測試、集成以及部署。
具體而言，架構師的主要職責是：確認需求，把係統分解成更小的子係統，識別和評估技術，以及製定規範。
1．確認需求
在軟件項目裏，有些事情是在架構師參與進來之前發生的。一群分析師、IT經理以及高管見麵、討論、評估以及談判。一旦確認新增的或者更新係統的需求，而且也有預算，分析師就會引出需求，這通常基於他們對業務、公司流程、環境以及最終用戶反饋的了解。
當需求列表準備好時，項目經理通常會與架構師見麵，交付一堆東西，然後說：“這是我們（認為我們）想要的，現在你來構建它。”
架構師確認需求，盡力在設計裏采用和滿足它們。
重要：
剛剛我們提到另一個角色：項目經理。項目經理這個角色在不同公司可能有不同定義。我們認為這個角色負責選定方法學，安排工作，跟蹤進度，回報情況，以及充當技術人員和業務人員之間的有效橋梁。充當這個角色的人與充當架構師角色的人可以是同一個人。當這種情況發生 時——而且並不罕見——需求就會從領域專家直接流向開發團隊。如果中間有其他人，就會出現領域知識存在誤差的風險，就像那個兒童遊戲，一個孩子在另一個人的耳朵裏小聲地說一個詞。第二個孩子告訴第3個，如此類推，直到無法猜到原詞是什麼為止。因此，通過統一語言表達的需求不經過中間渠道或隻經過直通渠道（pass-through layer）從領域專家流向開發團隊的過程非常關鍵。
2．分解係統
根據需求，架構師把整個係統描述成在進程裏運作的更小的子係統和組件的組合。在這種情況下，架構師構想邏輯層、服務，或者兩者都有。然後，根據環境，架構師決定各層的接口，與其他層的關係，以及係統所需的服務級別。
注意：
在這個階段裏，架構師評估各種架構模式。邏輯層是一個常見的選擇，也是貫穿本書的一個選擇。邏輯層要求垂直分布功能。分區（partitioning）是另一種方案，所有部件都在同一邏輯層次上，分布在一些共享實體（如對象模型或數據庫）周圍。麵向服務架構（SOA）和六角架構（Hexagonal Architecture，HA）等模式傾向於讓組件（SOA裏的服務，HA裏的適配器）在同一邏輯層次上運作和交互。微服務是另一個新近的架構模式，它的核心概念是專門和獨立的組件。
整體設計要與企業目標和需求保持一致。特別地，整體設計是由需求驅動，而不是驅動需求。
理論上，產生的架構受到一般原則的啟發，比如說，降低組件之間的耦合性，提高組件內部的內聚性，以及賦予每個組件一組清晰的職責。
產生的架構也會受到非功能性需求的驅動，比如說，安全、可伸縮性，以及允許或禁止的技術。所有這些方麵都引入了進一步的限製，在一定程度上界定了架構師可以尋找解決方案的範圍。
最後，架構師也會製定策略，根據係統的布局把每個組件的開發任務分配給個人開發者或者開發團隊。
重要：
軟件架構沒有絕對真理。沒有數學規律（或者建築工程裏的建築條例）可以幫你做出選擇。X公司可能發現A架構很成功，與此同時，Y公司卻拋棄了它，采用B架構。事實上，兩個都可能完全正確。上下文才是王道，要相信直覺。
3．識別和評估技術
確定需求並設計係統的各層之後，架構師接下來需要把邏輯組件關聯到具體的技術和產品。
架構師通常了解可能與項目內容有關的產品和技術的代價和好處。架構師推薦使用的任何技術和產品都是他認為對項目有利和劃算的。
架構師沒有選擇技術，隻是根據自身技能提出建議。
架構師可能會建議使用Microsoft SQL Server 2014，因為它的新的聚集列存儲索引（clustered column store indexes），或者可能選擇由ASP.NET Web API後端支持的單頁Web應用程序。類似地，架構師可能會提倡使用本地NoSQL文檔存儲而不是某種雲端表存儲。
誰對使用哪些技術和產品做最終決定？
一般是項目經理或者管理預算的人。架構師的建議可能被接受，也可能被拒絕。如果建議被拒絕，那麼使用或者不使用某個產品或者技術就會變成一個新的非功能性需求，它甚至可能對架構產生重大影響。
4．製定規範
架構師最終負責係統的開發以及協調開發團隊的工作。技術規範是架構師與開發者溝通架構決定的手段。
規範可以有多種形式：UML草圖、Microsoft Word文檔、Microsoft Visio圖表，或者可工作原型。
溝通對架構師來說是非常關鍵的。溝通會發生在架構師與開發者之間，也會發生在架構師與項目經理和分析師之間，如果不提用戶的話。架構師需要具備的一個重要特征是語言清晰。
架構師與開發者之間的互動會因為所選的方法學而有所不同。項目經理、分析師和用戶的參與也會因為你所接受的敏捷級別而有所不同。
1.2.2 架構師的角色
架構通常預示了一個被稱為“架構師”的角色。根據ISO/IEC，架構師沒有不同類型。架構師就是架構師。僅此而已。
但是，如果你環顧周圍（以及查看簡曆），你會看到不少架構師的定義。最終，這是一個被過度使用的詞，根據環境、公司，甚至國家，它真的會有非常不同的含義。
1．你知道多少種架構師
在美國，企業架構師（Enterprise Architect，EA）幾乎與應用程序開發毫無關係，因為這個角色的人有90%的時間都在關注與IT相關的業務策略、業務編排以及基礎設施。簡單地說，EA是把業務和IT結合起來的人。這個角色的人選可能對軟件架構知之甚少，甚至對分層架構或DDD一無所知。
在很多公司裏，負責艱難決定以及建議方案和技術的角色甚至不被稱作“架構師”，得到的頭銜可能是首席開發者或者類似的名稱。
因此，你可以找到企業架構師、基礎設施架構師（Infrastructure Architect，IA）、特定技術架構師（Technology-Specific Architect，TSA）以及解決方案架構師（Solution Architect，SA）等稱號。所有這些差異都是某種誤導，因為它們試圖把最終不可分割的複雜角色分解成不同部分。我們認為，它創造了不必要的分類，種下了困惑的禍根——“誰做什麼”場景。
在這本書裏，我們使用ISO/IEC的架構師定義，即“負責係統架構的個人、團隊或者組織”。把這個概念對應到大多數公司就會發現我們所說的架構師是軟件（或解決方案）架構師或者首席開發者。
2．架構師的角色
你可能已經有所了解，但如果你去Microsoft TechEd大會，你會發現架構這邊幾乎沒有關於軟件開發和架構的現實問題的會議。由於這個原因，我們在過去這些年裏提交的大量DDD會議常常被拒絕。除了Microsoft TechEd大會的員工，架構師通常是關注企業架構的角色。而Microsoft TechEd大會上的所有DDD會議都屬於開發這邊！
在同一個項目組裏有多個架構師是沒問題的。同樣地，不同的架構師擁有稍微不同的技能，即使不是最想要的，也是沒問題的。但是，正如我們在本書裏強調的，不管官方頭銜是什麼，架構師與代碼有著密切的聯係。他們構思係統的設計，然後與開發者密切合作，確保恰當實現。
我們認為，除了其他方麵，架構師是一個更好的更有經驗的開發者。我們不相信隻會使用UML和Visio並把實現細節扔給開發者的架構師是有價值的。至少，當遇到這些人時，我們從未發現他們易於相處。
1.2.3 關於架構師的常見誤解
通常，由於架構師這個術語存在各種含義，大量私下的定義和解釋也導致了誤解的增長。下麵來看其中的一些定義，我們也想對它們進行澄清。
1．架構師是分析師
這個說法不實。架構師並不是分析師。
有時候，架構師可能會在捕獲需求的過程中協助分析師澄清複雜的需求，或者清除僅為“完整性”而添加進來的千奇百怪的需求。有時候，架構師可能會與利益相關者會麵。但也僅此而已。
一般而言，分析師是領域方麵的專家。架構師並不一定是這樣的專家。分析師會與架構師分享關於係統應該如何工作以及係統應該做什麼的發現。
這個常見的誤解可能是因為分析師這個詞被賦予了不正確的含義。如果這個詞隻是表明某人對係統做了某些分析，那就很難否定架構師與分析師之間的相似性了。大約30年前，係統分析師這個術語是用來表明在設計係統時做出相關考量的專業能力。但是，那時的軟件並不如今天那麼重要，隻是一個基本上基於硬件的係統的一（小）部分。
今天，分析師與架構師的角色通常被認為是不同的。架構師也很難充當分析師的角色。
注意：
由於角色並不總是嚴格劃分，尤其在小公司裏，同一個人可能既是分析師又是架構師。這隻是意味著這個公司裏有一個人很熟悉業務和流程，可以找出功能性需求，並把它們轉化成開發者可以使用的規範。這些角色和職責仍是不同的，隻不過這些不同的技能恰好體現在同一個人身上。
2．架構師是項目經理
這是另一個不實的說法嗎？看情況而定。
架構師負責係統架構，同時協調和指導係統的開發。項目經理代表利益相關者，通過在一開始選擇開發方法學來管理項目。然後，項目經理負責確保項目在時間和預算都有限的情況下開展時能夠遵循架構。
如果細看架構師的角色和項目經理的角色，我們會發現它們是不同的。僅此而已。
但是，同一個人最後扮演兩個角色也並非罕見。就像演藝界一樣，這種事情很少發生在大公司裏，但經常發生在小公司裏。
總之，如果你以後想成為一名架構師，你不一定要培養項目管理方麵的技能。但是，如果你擁有兩個角色的技能，你可以嚐試拿兩份薪水。
3．架構師從不寫代碼
這絕對是當下熱議的問題：架構師應該寫代碼嗎？基本上有兩派觀點。
一派認為架構師在樓上工作，或許是頂樓。架構師僅在需要通過圖表展示他們對係統的看法時才會走下開發者所在的樓層。完事之後，他們乘坐電梯上去，收拾他們的東西，然後出去打高爾夫球了。到了球場，他們會關閉他們的手機，專心打球。打完球時，如果他們發現一兩個未接來電，他們會打電話回去，向那些愚笨的開發者解釋圖表上已經清楚說明但開發者仍然未能理解的東西。根據這一派的觀點，架構師從不親手敲下哪怕最簡單的C#語句。C#？噢，不，他們接觸過的最新語言，在學校裏可能是Pascal，在家裏可能是Visual Basic。
相反，另一派認為每個架構師本身都是開發者。把這個比喻推而廣之，我們可以說，Architect這個類繼承自Developer這個類，添加了一些新的方法（技能），同時又重寫了（特化）另一些方法。成為架構師在一些開發者的職業生涯裏是很自然的發展。架構師和開發者之間的基本差別是經驗和教育。你可以通過工作積累經驗，可以通過讀好的書和上好的課來獲得教育。此外，與普通開發者相比，架構師有能力從更高的層次看待係統。而且，架構師擁有很好的客戶應對技能。
架構師可能不寫太多產品代碼。但他會寫很多代碼；他每天都實踐編碼；他了解編程語言、代碼技術、庫、產品、工具、CTP；他還使用最新的Visual Studio。在某些編程領域，架構師甚至比很多開發者了解得多。架構師可能會寫工具幫助開發者提高生產力。更常見的情況是，架構師隻是開發團隊的一員。比如說，架構師寫產品代碼在敏捷環境裏絕對是正常現象。在小公司裏，不管選擇哪種開發方法學，這也是正常現象。與此同時，在某些大公司的場景裏，讓架構師寫產品代碼可能非常奇怪，尤其是采用了傳統的非敏捷的開發方法學。
我們兩個呢？我們屬於哪一派？
嗯，Andrea比Dino更像架構師，因為他在5樓工作。另外，Dino更像開發者，因為他寫過好幾本技術含量很高的ASP.NET書，更重要的是，他在二樓工作。但是，我們不打高爾夫球。Dino平時會打網球，而Andrea更喜歡壁球。我們剛被禁止采訪第一派的觀點。
注意：
“設計的人”和“構建的人”之間的區別在軟件領域裏很模煳，沒有其他工程領域和它一樣。這種區別一般是假定的而不是基於公認技能的。
典型的對照物是民用建築。泥水匠具備工程師沒有的獨特技能。但是，沒有泥水匠會質疑設計和計算，因為他們缺乏獨立做出決定的技能。他們盡最大的能力完成自己的工作，完全專注於委派給他們的建築工作。
在軟件領域裏，情況有所不同，因為架構師和開發者有著共同的根源。開發者越有能力，就越覺得自己可以討論設計選擇——通常都有理由。架構師對日常編程越是生疏，就越容易失去其他開發者的尊重。這導致了某種程度上的惡性循環，而當你改用敏捷方法學時，情況又會奇跡般地好轉。
最後更新：2017-06-01 16:01:36