早上醒來打開手機，瀏覽完該看的信息後，隨意點看某脈求職，由於自己定製的都是架構和開發類別，所以看到的招聘幾乎都是架構師職位，薪酬幾乎都在30~50K/月，好是羡慕（幾乎都是招Java架構的......看來還是得加快學習進度，轉型速度要快點）。心想如果自己去面試這些職位時，對方萬一問：“你來應聘架構師 ...
早上醒來打開手機，瀏覽完該看的信息後，隨意點看某脈求職，由於自己定製的都是架構和開發類別，所以看到的招聘幾乎都是架構師職位，薪酬幾乎都在30~50K/月，好是羡慕（幾乎都是招Java架構的......看來還是得加快學習進度，轉型速度要快點）。心想如果自己去面試這些職位時，對方萬一問：“你來應聘架構師，那你來說說什麼是架構？”時，自己要怎麼回答？從而引起來下麵的聯想，哈哈......隨想嘛，所以本篇只討論操作步驟，不談具體的實現細節，將一時的想法記錄一下
什麼是架構？一直以來也將自己定位為架構師（感覺還未真正入門 T_T ），但如果讓自己能以最簡潔的語言來描述它，有說說它具體的工作內容，還真的沒有去認真思考過，只能大概的說個所以然。
架構一直在心裡是一個很抽象的東西，就如下麵描述的這樣：
軟體架構是一個系統的草圖。軟體架構描述的對象是直接構成系統的抽象組件。各個組件之間的連接則明確和相對細緻地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。
架構對於框架來說，它就是繪出好的建築圖紙，它描述建築物的外部形狀、內部佈置、結構構造、內外裝修、材料做法以及設備、施工等各種圖樣。
而在實際工作中，是怎麼去做去執行的呢？在好長一段時間里我都無法將它明明白白的描述出來。只能說是憑經驗，得到一個需求後就知道產品大概要怎麼設計，它要用到那些技術，會大概面臨什麼問題，不同的問題或要求（性能、安全、數據量、併發......）在不同階段要怎麼去設計和用到那些技術，資料庫結構要怎麼去實現，是否需要分庫分表，怎麼設計才更有擴展性，怎麼去解耦，編碼時要用到多少人，這些人大概需要什麼樣的技能，需要多少開發時間，會不會出現延期，萬一延期的話要怎麼處理，測試呢？佈署呢？版本更新迭代？每個階段與其他相關部門的溝通？各種設計、開發、溝通文檔？......
那具體怎麼做呢？
這真不是三言兩語就可以說得清楚的，去書店看著那一本本厚厚的架構設計書籍就知道了。因為針對不同的行業、不同規模的企業、公司技術環境、公司計劃投入的資金大小、職位配備、項目的功能需求、技術人員能力、長短期目標、技術儲備情況、使用的開發語言、資料庫......都會影響架構師的判斷，決定著當前（不是最終哦）使用的技術框架。當然在某些階段也是有相同的地方，過程也大同小異，所以我們討論架構的話，必須有個邊界的限制。
首先，架構師必須瞭解具體的需求
不瞭解具體的業務需求，就沒辦法設計出一個成熟健壯的架構，也無法根據現實的具體環境，去選擇出最適合當前公司或團隊使用的技術架構，而導至各方面成本的增加，過度設計，投入大於產出；又或者產品擴展性不足無法應付業務增長及變化，而最終開發出來的產品也就很難吻合市場需求了。
客戶、市場人員、老闆、運營、銷售、市場、架構、產品......不同的人員對產品都有不同的理解（比如餐飲行業中的：食客、收銀、服務員、點菜、傳菜、選菜、廚師、領班、店長、財務......對店裡用的軟體理解的角度也是不一樣的），且同一個人在不同的場景針對不同的人說的同一句話都有可能意思都不一樣，更何況這麼多不同學歷文化、職位、角色的人，大家對同樣的話語、同樣的描述的理解不同肯定也會產生不同的結果。
所以，架構師首先要做的，是自己去瞭解需求，然後將自己的理解通過使用各種工具將業務需求繪製出來，形成清晰、直觀、容易瞭解的架構方案，和大家對稱對項目需求理解，看看大家理解的信息是否一致，統一思想，防止偏差。
比如：使用UML繪製各種概念模型（用例圖、泳道圖、流程圖、時序圖......）；或是用DDD思想去創建各種領域、子域、限界上下文模型；又或者是用利益相關者的視角去繪製利益相關者視圖、架構分層視圖、業務產品視圖、信息組織結構視圖、業務功能視圖、組織機構視圖、業務流程視圖、應用程式協作視圖......
其次，設計產品，細化各種模型與視圖
當大家對產品的理解統一之後，開始由產品經理來設計產品原型，以及架構師對前面模型與視圖進行細化，形成一份份與技術相關的各種文檔，指導後續工作的開展。
產品原型與各模型是相輔相成的，產品原型是模型的可視化體現，而模型是產品後端複雜的業務實現。
成熟的架構師除了懂得針對需求建立各種模型外，還要懂得從需求與產品中，提煉出成熟的商業模式與盈利模式，一個軟體如果不存在行業價值或商業價值，最終實現盈利，那它也走不了多遠。
然後，根據所在行業、公司、部門等各種綜合情況，再確定使用具體的技術框架
每個行業都有自己的特殊性，在這裡就不進行深入討論了。
而每個公司的資金實力都是不一樣的，技術部分的崗位職位配置也各不相同，使用的技術語言也是各種各樣，再加上技術人員技能水平也是高低有別，所以一套架構可以通吃的情況是不存在的。
資金充沛的土豪公司可以隨意，缺什麼職位就隨便高薪聘請，而用的技術框架也可以直接上高大上的那些組合，不用去考慮開發時間與成本......呵呵，這些對於絕大部分公司來說YY就好了，我們還是要回到現實中來，我們經常會碰到的是資金有限，人手不足，公司使用指定的技術或框架......然後對投入與時間又有嚴格要求，但又想系統開發出來以後系統可以隨時擴展，應付萬一業務做大，高併發、大數據、分散式、可擴展......等都要能對接的上且不用花費太大的成本，呃......
好的架構會對業務發展和技術發展做好提前預判（雖然不一定一直都正確），提前採用適合的性能比最好的技術架構來實現。當然在發展的過程中，如果真的公司業務量起來了，改造也大都在合理的範圍內。在不可避免需要進行大改造時，那也是有選擇有計劃的替換某些模塊。
再具體點來說，就是要使用.net、java、php、pyton還是什麼開發語言，使用SOA架構、微服務架構，還是傳統的軟體架構，軟體框架用MVC、傳統三層、DDD......數據層用EF、MyBatis、Hibernate......其他層呢？使用分散式架構還是一體式？使用消息陣列嗎？匯流排呢？前端框架呢？要考慮客戶端相容什麼版本手機或瀏覽器？安全呢？工作流？數據結構設計？開發模式是TDD/DDD/PDD/敏捷？人員分工安排？開發計劃？開發進度控制？......
跟著才進入具體的開發實現
這部分大家是最熟悉的就不擴展了
最後是測試、部署，產品的迭代
......
當然，並不是所有項目都是按這個順序來執行的，小項目小需求無架構，對於簡單的需求開發一個簡單功能的產品，直接畫個草圖然後碼代碼就可以了，考慮太多反而是過度設計浪費時間。當然架構師也不是萬能的什麼都懂什麼都會，一個人無法完成一個大中型項目的開發，它需要團隊中各個成員的密切配合，一起努力完成。
可以說每個架構師心中都有片森林，清晰的知道設定好目標以後，為了完成這個目標，我們會提前做好全方位的計劃，當然這個計劃不只是技術上的，還會關係到相關部門的溝通與配合，清楚在前進的路途中每一個節點或階段性目標要達到時需要的準備工作與各部門提供的配合工作。然後就是把控好這個節奏，讓產品的大船沿著正確的方向前進，最終到達目的地。
完美的架構師，他是技術總監、系統分析師、架構師、產品經理、項目經理、核心開發、測試人員，他是堵槍眼的角色，那個崗位需要隨時準備頂上的人員。
知識有限對架構師的認識比較淺簿，想到哪就寫到哪，不知這樣認為是否正確，歡迎大家指正。
版權聲明：
本文由AllEmpty原創併發布於博客園，歡迎轉載，未經本人同意必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，否則保留追究法律責任的權利。如有問題，可以通過[email protected] 聯繫我，非常感謝。
發表本編內容，主要是為了和大家共同學習共同進步，有興趣的朋友可以加加Q群：327360708 ，大家一起探討，我們群每半個月會組織一次在群視頻里進行技術分享，有興趣的朋友可以加入進來一起探討。
更多內容，敬請觀註博客：http://www.cnblogs.com/EmptyFS/
