點(diǎn)擊藍(lán)色字體“肉眼品世界”，關(guān)注公眾號

改變，從一點(diǎn)一滴積累開始

作者丨胡斌

策劃丨小智

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

在日常系統(tǒng)開發(fā)過程中，作為技術(shù)人員想必大家都參與過架構(gòu)設(shè)計(jì)的工作。做過一段系統(tǒng)架構(gòu)工作之后，心里對于架構(gòu)產(chǎn)生了越來越多的問題。

• 對于系統(tǒng)的架構(gòu)，它的本質(zhì)是什么，它對產(chǎn)品有何影響？

• 架構(gòu)分為哪幾類？

• 為什么要畫架構(gòu)圖，可以不畫架構(gòu)圖嗎？

• 架構(gòu)圖該怎么畫，怎么讓畫架構(gòu)圖不那么痛苦？

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

什么是架構(gòu)

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

在百度百科中的定義是：架構(gòu)，又名軟件架構(gòu)，是有關(guān)軟件整體結(jié)構(gòu)與組件的抽象描述，用于指導(dǎo)大型軟件系統(tǒng)各個方面的設(shè)計(jì)。

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

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

下圖為古代的木質(zhì)建筑的結(jié)構(gòu)圖：

對應(yīng)到軟件架構(gòu)，這里面的“木”代表什么，軟件架構(gòu)中的“結(jié)構(gòu)”是什么，這些軟件系統(tǒng)的“木”又是如何連接的？

• 關(guān)聯(lián)到軟件領(lǐng)域，木就是系統(tǒng)中的要素，我們將他們稱之為架構(gòu)要素。架構(gòu)要素可以是子系統(tǒng)、模塊、應(yīng)用服務(wù)。

• 結(jié)構(gòu)，是架構(gòu)的產(chǎn)物。不同的軟件系統(tǒng)會有不同的結(jié)構(gòu)，這些結(jié)構(gòu)是為解決不同場景而設(shè)計(jì)的。

• 連接，通過定義架構(gòu)元素之間的接口和交互關(guān)系、集成機(jī)制，實(shí)現(xiàn)架構(gòu)元素之間的連接。連接可以是分布式調(diào)用、進(jìn)程間調(diào)用、組件之間的交互關(guān)系等。

總結(jié)一下架構(gòu)的本質(zhì)，即架構(gòu) = 要素 + 結(jié)構(gòu) + 連接，將系統(tǒng)要素按照特定結(jié)構(gòu)進(jìn)行連接交互。

架構(gòu)域的分類

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

業(yè)務(wù)架構(gòu)

在需求初期，業(yè)務(wù)的需求描述往往比較模糊，可能只是一句話。他們可能來自老板、運(yùn)營或者用戶。直接把這句話作為核心產(chǎn)品功能是不恰當(dāng)?shù)?#xff0c;合理的做法是先把這個產(chǎn)品所有的問題域列清楚。

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

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

業(yè)務(wù)架構(gòu)就是在業(yè)務(wù)需求初期，將模糊的需求描述轉(zhuǎn)變成清晰的問題域，梳理出清晰的業(yè)務(wù)流程。為產(chǎn)品架構(gòu)提供輸入。

業(yè)務(wù)架構(gòu)包括業(yè)務(wù)規(guī)劃、業(yè)務(wù)模塊、業(yè)務(wù)流程，對整個系統(tǒng)的業(yè)務(wù)進(jìn)行拆分，對領(lǐng)域模型進(jìn)行設(shè)計(jì)，把現(xiàn)實(shí)的業(yè)務(wù)轉(zhuǎn)化成抽象對象。沒有最優(yōu)的架構(gòu)，只有最合適的架構(gòu)，一切系統(tǒng)設(shè)計(jì)原則都要以解決業(yè)務(wù)問題為最終目標(biāo)，脫離實(shí)際業(yè)務(wù)的技術(shù)情懷架構(gòu)往往是空中樓閣。

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

上述的案例正是由于業(yè)務(wù)架構(gòu)沒有做到位，沒有做好軟件架構(gòu)的分析和設(shè)計(jì)，所以我們很難看出兩個系統(tǒng)有多少差別，也無法確定用一個業(yè)務(wù)系統(tǒng)去覆蓋另一個業(yè)務(wù)系統(tǒng)的可行性有多大。相反，對 A 和 B 業(yè)務(wù)領(lǐng)域進(jìn)行業(yè)務(wù)架構(gòu)梳理，我們就能清楚發(fā)現(xiàn)兩者的一致與區(qū)別，就能有效的評估系統(tǒng)覆蓋的可行性和合理性。

經(jīng)過業(yè)務(wù)架構(gòu)階段之后，需要輸出的產(chǎn)物包括：企業(yè)戰(zhàn)略方向圖、問題域列表、業(yè)務(wù)流程圖。

數(shù)據(jù)架構(gòu)

企業(yè)架構(gòu)由業(yè)務(wù)架構(gòu)驅(qū)動，從業(yè)務(wù)架構(gòu)分析業(yè)務(wù)流程、定義數(shù)據(jù)架構(gòu)，流程和數(shù)據(jù)結(jié)合定義產(chǎn)品架構(gòu)。這中間，數(shù)據(jù)架構(gòu)起著至關(guān)重要的作用。企業(yè) IT 系統(tǒng)的價值并不在于選取的技術(shù)有多先進(jìn)，使用的硬件有多強(qiáng)大。而是企業(yè)業(yè)務(wù)數(shù)據(jù)的處理和存儲。一家公司最寶貴的資產(chǎn)無疑就是–數(shù)據(jù)。毫無疑問，在當(dāng)今大數(shù)據(jù)的時代背景下，缺少數(shù)據(jù)資產(chǎn)的建設(shè)和使用，就失去與同行業(yè)爭奪競爭的機(jī)會。

因此，數(shù)據(jù)架構(gòu)主要解決三個問題：第一，系統(tǒng)需要什么樣的數(shù)據(jù)；第二，如何存儲這些數(shù)據(jù)；第三，如何進(jìn)行數(shù)據(jù)架構(gòu)設(shè)計(jì)。

系統(tǒng)需要什么樣的數(shù)據(jù)

數(shù)據(jù)是對客觀事物的真實(shí)表現(xiàn)，企業(yè)業(yè)務(wù)過程中的所有對象的狀況都可以用數(shù)據(jù)記錄下來。業(yè)務(wù)運(yùn)營過程中有兩條重要的線索：流程和數(shù)據(jù)。業(yè)務(wù)流程離不開數(shù)據(jù)流轉(zhuǎn)，業(yè)務(wù)運(yùn)營狀況通過數(shù)據(jù)反映。基于業(yè)務(wù)架構(gòu)的端到端的流程建模過程中，會衍生出對應(yīng)的業(yè)務(wù)數(shù)據(jù)對象，需要與數(shù)據(jù)架構(gòu)模型對接。流程模型和數(shù)據(jù)模型對接后落實(shí)到應(yīng)用層面，就形成了產(chǎn)品架構(gòu)。

數(shù)據(jù)架構(gòu)中的數(shù)據(jù)包含靜態(tài)數(shù)據(jù)和動態(tài)數(shù)據(jù)。相對靜態(tài)部分如元數(shù)據(jù)、業(yè)務(wù)對象數(shù)據(jù)模型、主數(shù)據(jù)、共享數(shù)據(jù)。相對動態(tài)部分如數(shù)據(jù)流轉(zhuǎn)、ETL、數(shù)據(jù)全生命周期管控治理。

如何存儲這些數(shù)據(jù)

數(shù)據(jù)架構(gòu)是為了建立一個共享、通用、一致的數(shù)據(jù)基礎(chǔ)平臺，解決企業(yè)信息孤島。如何存儲業(yè)務(wù)數(shù)據(jù)，需要結(jié)合自身需求，采取合適的數(shù)據(jù)分布策略。通常，數(shù)據(jù)存儲的分布策略有兩種：一種是集中式存儲，一種是分布式存儲。

集中式存儲就是講數(shù)據(jù)集中存放于總部數(shù)據(jù)中心，所有的下屬機(jī)構(gòu)或子公司不放置和維護(hù)數(shù)據(jù)，都想總部數(shù)據(jù)中心進(jìn)行訪問。

集中式存儲

分布式存儲就是數(shù)據(jù)分布存放于總部、分支機(jī)構(gòu)或者子公司，每個分布節(jié)點(diǎn)需要維護(hù)和管理自己的數(shù)據(jù)。分布式的數(shù)據(jù)存儲架構(gòu)中，還需要考慮每個分布式節(jié)點(diǎn)的數(shù)據(jù)與總部節(jié)點(diǎn)數(shù)據(jù)進(jìn)行同步、備份，做到數(shù)據(jù)資產(chǎn)的安全、可靠。

分布式存儲

如何進(jìn)行數(shù)據(jù)架構(gòu)設(shè)計(jì)

數(shù)據(jù)源自于企業(yè)的業(yè)務(wù)流程，從業(yè)務(wù)流程中我們可以找出領(lǐng)域?qū)ο?#xff0c;基于領(lǐng)域?qū)ο筮M(jìn)行分析，就能得到對象的屬性。根據(jù)業(yè)務(wù)關(guān)系進(jìn)而抽取領(lǐng)取對象之間的關(guān)系。因此，領(lǐng)域建模是一種對數(shù)據(jù)架構(gòu)很有幫助的建模思想。通過領(lǐng)域建模，我們不僅能清晰的反映企業(yè)的業(yè)務(wù)域，還能清晰的描繪出一幅企業(yè)的數(shù)據(jù)模型。

數(shù)據(jù)模型最常用的視圖就是 ER 圖，它主要描述企業(yè)數(shù)據(jù)實(shí)體、屬性和關(guān)系。

• 實(shí)體 (Entiy): 企業(yè)領(lǐng)域?qū)ο?/p>

• 屬性 (Attribute): 領(lǐng)域?qū)ο蟮膶傩?/p>

• 聯(lián)系 (RelationShip): 兩個領(lǐng)域?qū)ο笾g的關(guān)系 (1:1, 1:n 或者 m:n)

產(chǎn)品架構(gòu)

基礎(chǔ)的產(chǎn)品框架脫胎于業(yè)務(wù)流程，但相比業(yè)務(wù)流程，更加注重產(chǎn)品功能的枚舉、功能模塊之間的分界。

當(dāng)我們打開一個系統(tǒng)，我們會看到一個精美的頁面，一些豐富的信息、導(dǎo)航。這些東西會引導(dǎo)我們?nèi)ナ褂眠@個系統(tǒng)。這些東西就是這個系統(tǒng)的組成部分，就是這個系統(tǒng)的功能模塊。產(chǎn)品架構(gòu)，就是將這些不同用途的功能模塊圍繞特定的業(yè)務(wù)目標(biāo)進(jìn)行分類整合。

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

產(chǎn)品架構(gòu)中，功能模塊是根據(jù)其相互之間的關(guān)系來組織的。一個產(chǎn)品中不同的功能模塊之間的關(guān)系分直接關(guān)系和間接關(guān)系。只有直接關(guān)系的功能模塊才會被組織到一起，形成一個子系統(tǒng)。那些存在間接關(guān)系的模塊，會在不同的層級通過直接關(guān)系的模塊產(chǎn)生聯(lián)系。

當(dāng)具有直接關(guān)系的功能模塊組合成一個子系統(tǒng)后，解決相同問題域的子系統(tǒng)就形成一個功能層級。功能層級按照接近用戶實(shí)操的距離程度進(jìn)行從上到下，或者從左至右的劃分，這就形成了產(chǎn)品架構(gòu)的分層。

應(yīng)用架構(gòu)

應(yīng)用架構(gòu)是要說明產(chǎn)品架構(gòu)分哪些應(yīng)用系統(tǒng)，應(yīng)用系統(tǒng)間是如何集成的。這就是應(yīng)用架構(gòu)和應(yīng)用集成架構(gòu)。產(chǎn)品架構(gòu)在業(yè)務(wù)架構(gòu)的基礎(chǔ)上，按照解決的業(yè)務(wù)問題域，劃分出不同的功能模塊，再根據(jù)功能模塊間的關(guān)系，組合成子系統(tǒng)。應(yīng)用架構(gòu)在產(chǎn)品架構(gòu)的基礎(chǔ)上考慮兩個事情：第一、考慮的是子系統(tǒng)間的關(guān)系。第二、考慮將可復(fù)用的組件或模塊進(jìn)行下沉，沉淀到平臺層，為業(yè)務(wù)組件提供統(tǒng)一的支撐。

應(yīng)用架構(gòu)在規(guī)劃時，需要遵循以下幾個原則：

簡單性

體現(xiàn)在應(yīng)用架構(gòu)是否有清晰、明確的層次劃分，各應(yīng)用系統(tǒng)之間的連接關(guān)系是否簡單明確，系統(tǒng)之間的耦合程度低。

靈活性

體現(xiàn)在應(yīng)用架構(gòu)適應(yīng)業(yè)務(wù)的快速變化，不僅要求在快速增加新應(yīng)用時保持現(xiàn)有應(yīng)用架構(gòu)的穩(wěn)定性，還要在適應(yīng)業(yè)務(wù)變化的同時主動促進(jìn)業(yè)務(wù)變革。

整合性

通過應(yīng)用系統(tǒng)之間的解耦和組合，以統(tǒng)一的方式對外提供一致的服務(wù)接口，從而實(shí)現(xiàn)應(yīng)用系統(tǒng)之間的共享和協(xié)作。

技術(shù)架構(gòu)

應(yīng)用架構(gòu)本身只關(guān)心需要哪些應(yīng)用系統(tǒng)，哪些平臺來滿足業(yè)務(wù)目標(biāo)的需求，而不會關(guān)心在整個構(gòu)建過程中你需要使用哪些技術(shù)。技術(shù)架構(gòu)是應(yīng)接應(yīng)用架構(gòu)的技術(shù)需求，并根據(jù)識別的技術(shù)需求，進(jìn)行技術(shù)選型，把各個關(guān)鍵技術(shù)和技術(shù)之間的關(guān)系描述清楚。

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

總之，技術(shù)架構(gòu)是將產(chǎn)品需求轉(zhuǎn)變?yōu)榧夹g(shù)實(shí)現(xiàn)的過程。

為什么要畫架構(gòu)圖 梳理自己對產(chǎn)品和技術(shù)方向的判斷

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

提供產(chǎn)品 & 技術(shù) & 運(yùn)營的輸出

當(dāng)產(chǎn)品架構(gòu)圖被設(shè)計(jì)出來后，按照產(chǎn)品架構(gòu)圖的結(jié)構(gòu)和路徑，項(xiàng)目的里程碑（RoadMap）就可以被清晰的拆解出來，同時項(xiàng)目成員也可以根據(jù)這張架構(gòu)圖產(chǎn)出運(yùn)營計(jì)劃、技術(shù)架構(gòu)等強(qiáng)依賴產(chǎn)品方向的方案。

當(dāng)技術(shù)架構(gòu)圖被設(shè)計(jì)出來后，技術(shù)方案、技術(shù)開發(fā)進(jìn)度就可以被清晰的制定，技術(shù)選型就會明確的選定。

讓他人可視化的理解你的架構(gòu)

能清晰簡單的呈現(xiàn)自己的思路、明確自己產(chǎn)品的邊界和技術(shù)邊界、指明發(fā)展的方向，幫助不了解你產(chǎn)品的人快速的建立對你產(chǎn)品結(jié)構(gòu)、功能、技術(shù)的認(rèn)知。

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

不同角色對于架構(gòu)視圖的需求有所不同，一張圖走天下是不太現(xiàn)實(shí)。往往需要針對不同的用戶，提供不同視角的架構(gòu)視圖，便于不同角色用戶對于產(chǎn)品的理解。

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

同理，軟件架構(gòu)視圖也需要按照不同的視角提供不同的視圖。面向業(yè)務(wù)或者產(chǎn)品，需要以產(chǎn)品架構(gòu)圖去展示。面向技術(shù)同學(xué)，需要以技術(shù)架構(gòu)圖去溝通。不同的視圖有助于大家理解同一件事。

何時需要畫架構(gòu)圖 在復(fù)雜項(xiàng)目開始前畫

當(dāng)你要開始設(shè)計(jì)一個系統(tǒng)性、完整性的系統(tǒng)時，如果一開始就跳過設(shè)計(jì)產(chǎn)品架構(gòu)圖、技術(shù)架構(gòu)圖，直接開始寫文檔、畫 demo，就很容易發(fā)生改了又改，做了又推翻的情況。

當(dāng)你覺得是該畫的時候（do it）

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

如何畫架構(gòu)圖對復(fù)雜的系統(tǒng)，特別是前人沒有做過的新系統(tǒng)，通常難以一下子設(shè)計(jì)出合適的架構(gòu)。在架構(gòu)設(shè)計(jì)的初期，通常都要經(jīng)歷一個不斷探索的階段。

在架構(gòu)設(shè)計(jì)過程中，架構(gòu)分解是必不可少的關(guān)鍵步驟。如何進(jìn)行架構(gòu)分解，從哪里入手開始進(jìn)行分解？這些需要一套架構(gòu)分解的過程模型和過程方法來指導(dǎo)分解。

從架構(gòu)域的分類：業(yè)務(wù)架構(gòu)、數(shù)據(jù)架構(gòu)、產(chǎn)品架構(gòu)、應(yīng)用架構(gòu)、技術(shù)架構(gòu)這 5 個域，依次需要進(jìn)行架構(gòu)分解。每個結(jié)構(gòu)域的分解過程，都是一個迭代過程。從無到有、從粗到細(xì)、從模糊到清晰，一步步精細(xì)化、豐富架構(gòu)。迭代的過程就是一個否定之否定的過程，隨著分解的逐步推進(jìn)或系統(tǒng)的架構(gòu)演化，后面的分解除了會識別出新的架構(gòu)元素，也可能會對先前識別出的架構(gòu)作出調(diào)整。整個架構(gòu)分解的迭代過程，通過畫架構(gòu)圖的方式是種非常直觀的表現(xiàn)形式。

根據(jù)這些架構(gòu)的分類，依次需要產(chǎn)出業(yè)務(wù)架構(gòu)圖、數(shù)據(jù)架構(gòu)圖、產(chǎn)品架構(gòu)圖、應(yīng)用架構(gòu)圖、技術(shù)架構(gòu)圖。每個架構(gòu)域如何進(jìn)行設(shè)計(jì)和架構(gòu)圖的繪制，將通過后續(xù) 4 篇文章來闡述。

作者介紹

胡斌，菜鳥網(wǎng)絡(luò)技術(shù)專家，目前負(fù)責(zé)菜鳥風(fēng)控系統(tǒng)的建設(shè)。曾在淘寶技術(shù)部先后負(fù)責(zé)賣家平臺、商家運(yùn)營等領(lǐng)域。在大規(guī)模分布式應(yīng)用、大數(shù)據(jù)、架構(gòu)領(lǐng)域有多年的開發(fā)和管理經(jīng)驗(yàn)。

點(diǎn)個在看少個 bug ?

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。