點擊藍色字體“肉眼品世界”，關注公眾號

改變，從一點一滴積累開始

作者丨胡斌

策劃丨小智

本文是架構設計實踐五部曲系列文章的第一篇，架構與架構圖。本文將對架構作深入的闡釋，并教你什么時候畫架構圖、怎么畫架構圖。

在日常系統開發過程中，作為技術人員想必大家都參與過架構設計的工作。做過一段系統架構工作之后，心里對于架構產生了越來越多的問題。

• 對于系統的架構，它的本質是什么，它對產品有何影響？

• 架構分為哪幾類？

• 為什么要畫架構圖，可以不畫架構圖嗎？

• 架構圖該怎么畫，怎么讓畫架構圖不那么痛苦？

為了回答這些問題，我總結了這一系列的文章，沉淀自己對于架構的理解，總結架構設計的實踐和思路。希望能幫助到在做架構設計過程中，同樣有這些困惑的你。

什么是架構

什么是架構？我們先看一下百科中是如何定義架構的。

在百度百科中的定義是：架構，又名軟件架構，是有關軟件整體結構與組件的抽象描述，用于指導大型軟件系統各個方面的設計。

在維基百科中的定義是：軟件體系結構是指軟件系統的基本結構，創建此類結構的規則以及這些結構的文檔。需要這些結構來推斷軟件系統。每個結構包括軟件元素，它們之間的關系，元素和關系的屬性，以及每個元素的引入和配置的基本原理。軟件系統的體系結構是一種隱喻，類似于建筑物的體系結構。

從百科中我們提煉出一句話，“架構是一種整體與局部關系的抽象描述”。這句話還是稍顯抽象，不太容易理解。換個角度，按照中文的字面理解，對“架構“兩個字進行拆解，就會發現很有意思含義。架構從字面意思上，是源于古代的建筑術語。把架構拆分成兩個字“架”和“構”。“架”就是“加”和“木”的結合，把木頭加起來、連接起來就是架。“構”就是結構的意思。所以，“架構”就是把“木“按照一定的結構連接起來。

下圖為古代的木質建筑的結構圖：

對應到軟件架構，這里面的“木”代表什么，軟件架構中的“結構”是什么，這些軟件系統的“木”又是如何連接的？

• 關聯到軟件領域，木就是系統中的要素，我們將他們稱之為架構要素。架構要素可以是子系統、模塊、應用服務。

• 結構，是架構的產物。不同的軟件系統會有不同的結構，這些結構是為解決不同場景而設計的。

• 連接，通過定義架構元素之間的接口和交互關系、集成機制，實現架構元素之間的連接。連接可以是分布式調用、進程間調用、組件之間的交互關系等。

總結一下架構的本質，即架構 = 要素 + 結構 + 連接，將系統要素按照特定結構進行連接交互。

架構域的分類

在軟件設計中架構域是如何劃分的，架構域包括：業務架構、數據架構、產品架構、應用架構、技術架構。首先需要熟悉業務，形成業務架構，根據業務架構，做出相應的數據架構和應用架構，最后通過技術架構落地實施。業務架構是戰略，應用架構是承上啟下，一方面承接業務架構的落地，另一方面影響技術架構的選型。如何針對當前需求，選擇合適的架構，如何面向未來，保證架構平滑過渡，這個是軟件開發者，特別是架構師，都需要深入思考的問題。

業務架構

在需求初期，業務的需求描述往往比較模糊，可能只是一句話。他們可能來自老板、運營或者用戶。直接把這句話作為核心產品功能是不恰當的，合理的做法是先把這個產品所有的問題域列清楚。

問題域，是指自己的產品能夠解決的所有問題的空間集合。從核心需求出發，將所有當前需要解決、未來可能要解決的問題放入產品框架的范圍。能夠幫助我們的產品擁有更高的可拓展性，在后續具備迭代和優化的空間。

在經過問題域的羅列后，我們應該能夠得到一個模糊的產品方向和功能范圍。把這些問題域的答案抽象總結成一個確定的產品需求。根據核心需求和問題域的答案，梳理出業務流程。

業務架構就是在業務需求初期，將模糊的需求描述轉變成清晰的問題域，梳理出清晰的業務流程。為產品架構提供輸入。

業務架構包括業務規劃、業務模塊、業務流程，對整個系統的業務進行拆分，對領域模型進行設計，把現實的業務轉化成抽象對象。沒有最優的架構，只有最合適的架構，一切系統設計原則都要以解決業務問題為最終目標，脫離實際業務的技術情懷架構往往是空中樓閣。

業務架構必須與其面向的實際應用場景相匹配，由于每個產品或項目的業務場景均有所不同，所以每次做新的軟件開發前，必須設計軟件架構。試圖不經分析直接套用先前的架構方案，十有八九會讓當前的系統在某個點上報出大問題導致推翻重建，更不要說直接拿別人的現成架構方案了。例如，A 業務中有套 A 系統，恰巧 B 業務需要解決類似 A 業務的場景。此時很多情況，B 業務的人員會考慮把 A 系統直接拿過來，以為做一些簡單的修改，就能在 B 業務中落地。結果在系統落地的過程中，很多功能模塊不能直接使用，都要重新按照業務進行修改。最終的結果是，A 系統經過不斷的重寫修改變成了 B 系統。

上述的案例正是由于業務架構沒有做到位，沒有做好軟件架構的分析和設計，所以我們很難看出兩個系統有多少差別，也無法確定用一個業務系統去覆蓋另一個業務系統的可行性有多大。相反，對 A 和 B 業務領域進行業務架構梳理，我們就能清楚發現兩者的一致與區別，就能有效的評估系統覆蓋的可行性和合理性。

經過業務架構階段之后，需要輸出的產物包括：企業戰略方向圖、問題域列表、業務流程圖。

數據架構

企業架構由業務架構驅動，從業務架構分析業務流程、定義數據架構，流程和數據結合定義產品架構。這中間，數據架構起著至關重要的作用。企業 IT 系統的價值并不在于選取的技術有多先進，使用的硬件有多強大。而是企業業務數據的處理和存儲。一家公司最寶貴的資產無疑就是–數據。毫無疑問，在當今大數據的時代背景下，缺少數據資產的建設和使用，就失去與同行業爭奪競爭的機會。

因此，數據架構主要解決三個問題：第一，系統需要什么樣的數據；第二，如何存儲這些數據；第三，如何進行數據架構設計。

系統需要什么樣的數據

數據是對客觀事物的真實表現，企業業務過程中的所有對象的狀況都可以用數據記錄下來。業務運營過程中有兩條重要的線索：流程和數據。業務流程離不開數據流轉，業務運營狀況通過數據反映。基于業務架構的端到端的流程建模過程中，會衍生出對應的業務數據對象，需要與數據架構模型對接。流程模型和數據模型對接后落實到應用層面，就形成了產品架構。

數據架構中的數據包含靜態數據和動態數據。相對靜態部分如元數據、業務對象數據模型、主數據、共享數據。相對動態部分如數據流轉、ETL、數據全生命周期管控治理。

如何存儲這些數據

數據架構是為了建立一個共享、通用、一致的數據基礎平臺，解決企業信息孤島。如何存儲業務數據，需要結合自身需求，采取合適的數據分布策略。通常，數據存儲的分布策略有兩種：一種是集中式存儲，一種是分布式存儲。

集中式存儲就是講數據集中存放于總部數據中心，所有的下屬機構或子公司不放置和維護數據，都想總部數據中心進行訪問。

集中式存儲

分布式存儲就是數據分布存放于總部、分支機構或者子公司，每個分布節點需要維護和管理自己的數據。分布式的數據存儲架構中，還需要考慮每個分布式節點的數據與總部節點數據進行同步、備份，做到數據資產的安全、可靠。

分布式存儲

如何進行數據架構設計

數據源自于企業的業務流程，從業務流程中我們可以找出領域對象，基于領域對象進行分析，就能得到對象的屬性。根據業務關系進而抽取領取對象之間的關系。因此，領域建模是一種對數據架構很有幫助的建模思想。通過領域建模，我們不僅能清晰的反映企業的業務域，還能清晰的描繪出一幅企業的數據模型。

數據模型最常用的視圖就是 ER 圖，它主要描述企業數據實體、屬性和關系。

• 實體 (Entiy): 企業領域對象

• 屬性 (Attribute): 領域對象的屬性

• 聯系 (RelationShip): 兩個領域對象之間的關系 (1:1, 1:n 或者 m:n)

產品架構

基礎的產品框架脫胎于業務流程，但相比業務流程，更加注重產品功能的枚舉、功能模塊之間的分界。

當我們打開一個系統，我們會看到一個精美的頁面，一些豐富的信息、導航。這些東西會引導我們去使用這個系統。這些東西就是這個系統的組成部分，就是這個系統的功能模塊。產品架構，就是將這些不同用途的功能模塊圍繞特定的業務目標進行分類整合。

功能模塊是用戶能夠完成一個操作的最小粒度的完整功能。比如一個展示可購買商品的列表頁、一個修改用戶密碼的功能。在功能模塊設計過程中，需要確保用戶能通過一個功能模塊完整的完成一項工作，而不是半個工作。

產品架構中，功能模塊是根據其相互之間的關系來組織的。一個產品中不同的功能模塊之間的關系分直接關系和間接關系。只有直接關系的功能模塊才會被組織到一起，形成一個子系統。那些存在間接關系的模塊，會在不同的層級通過直接關系的模塊產生聯系。

當具有直接關系的功能模塊組合成一個子系統后，解決相同問題域的子系統就形成一個功能層級。功能層級按照接近用戶實操的距離程度進行從上到下，或者從左至右的劃分，這就形成了產品架構的分層。

應用架構

應用架構是要說明產品架構分哪些應用系統，應用系統間是如何集成的。這就是應用架構和應用集成架構。產品架構在業務架構的基礎上，按照解決的業務問題域，劃分出不同的功能模塊，再根據功能模塊間的關系，組合成子系統。應用架構在產品架構的基礎上考慮兩個事情：第一、考慮的是子系統間的關系。第二、考慮將可復用的組件或模塊進行下沉，沉淀到平臺層，為業務組件提供統一的支撐。

應用架構在規劃時，需要遵循以下幾個原則：

簡單性

體現在應用架構是否有清晰、明確的層次劃分，各應用系統之間的連接關系是否簡單明確，系統之間的耦合程度低。

靈活性

體現在應用架構適應業務的快速變化，不僅要求在快速增加新應用時保持現有應用架構的穩定性，還要在適應業務變化的同時主動促進業務變革。

整合性

通過應用系統之間的解耦和組合，以統一的方式對外提供一致的服務接口，從而實現應用系統之間的共享和協作。

技術架構

應用架構本身只關心需要哪些應用系統，哪些平臺來滿足業務目標的需求，而不會關心在整個構建過程中你需要使用哪些技術。技術架構是應接應用架構的技術需求，并根據識別的技術需求，進行技術選型，把各個關鍵技術和技術之間的關系描述清楚。

技術架構解決的問題包括：如何進行純技術層面的分層、開發框架的選擇、開發語言的選擇、涉及非功能性需求的技術選擇。由于應用架構體系是分層的，那么對于的技術架構體系自然也是分層的。大的分層有微服務架構分層模型，小的分層則是單個應用的技術分層框架。大的技術體系考慮清楚后，剩下的問題就是根據實際業務場景來選擇具體的技術點。各個技術點的分析、方案選擇，最終形成關鍵技術清單，關鍵技術清單考慮應用架構本身的分層邏輯，最終形成一個完成的技術架構圖。

總之，技術架構是將產品需求轉變為技術實現的過程。

為什么要畫架構圖 梳理自己對產品和技術方向的判斷

我們是不是都會遇到這樣的情況，每次畫圖前，腦海中有一張看似清晰的圖。但是一到畫圖那一刻，這張圖確又是那么無比的模糊。思考這張圖如何設計的過程，也是幫助你梳理“未來產品該朝什么方向發展、功能迭代如何分期和落地、和其他產品的依賴關系是什么、技術方案該如何演進”等問題的過程。

提供產品 & 技術 & 運營的輸出

當產品架構圖被設計出來后，按照產品架構圖的結構和路徑，項目的里程碑（RoadMap）就可以被清晰的拆解出來，同時項目成員也可以根據這張架構圖產出運營計劃、技術架構等強依賴產品方向的方案。

當技術架構圖被設計出來后，技術方案、技術開發進度就可以被清晰的制定，技術選型就會明確的選定。

讓他人可視化的理解你的架構

能清晰簡單的呈現自己的思路、明確自己產品的邊界和技術邊界、指明發展的方向，幫助不了解你產品的人快速的建立對你產品結構、功能、技術的認知。

提供面向不同人員的視圖語言

不同角色對于架構視圖的需求有所不同，一張圖走天下是不太現實。往往需要針對不同的用戶，提供不同視角的架構視圖，便于不同角色用戶對于產品的理解。

來看一個生活中視圖的例子。就拿中國地圖為例，不同的人員會關心不同的問題，例如圖 1（中國氣候類型）是氣象學家關心的，而圖 2（商品糧基地分布）是糧食局人員關心的。如果氣象學家拿到一張商品糧基地分布地圖，對他們來說根本就沒有什么研究價值。看地圖的人希望一幅地圖能針對他的需求來展現。

同理，軟件架構視圖也需要按照不同的視角提供不同的視圖。面向業務或者產品，需要以產品架構圖去展示。面向技術同學，需要以技術架構圖去溝通。不同的視圖有助于大家理解同一件事。

何時需要畫架構圖 在復雜項目開始前畫

當你要開始設計一個系統性、完整性的系統時，如果一開始就跳過設計產品架構圖、技術架構圖，直接開始寫文檔、畫 demo，就很容易發生改了又改，做了又推翻的情況。

當你覺得是該畫的時候（do it）

如果項目已經進行了一半，或者項目都已經結束了，但自己卻從未畫過架構圖。那么從此刻開始，動手開始畫把。有一句話“種一棵樹最好的時間是十年前，其次是現在”。

如何畫架構圖對復雜的系統，特別是前人沒有做過的新系統，通常難以一下子設計出合適的架構。在架構設計的初期，通常都要經歷一個不斷探索的階段。

在架構設計過程中，架構分解是必不可少的關鍵步驟。如何進行架構分解，從哪里入手開始進行分解？這些需要一套架構分解的過程模型和過程方法來指導分解。

從架構域的分類：業務架構、數據架構、產品架構、應用架構、技術架構這 5 個域，依次需要進行架構分解。每個結構域的分解過程，都是一個迭代過程。從無到有、從粗到細、從模糊到清晰，一步步精細化、豐富架構。迭代的過程就是一個否定之否定的過程，隨著分解的逐步推進或系統的架構演化，后面的分解除了會識別出新的架構元素，也可能會對先前識別出的架構作出調整。整個架構分解的迭代過程，通過畫架構圖的方式是種非常直觀的表現形式。

根據這些架構的分類，依次需要產出業務架構圖、數據架構圖、產品架構圖、應用架構圖、技術架構圖。每個架構域如何進行設計和架構圖的繪制，將通過后續 4 篇文章來闡述。

作者介紹

胡斌，菜鳥網絡技術專家，目前負責菜鳥風控系統的建設。曾在淘寶技術部先后負責賣家平臺、商家運營等領域。在大規模分布式應用、大數據、架構領域有多年的開發和管理經驗。

點個在看少個 bug ?

總結

以上是生活随笔為你收集整理的架构设计实践思路：什么是架构，怎么画架构图？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。