想做架構師？少點幻想！你還有很多要學 - Medium

誠然畫圖是架構師的一項日常工作，但通過一張圖，來道出事物發展的本質， ... 產品經理、或者是客戶，來講清楚某個複雜的商業模式，難度是非常高的。

UpgradeOpeninappHomeNotificationsListsStoriesWritePublishedin數據分析不是個事想做架構師？少點幻想！你還有很多要學|0x00架構思維相信很多人，談起架構，第一印象，就是各種各樣的架構圖，仿佛有一個高高在上的人，坐在那裡，闊談自己的理念。

誠然畫圖是架構師的一項日常工作，但通過一張圖，來道出事物發展的本質，卻是另外一種功夫。

做了這麼多年的程式設計師之後，如果只有打開了Idea才會思考架構，或者是敲起了SQL程式碼才會理解業務，細細想來，只能是自己的功夫不到，理解不透罷了。

架構的第一印象，不應該是多麼流行的技術，或者是多麼麼高效能的框架，而是它能不能滿足業務的需求，既不能跑不動，也不能太超前。

那麼架構是什麼？從理論上講，它描述了系統中不同實體之間的抽象關係。

抽象這件事其實很重要，因為你要跟一個軟體工程師、或者是產品經理、或者是客戶，來講清楚某個複雜的商業模式，難度是非常高的。

這個時候，把商業模式來簡化，抽象成一個個普通的“詞彙”，讓大家準確的理解，能夠進行重新組合，生產力就爆發了出來。

再進一步，軟體過程中的架構，就是兩個目標：「降低系統的熵」、「支援快速擴充套件」。

軟體開發是一件多方合作的系統工程，功能越完善，系統的複雜度就越高，管理的難度越大，出現問題的概率就越高。

如何系統性的降低系統的認知負荷，就是在“降低系統的熵”，對於後續繼續開發的人而言，生產力的提升就越高。

但需求不會是一成不變的，理想的狀態就像是雲服務那樣，不斷擴容就能夠解決一切問題。

因此「元件化」、「微服務」等概念的不斷出現，也是在嘗試為未來不確定的需求做擴充套件上的預留。

架構思維-想做架構師？少點幻想！你還有很多要學架構思維的核心，就是解決複雜性的問題，並在解決的過程中找到平衡點：既要簡單又能滿足發展。

這種平衡的思維絕非一天兩天能夠練就的，生活中也處處存在：如何平衡生活與工作、如何平衡體重與食慾、如何平衡休息與學習…無他，唯手熟爾。

|0x01系統分析能夠對業務有了深入的理解之後，下一步就是要進行系統分析，拆解業務的細節。

系統分析有很多種方式，但總的來說，有兩種最為常用：一種是「自底向上」，一種是「自頂向下」。

「自底向上」指先有具體的問題，然後通過分析來進行抽象。

開發同學在日常的工作中，每天都要與各種各樣的需求打交道，有一些是來自業務方的訴求，有一些是來自於腦暴，有一些是來自於常規功能迭代。

那麼這些需求細節來了之後，我們就需要開始抽象的過程，這是一個嚴密的推導過程，即業務建模+應用邏輯=系統架構。

業務建模通常需要對某個領域的知識積累，多蒐集相關領域的業務知識，通過搭建業界通用的最小業務單元，一步步向上推導頂層結構，對於業務建模幫助很大。

另一部分就是應用邏輯，例如面向物件設計方法，提煉出可複用的模組及穩定的依賴關係，這部分取決於開發人員的經驗積累。

「自頂向下」是指先有抽象的概念，再一步步拆解到具體的做法，這種推導方法依賴於「準確的定義問題」。

通常而言，有這麼幾個階段可以參考：準確提出問題—設想需求疑問—與需求方進行對話—提煉新的需求疑問—繼續與需求方對話。

這是正常人的思維：系統分析-想做架構師？少點幻想！你還有很多要學這是金字塔的思維：系統分析-想做架構師？少點幻想！你還有很多要學“腦子想得通，說話才能說通，說話說得通，做事才能做通。

”我們在設計架構的時候，通常都是直接從產品或者業務方面拿到的需求，在對問題進行逐層分解的過程中，有一些環節能夠直接定義成技術問題，但總有一些特定的功能需求，是通過業務語言描述的，這部分需要進行重新對話確認後，轉化為技術問題。

最終將一個大的需求，拆解成若干的技術子問題，完成架構的「自頂向下「推導。

|0x02架構設計目前比較主流的企業架構理論是“TOGAF”，大約有80%的福布斯全球排名前50的公司在使用，國外有SAP、IBM、HP、Oracle等公司在推動。

架構設計-想做架構師？少點幻想！你還有很多要學架構設計-想做架構師？少點幻想！你還有很多要學用了理論指導，接下來就開始簡述一下日常的工作流程：設計工具：「工欲善其事，必先利其器。

」架構如果沒有工具來輔助思考的話，就太難了。

在系統設計上，首推UML統一建模語言。

UML最大的特點，就是對於不同的領域，其所採用的本質元素是相同的，大家能夠基於共同的“模型”來理解業務、需求。

需求分析：需求分析階段，首先要進行利益分析，尤其是在面對多方向的業務方交付，就要抓住系統最主要的受益者，做好牽頭的利益分配；其次做好資源評估，包括了人力和機器資源；再次整理需求規範，這一步是面向技術人員的，通過一系列的規範來保障開發人員的理解能夠精準匹配業務方的需求。

模型建立：建模的目的是通過構造簡單的模型，來替代複雜的業務現實。

建模方法有很多種：領域驅動（DDD）、用例驅動（UDD）、四色建模法，等等。

建模的過程讓那個需要用到領域對應的知識，比如許可權、人群、活動等，用於匹配具體的業務過程：授權、圈選人群、營銷規則等。

通過建模方法，對具體的領域知識進行消化，我們就可以輸出最終的領域模型圖。

架構輸出：這一步主要包括了方案描述、設計約束、技術選型、系統結構、資料設計等部分。

最終我們能夠確定技術的大致架構型別，比如分層架構（MVC）、微服務架構、雲原生架構等。

|0x03架構落地剛才寫的過程看起來平淡無奇，但都是前人們對於軟體開發經驗的高度總結，都是精華。

而將這些大道至簡的道理，濃縮成一條條原則，用於指導技術人員的日常開發設計，使我們不論面對多麼複雜的軟體系統，都能夠處理的遊刃有餘，則是架構能夠真正落地的基石。

大家日常所熟知的設計原則，也稱之為SOLID原則，主要有五類：S-單一職責：改變類的原因只有一個。

即每個類只做一種型別責任，當這個類有多個責任的時候，要將類分解。

O-開閉原則：對擴充套件開放，對修改關閉。

L-裡式替換：子類儘量不要覆蓋父類的方法，子類可以擴充套件父類的功能，但不能改變父類原有的功能。

I-介面隔離：使用多個專門的介面比使用單一的總介面要好。

D-依賴倒置：高層模組不應該依賴於底層模組，而這都應該依賴於抽象，即抽象不應該依賴於細節，細節應該依賴於抽象。

|0xFF架構師說到最後，我們來講一下架構師最重要的技能：權衡與學習。

既需要滿足未來的發展，又要避免過度設計。

例如在資料開發中，實時的意思並不一定意味著一定要使用實時計算的框架，通過OLAP引擎提升查詢速度，或者是15分鐘/30分鐘更新資料，同樣能夠滿足大多數感官上的“實時計算”。

對於架構師而言，提升對於技術的思考能力，以及相應領域的解決方案理解，是最底層的能力，即便是純框架，或者是純架構相關的開發崗位，也越來越強調要貼近業務了。

在平時大量的業務開發過程中，最大的難點永遠是兩個：一個是邏輯的複雜性，一個是需求的變化性。

很多時候，帶著問題主動去思考，客戶是誰？訴求是什麼？有沒有更好的方案？經過長時間的刻意訓練，能力的提升也就是自然的事情了。

版權宣告：本文為Leo.Yuan原創文章，遵循CC4.0BY-SA版權協議，轉載請附上原文出處連結和本宣告。

本文連結：https://blog.csdn.net/yuanziok/article/details/108791610歡迎按讚我的臉書ITValue研討社，發現更多精彩內容😃偷偷告訴你，私訊臉書小編，關鍵詞【數字化轉型】，即可獲取一份14個行業，240個轉型案例的最全資料包69Morefrom數據分析不是個事分享數據人必備的知識！Readmorefrom數據分析不是個事GetstartedIT公社687Followers基於CIO知識分享的人際圈FollowRelatedIELTSListening — MatchingQuestions.Howtosolveaccurately?CS371pSpring2022:Week8Whatdidyoudothispastweek?CompassionateReflectionandGoalSetting(Part4 — FinalPart)IELTSWritingTask1MapsTipsandTricksMapsareacommonTask1questiontypefortheIELTSWritingExam,whichtestswhetheryoucanunderstandandinterpretdata.Itwouldhelp…HelpStatusWritersBlogCareersPrivacyTermsAboutKnowable