资深架构专家聊架构之道：规划、简化和演化
李曉時，超過 20 年 IT 行業經驗；資深架構專家，《架構寶典》聯合作者。
1
? ?
引言
大家好，我是李曉時，架構這個概念，和計算機科學（包括近幾年才成為一級學科的軟件工程）的其他術語類似，都是從傳統學科借用來的。這是因為計算機科學太年輕、發展太快，來不及形成自己特有的術語和名詞。因此，在學習和思考方法上，常常推薦類比法，嘗試用一些耳熟能詳的事物去理解和解釋計算機科學領域的概念，以求“老嫗能懂”的效果。
這里介紹的一些內容，大多是個人在學習和實踐過程中的一些思考和體會，以及平時的一些學習筆記整理而成，還很不成體系，還有很多需要繼續推敲的地方。我會在未來的工作實踐中更加深入思考，廣泛參考領域內的成果，力求概念準確，容易理解。也歡迎各位同行專家不吝賜教。
2
? ?
什么是架構
關于架構概念的學習和理解，我建議從 2 個方面入手：
第一、這個概念來自于建筑工程領域，要深入準確地理解，需要看一些建筑方面的資料，比如我會看梁思成《圖像中國建筑史》手繪圖，從中體會什么是架構；我也會到建筑工地去看建筑施工的一些情況；還會在旅游時有意識地關注不同樣式的建筑，體會其架構的不同?！敖ㄖ悄痰囊魳贰?#xff0c;我們要試圖體會架構之美。
第二、對于計算機科學與工程實踐中總結出來的一些架構，我們要通過實踐來學習和領會。比如對于 MVC 架構，我們是否聯想到用 VC++編程時 “ Document/View ” 模型？比如說到三層架構或者多層架構，我們是否考慮到與 “ Client/Server ” 二層架構的關系。
2.1
? ?
架構工作可能是隱式的
架構工作，不管有沒有架構師被指派，其實都是會做的，只是有些時候，架構工作被做了，但沒有人意識到。
有明確的架構師，可能會使架構工作更加專業化，可能對提高架構的質量有幫助；但并不是只有架構師才可以做架構工作。
我們應該把架構師當成一種角色，而不僅僅是一個頭銜、一個位子。也許有很多人的工作頭銜是架構師，但其實際工作和架構關系不大，也可能有些人沒有架構師頭銜，但其在實際工作中衛架構正在做貢獻。
3
? ?
TOGAF 的企業架構模型
As shown in the figure, TOGAF divides an enterprise architecture into four categories, as follows:
圖中，TOGAF 把企業架構分為 4 個部分：
1.Business architecture—Describes the processes the business uses to meet its goals
第一、業務架構。描述業務流程及其達成的業務目標。
2.Application architecture—Describes how specific applications are designed and how they interact with each other
第二、應用架構。描述具體的應用系統的設計以及相互之間的關系。
3.Data architecture—Describes how the enterprise datastores are organized and accessed
第三、數據架構。描述企業的數據存儲以及訪問方式。
4.Technical architecture—Describes the hardware and software infrastructure that supports applications and their interactions 第四、技術架構。描述基礎設施如何支持應用系統的運行及交互。
其中，一個重要的理念是業務架構與應用架構的映射關系（依賴、推理）。應用架構要基于業務架構來考慮，而不是憑空想象。應用是業務能力的提供者。
3.1
? ?
與數據有關的三種角色
很多時候，IT 部門、以及 IT 部門的一些人，常常把自己當成數據的所有者，導致認為地制造了藩籬，阻礙數據的共享及訪問。其實，IT 通常應該只是“司機”的角色。角色錯位了，想做事正確？難于緣木求魚。
這里強調數據，是因為數據是對客觀世界的反映，而我們的每一個應用，不過是客觀世界的一個視圖。
數據是最基本的。數據可以被處理、解釋而得到各種信息，而信息又可以被挖掘出有用的知識。我們也可以從中理解當今所謂 DT 的重要性，以及大數據時代，數據就像工業時代的石油一樣重要。
4
? ?
架構的地位
架構是客觀存在的，不管我們是否有意識地考慮它。架構不是孤立存在的，它是在具體的上下文環境中，為達到明確的目標而存在的。架構不是“屠龍術”。
“規劃-架構-設計”這三者是緊密聯系的，常常被混為一體的。為了理解這些概念的聯系和區別，我們可以與市政規劃進行類比。巴西利亞的建城史、華盛頓的城市規劃，其理念值得我們在考慮架構時借鑒。
5
? ?
規劃與架構
這里把規劃提取出來，而不是與架構混為一談，是為了有助于理解思考與實踐的不同階段和步驟，幫助思維更加清晰。從軟件工程與建筑工程的類比，更容易地理解架構和規劃。另外，“自頂向下，逐步細化”的結構化思想也清晰可見。我們推崇面向對象的方法，因為它與客觀世界的實際情況更接近，同時，我們也要繼承和發揚結構化方法。
6
? ?
架構與設計
所有的架構都是設計，但不是所有的設計都是架構。架構可以認為是宏觀設計、頂層設計。
計算模式經歷了幾個發展階段，我們選擇什么的模式，一方面要跟上技術發展的趨勢，另一方面要知道目的是什么。
第一、主機-終端（mainframe）第二、個人計算機（PC）第三、客戶機/服務器（C/S）第四、分布式計算（網格、云計算等）
7
? ?
分布與集中
如果規模不大，采用分布式部署意義不大。
8
? ?
解耦與服務化
對解耦與服務化的關系進行深入思考，嘗試理解其本質，明確什么事目的，什么是手段。在做決策的時候，就有助于分清主次。
8.1
? ?
一種不嚴格的解耦方法
對于企業應用架構向“微”服務演化，解耦是基礎。為此，在程序實現時，“單一職責”原則需要尊循。即使不走服務化道路，降低耦合度也是好的。
是否可以假定：一般情況下，對于特定的語言環境，比如：java 和 C#，較少的代碼行很難實現多個業務功能？于是以子程序(函數，過程，方法)代碼行數對工程師執行“單一職責”原則進行度量。
對于不同語言，建議對開發小組的代碼行進行統計，經過一段時間的積累得出合適的經驗值。一般地，這個代碼行數的經驗值是和小組的能力相關的。
9
? ?
迭代/敏捷與傳統方法
敏捷方法的使用離不開迭代，我們需要合理地使用這兩種方法，才能使我們的交付物越來越逼近用戶的真實需求。
這里提到了用戶的真實需求，我也多說幾句。用戶的需求不應該是我們作為 BSA 或者 SME 假設出來的，而是我們通過各種有效的方法，比如訪談，從用戶那里捕獲的。即使我們對用戶的建議是正確的，幫助用戶完善需求的，也一定要取得用戶的完全理解并由用戶正式確認。
10
? ?
由分工引發的思考
沒有分工，協作就是一句空話。沒有明確的分工，就會造成扯皮等現象。分工有助于提高效率和質量。要想分工，就要做好功能分解。而功能分解到合適的粒度，也可以認為是服務化的基礎。
微服務所倡導的“單一職責”，其實質也是明確責任，消除歧義。簡單即美，大道至簡。單一職責恰恰符合這個原則。
從這個對制造別針的分工的描述，你會體會到并發現，很多基本道理是相通的，不論對于生產制造還是軟件開發。這就是道法自然。（未完待續）
微服務架構最強講解，通俗易懂，寫得太好了！
2021-06-21
標簽類目體系的價值與意義
2021-06-18
程超：突破瓶頸！如何不斷的提高自己
2021-06-17
資深架構師手把手教你性能優化
2021-06-07
李偉山：金融撮合架構
2021-05-31
總結
以上是生活随笔為你收集整理的资深架构专家聊架构之道：规划、简化和演化的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： nyist-508（余数求和）
- 下一篇： zoj-3624（Count Path