前言

卓越的軟體架構師從何而來?

所有程式設計師都有成為架構師的潛力，只要掌握了架構師的思維方式和工作方法，你也能成長為架構師。

本文教你如何像架構師那樣思考問題、理解需求、設計架構、評估結果、編寫檔案。
本文不但通過真實案例講解架構設計流程和經驗，還總結了豐富的架構師工作原則和技巧，尤其適合廣大程式設計師進階學習。同時也適合產品經理、測試人員、運維人員和其他行業從業者深入理解軟體架構設計工作。
本文將給廣大程式設計師的幫助：

• 成為出色的技術領導者
• 在快速迭代的敏捷開發中開展架構設計
• 避免專案波動和返工
• 帶領團隊共同成長

 

接下來就帶大家一步步來學習本文具體內容講解，希望本文能夠得到大家的喜歡，多多轉發+關注！

目錄

 

主要內容

本文分為三部分。第一部分與第二部分建議從頭至尾通讀，第三部分則便於參考和檢索。

第一部分介紹軟體架構的基礎知識和架構師必備的設計思維。
第1章成為軟體架構師;除了程式設計，架構師還有其他職責。他們要從工程角度定義問題。他們要將軟體系統分解成多個可實現的模組，同時又要兼顧大局、確保系統整體有效工作。他們要在軟體品質屬性(quality attributes，是軟體的非功能性需求)之間進行權衡，並管控不可避免的技術債務。更重要的是，他們要鍛鍊和提升整個團隊的架構設計能力，因為最好的團隊里人人都應該是架構師。

本章講解架構師要做些什麼。你將明白為什麼理解軟體架構可以讓你成為更優秀的程式設計師和技術領導者。我還會介紹如何開始架構師的職業生涯。

 

第2章設計思維基礎;無論是從頭設計架構，還是改善已有的軟體系統，我們需要的架構其實就在那裡，等待我們去發現（ to be discovered，TBD）。架構設計總是一邊摸索要解決的問題，一邊探求解決方案。

為了完成這項任務，你需要學習一種分析和解決問題的創新方法，即以人為本的設計思維。將注意力放在受設計決策影響的人身上，可以幫助你理清必須解決的問題。這種設計思維強調我們的目標是打造幫助他人的軟體，唯其如此我們的方案才能落地。

本章講解如何在架構設計中運用設計思維。我們首先介紹設計思維的四條基本原則，然後學習用思維模式確保架構設計朝著正確的方向前進。最後，學習挑選合適的思維模式。

 

第二部分講解架構師需要掌握的核心技能和知識。
第3章制定設計策略;架構設計很容易陷入混亂無序的狀態。哪怕軟體系統充滿了各種不確定性，我們也必須制訂計劃。凡事預則立，只有憑藉穩固的設計策略，才能應付各種不確定性。

設計思維擅長為複雜問題尋找解決方案，它不是一蹴而就地解決問題，而是強調學習和實驗的重要性。有人認為檢驗架構要先將其實現，但我們的做法是在設計過程中逐步驗證架構的各個部分，同時運用思維模式和TDC 迴圈確定下一步做什麼。

第2章講解了設計思維的基本原則和用法。本章將繼續學習如何根據系統風險選擇思維模式，並將其作為設計策略的一部分。

 

第4章換位思考;搞清楚到底要解決什麼問題，往往是說起來容易做起來難。我們開發軟體是為了服務於人，因此必須理解受軟體影響的人。只有理解他們的需求，才能搞清楚到底要解決什麼問題。

我們把與軟體有關、受軟體影響的人稱為利益相關方（者)。架構師有責任確定利益相關方並瞭解他們的需求。利益相關方對系統的期望將直接或間接影響我們的設計方式。

換位思考( empathy，也叫同理心）是推動設計的引擎。只有站在利益相關方的角度思考和處理問題，才能開發出更好的軟體。本章將學習在開始設計架構之前，如何決定與誰討論你要解決的問題,以及你要從他們身上了解什麼。

 

第5章挖掘關鍵架構需求;關鍵架構需求(architecturally significant requirement，ASR)是顯著影響架構中的結構選擇的需求。架構師有責任確定對架構有重大影響的需求。ASR通常分為四類。

約束:給定或選定的不可更改的設計決策。

品質屬性:外部可見特性，表徵系統在特定環境下的執行情況。
影響較大的功能需求:架構設計需要特別注意的特性和功能。

其他影響因素︰時間、知識、經驗、技術、辦公室政治、你的技術特長，以及其他影響決策的東西。

讓我們仔細研究一下這四類ASR，學習如何與利益相關方合作定義它們。

 

第6章主動選擇架構;所有軟體系統都有架構，但這並不意味著理想的架構會自動送上門來。如果你把設計決策交給命運，沒人知道命運會帶來什麼結果。積極主動地思考和選擇才能提高成功的機會。

架構設計就是在不確定的情況下做決策。決策就是做取捨，我們不得不做一些妥協——放棄一些東西以避免更壞的情況發生，或者接受不好的條件以便在其他方面做得更出色。只要做出合適的取捨，就可以實現關鍵架構需求，幫助利益相關方完成業務目標。本章學習運用關鍵架構需求制定決策，選擇架構的結構。

 

第7章架構模式;數百年來，人們一直在提煉解決常見問題的方案，總結可複用的模式。軟體工程繼承了這一傳統。經驗豐富的架構師熟悉許多架構模式，面對新問題，他們會先回顧自己知道的模式，尋找合適的方案。確定架構模式後再根據實際情況做進一步的調整，以滿足特殊的需求。

所有軟體系統都有自己的核心模式，其他設計決策都以此核心模式為基礎。使用模式相當於汲取前人的智慧,可以大大節省工作量。

已知的架構模式數量成百上千，覆蓋各個領域。本章介紹最常見的架構模式，講解如何讓這些通用模式適應具體需求。

 

第8章建立模型，化繁為簡;再成功的軟體系統也難免走向複雜。使用者數量的增加將給系統的可用性、可伸縮性、效能表現施加前所未有的壓力。新功能不斷插入，修補程式越來越多，讓軟體越來越笨重。擴充套件系統的任務可能壓得開發團隊喘不過氣。如果不保持警惕，軟體系統最終會成為其自身成功的受害者。

當然，複雜性剛剛露出猙獰面目時，我們還是有辦法控制的，比如通過需求變更和程式碼裁剪精簡系統，將大件拆分成容易分析和管理的小件，還可以從細節中抽身出來，從更抽象的層面重新思考軟體。

我們曾說過，架構是由結構組成的，而結構又是由元素和關係組成的。本章將學習使用這些基本構件建立有意義的模型，幫助我們分析、構思、推演我們的設計。

 

第9章召開架構設計研討會;本章學習籌劃和主持架構設計研討會。讀者將學習如何主持設計研討會。良好的主持不僅僅是舉止得當，更要讓討論順利開展。本章講解的方法將有助於提高研討會的效率。

 

第10章展示設計決策;分享設計想法的最佳方式是把它展示出來。光憑嘴說，別人可能很難理解你的思路。把架構畫出來，大家就能按照自己的節奏和方式來琢磨。開發人員都清楚，討論抽象想法最好找一塊白板，畫點草圖。把想法畫出來才能保證大家的理解是一致的。

架構圖沒必要畫得很精緻，只要能夠有效表達想法就行。第8章曾講解過通過建立準確的模型來推演架構，提升品質屬性。本章將學習繪製架構圖，以便與開發人員溝通。

 

第11章描述架構;大家都不喜歡寫架構檔案，它佔據了寫程式碼的時間，而且看起來總是過時的。另外，檔案格式常常很怪，編輯起來很麻煩。最重要的是，沒有人願意讀!難怪有人說軟體架構描述（縮寫SAD)是一個悲劇。

糟糕的架構描述著實讓人難受，但出色的架構描述卻能向團隊展示清晰的願景。優秀的架構描述是有用的資產，它能促進溝通與共同作業，將設計決策和思想有效傳遞給每一個人，提高軟體開發的品質。

本章學習描述軟體架構，用人性化的、簡潔的形式向受眾展示確切的資訊，讓大家愛上它。愛是一個帶有強烈情緒的詞，但我保證讓人們愛上架構描述比你想象的簡單。

 

第12章架構評估;對學生、家長、老師來說，成績單是重要的反饋渠道。學生不必等到年底才知道自己的課程是「過了」還是「掛了」——通過每個季度的成績單，就能判斷自己是否獲得了理想的成績，以及哪些地方需要改進。架構評估的作用就像成績單一樣，它讓我們儘早發現問題，從而按計劃交付系統。

架構評估可以提高開發效率，而不是單純地佔用程式設計時間。順利的話，架構評估一小時就可以完成，它很容易融入現有開發流程中，而且不需要團隊成員掌握什麼新知識。

本章將學習對架構進行評估。評估結果可用於指導團隊、為設計決策提供支援、降低交付風險、提高架構設計水平。

 

第13章鼓勵團隊參與架構設計;開發現代軟體系統需要藉助團隊的力量。科技進步（容器技術、雲設施等）賦予了開發者更大的靈活性和權力。隨之而來的新架構模式(微服務、FaaS等)則對開發人員提出了更高的要求。他們必須清楚自己的決策會對包括品質屬性在內的系統特性造成什麼樣的影響。

在現代軟體開發中，開發人員與架構師的角色幾乎沒有差別。這並不是說現代軟體開發團隊不需要架構師，而是說我們需要的不再是那種傳統的、居高臨下的技術領導者。

今天的架構師應該與團隊一起設計架構，而不是獨自為團隊設計架構。架構師應該既是技術專家，也是教練和導師。本書前兩部分講解了架構設計的核心原則和方法。現在，你要學習讓團隊與你一起成長，共同設計出色的軟體架構。

 

第三部分討論一系列實用的架構設計方法。世上沒有萬能鑰匙，每位軟體工程師都有自己的一套經驗、方法、技術。第三部分將介紹我自己的經驗、方法、技術。
第14章理解問題的常用方法;理解模式要求我們主動從利益相關方處獲取資訊，用於定義(或重新定義)問題。不僅要理解需求，還要理解誰是利益相關方主體、理解系統的業務目標，同時開始構思如何設計架構滿足需求。

第5章曾提到四類關鍵架構需求.這幾類需求都會對架構產生影響，而品質屬性的影響最大，是架構中的關鍵問題.

約束給定或選定的不可更改的設計決策。

品質屬性外部可見特性，表徵系統在特定環境下的執行情況。影響較大的功能需求架構設計需要特別注意的特性和功能。

其他影響因素時間、知識、經驗、技術、辦公室政治、你的技術特長，以及其他影響決策的東西.

本章介紹的方法能夠讓開發團隊與利益相關方相互理解，從而挖掘出關鍵架構需求。如果你需要更好地理解問題，不妨試試這些方法。

 

第15章探索解決方案的常用方法;探索模式可以幫助我們發現各種解決問題的設計理念與工程方法。架構探索關注的是受架構控制的部分─—軟體。我們並不是總有機會選擇解決什麼問題，但至少可以選擇怎麼解決。解決方案只受我們的知識、創造力、技能的約束。

探索似乎是沒有邊界的，但設計總是在前人的基礎上開展的，設計思維的四條原則之一是善於借鑑（見第2.1節)。所有設計都是在已有設計基礎上的重新設計和調整創新，探索首先要從這些已知的設計開始(比如第7章介紹的架構模式)。

架構師不僅是設計師，也是工程師，所以我們還要探索另外一些領域。比如軟體的構建方法、已有的框架、經驗法則，它們也會對架構產生影響;還有問題領域的概念和知識，這些是構思解決方案的出發點。當然，還要探索架構元素的關係和功能。

本章介紹的方法將幫助你構思各種架構設計方案。從這些方案中選擇合適的架構，並找到相應的開發方法。

 

第16章展示設計的常用方法;介紹架構光靠嘴巴講是不夠的，應該設法展示出來。展示模式把抽象的想法(如設計概念)轉變成可感知的物件，方便分享。將設計展示出來不但可以促進交流，而且可以用來檢查設計能在多大程度上滿足需求。設法展示的過程也是推演架構的過程。即使只是製作設計草稿，也是一種有用的思維練習。

除了畫線框圖，還有許多方式展示架構設計，比如製作原型、編寫檔案、開展實驗、比較資料、講故事，甚至表演。這些都可以用來向他人展示架構設計，而且效果都比單純的語言交流更好。

本章介紹的方法將幫助你展示架構設計。你可以按照這裡介紹的方法自己動手，但我建議你與他人一起合作，那樣會更有趣，效果更好。這些方法的耗時一般不會超過30分鐘。

展示的目的是分享，所以要請團隊成員（或利益相關方）評估你製作的展示物。他們應該知道你希望展示什麼樣的想法。評估也是檢查你對問題的理解是否與架構設計一致的過程。第17章將介紹常用的評估方法。

 

第17章評估設計方案的常用方法;評估模式幫助我們檢查設計決策，確定它們滿足需求的程度。設計不必追求完美，但至少應該夠用。我們的目標是找到夠用的架構，滿足需求。解決方案只要夠用就是合適和恰當的。

評估可以幫助我們發現不夠用的架構部分。我們也許會發現自己對細節的理解還不充分。也許看起來不錯的設計卻有著不可接受的弊端(忽略了重要的約束，或者引入了過多的風險)。這種事知道得越早越好。越往後，修改決策的代價就越高。

評估結束後，我們應該有充足的資訊來決定下一步採用哪種思維模式。TDC迴圈（見第2.3節)的檢查階段當然需要用到評估模式，思考階段同樣也需要。

評估應該是一項持續開展的活動。等到設計結束時才做評估，很可能為時已晚。因此每一步工作都應該做評估。這樣，只要我們認為某個部分的架構設計是恰當和合適的，就可以進一步完善它的細節。架構的所有部分在開始構建之前都應該準備充分。

本章介紹的方法可以幫助團隊深入瞭解架構，收集採取行動所需的資訊。這些方法既可以用來驗證假設、選擇設計方案，也能幫助你決定下一步要做什麼。

 

這份【架構師修煉之道】總共有313頁，如果需要完整版的小夥伴，可以掃碼來獲取！！

本文的目標讀者

本文是寫給所有曾站在白板前畫方框和線條，試圖解決棘手問題的人看的。如果你是軟體架構設計新手，本文很適合入門學習。我們將從介紹基礎知識開始，由淺入深逐步講解優秀軟體架構師必須掌握的核心技能。

如果你是對架構設計略知一二的程式設計師，本文將有助於你整理思路。你會讀到那些你既陌生又熟悉的概念，填補你自己都未曾意識到的知識空白。讀完本文，你將更加深入地理解架構師的工作，以便日後更好地領導他人。

如果你是久經沙場的軟體架構師，本文將教你從一個全新的視角來審視如何領導團隊。
今天，越來越多的初級程式設計師希望在軟體開發中發揮更大的作用。文中講解的基礎知識將幫助你引導他們全面地參與到設計過程中來。

本文闡述的共同作業設計方法可以讓你安全高效地與經驗不足的團隊成員進行合作。

希望本文能夠幫助到大家的學習，讓大家快速成長為架構師，也希望本文能夠得到大家的喜歡！！