1

? ?

業(yè)務(wù)分析

業(yè)務(wù)分析是應(yīng)用系統(tǒng)的思想和方法，把復(fù)雜的需求分解成簡單的對象，找出這些對象的基本屬性以及彼此之間的關(guān)系，系統(tǒng)分析也是系統(tǒng)開發(fā)中最重要、也是最困難的階段，最終的架構(gòu)設(shè)計(jì)也要依據(jù)業(yè)務(wù)分析的結(jié)果，運(yùn)用合理的思想和方法，才能設(shè)計(jì)出滿足逾期的系統(tǒng)架構(gòu)，由此可見系統(tǒng)的分析和設(shè)計(jì)是程序員進(jìn)階中最重要的能力，是產(chǎn)品需求到編碼實(shí)現(xiàn)過程中最重要的手段。

2

? ?

黃金圈法則

人人都知道自己是做什么的，有些人知道自己是怎么做的，但極少一部分人知道自己為什么這么做，這就是很著名的黃金圈法則，也叫作 2W1H 分析法。黃金圈法則源于知名廣告人 Simon Sinek 的發(fā)現(xiàn)，是由“為什么（Why）、怎么做（How）、做什么（What）”三部分組成的由內(nèi)到外的思維方式，如圖所示。

黃金圈法則的三個層次與人腦的三個皮層精確對應(yīng)，如圖所示。人腦最外層為新皮質(zhì)，負(fù)責(zé)理性思維分析和語言；中間層和最里層為邊腦，負(fù)責(zé)情緒和行動，比如信任和忠誠，以及行為和決策。人們通過理智對外界信息和過往經(jīng)歷進(jìn)行搜集與整理，傳達(dá)給情緒，情緒影響直覺，直覺產(chǎn)生行動，而感覺則是直覺的直接反應(yīng)，預(yù)示著如何行動。所以從外到內(nèi)溝通時，通過說明“做什么”能夠幫助我們理解大量的復(fù)雜信息，利用的是理性思維，它擅長分析，但不會促使人采取行動。但從內(nèi)到外溝通時，是直接對應(yīng)控制決策過程的。

如果將黃金圈法則對應(yīng)工作的話，則：大部分人都知道做什么，能使用技術(shù)將工作做好，通常處于執(zhí)行層；而有些人知道怎么做，具有組織、管理和協(xié)調(diào)能力，通常處于管理層；而只有極少一部分人知道為什么做，能夠制定戰(zhàn)略、目標(biāo)和計(jì)劃，具有宏觀把控能力，通常處于決策層。企業(yè)中的執(zhí)行層、管理層和決策層就形成了我們的人才金字塔，如圖所示

所以，我們通過黃金圈法則能夠解釋為什么一些組織者或領(lǐng)導(dǎo)者能夠在別人覺得不可能的地方激發(fā)出靈感和潛力，表現(xiàn)出卓越的天賦。那么，程序員如何從被動接收任務(wù)的執(zhí)行層，發(fā)展成為具備系統(tǒng)分析和架構(gòu)設(shè)計(jì)能力的決策層呢？有什么方法或捷徑可循嗎？答案之一是對 UML 建模工具的熟練運(yùn)用，因?yàn)槌绦騿T除了需要具備寫代碼的能力，還需要具備凌駕于編程語言之上的能力，即系統(tǒng)分析與設(shè)計(jì)的能力，UML 就是用于系統(tǒng)分析和設(shè)計(jì)的一種工具。

3

? ?

業(yè)務(wù)分析和設(shè)計(jì)的方法

現(xiàn)在，用戶的需求越來越復(fù)雜，變化也越來越快，如果仍然通過需求管理、需求跟蹤等管理方式來約束和減少需求頻繁變更對軟件開發(fā)帶來的沖擊，則會導(dǎo)致軟件開發(fā)變得僵硬，程序員更加疲憊。另外，用戶的需求通常來自某個專業(yè)領(lǐng)域，比如法律、財(cái)務(wù)或電子商務(wù)等，每個特定的需求又有其特別復(fù)雜之處，所以幾乎沒有人能夠第一時間抓住這些專業(yè)領(lǐng)域的需求本質(zhì)。因此，用戶的需求在歷經(jīng)幾次演變之后變得面目全非，每一個加工制造環(huán)節(jié)都以為做“正確的事”。

在現(xiàn)實(shí)工作中，這樣的局面一再上演，比如，產(chǎn)品經(jīng)理在宣講 PRD（Product Requirement Document，產(chǎn)品需求文檔）時，需要將專業(yè)名詞使用通俗的業(yè)務(wù)語言翻譯給業(yè)務(wù)方，還要使用技術(shù)語言翻譯給開發(fā)人員，這就很容易導(dǎo)致各方信息不對等，業(yè)務(wù)方的理解和技術(shù)人員的理解可能完全不一致。

因此，聰明的工程師們引入了靈活多變的面向?qū)ο蠓治雠c設(shè)計(jì)（OOAD）方法。面向?qū)ο蠓治雠c設(shè)計(jì)方法對復(fù)雜需求的解決方法是：委派專業(yè)建模專家跟蹤理解需求，并在需求和需求之間搭建橋梁。

注意：面向?qū)ο蠓治雠c設(shè)計(jì)被拆分為系統(tǒng)分析和系統(tǒng)設(shè)計(jì)兩部分，我們國家還專門有“系統(tǒng)分析師”和“系統(tǒng)設(shè)計(jì)師”兩種職稱考試。這樣拆分的結(jié)果就是對需求分析的結(jié)果無法直接進(jìn)行設(shè)計(jì)和編程，而能夠運(yùn)行的代碼扭曲需求，導(dǎo)致客戶在運(yùn)行軟件后才發(fā)現(xiàn)很多功能不是自己想要的，而且軟件不能快速跟進(jìn)需求的變化。

雖然面向?qū)ο蠓治雠c設(shè)計(jì)的思想帶給分析和設(shè)計(jì)很大的靈活性，也對軟件開發(fā)產(chǎn)生了前所未有的影響，但有一定的局限性：面向?qū)ο蠓治雠c設(shè)計(jì)主要關(guān)注微觀層次的抽象，比如類和對象實(shí)例等；每個問題域通常都需要創(chuàng)建單獨(dú)的用例分析模型，項(xiàng)目或產(chǎn)品的大方向在許多情況下變得很模糊，很難全局把控系統(tǒng)的總目標(biāo)，所以這樣的系統(tǒng)分析與設(shè)計(jì)方式存在很大的風(fēng)險(xiǎn)。

面向?qū)ο蠓治雠c設(shè)計(jì)的局限性，催生了面向服務(wù)分析與設(shè)計(jì)（SOAD）方法，它有效地彌補(bǔ)了面向?qū)ο蠓治雠c設(shè)計(jì)的局限性。同時，面向服務(wù)的架構(gòu)（Service-Oriented Architecture，SOA）也走進(jìn)了大眾的視野并很快流行起來。

面向服務(wù)分析與設(shè)計(jì)并不是一種全新的分析與設(shè)計(jì)方式，只不過是從不同的抽象角度去設(shè)計(jì)一種業(yè)務(wù)模型。面向?qū)ο蠓治雠c設(shè)計(jì)可以說是一種自底向頂?shù)脑O(shè)計(jì)方式，雖然面向?qū)ο蟮姆椒ū绕鹪缙诿嫦蜻^程的方法有了很大的改進(jìn)，但是放到復(fù)雜的商業(yè)邏輯里面，面向?qū)ο缶惋@得遠(yuǎn)遠(yuǎn)不夠，需要從更高的層次分解商業(yè)邏輯，所以才需要面向服務(wù)分析與設(shè)計(jì)。在做面向服務(wù)分析與設(shè)計(jì)時，首先會分離出業(yè)務(wù)流程和服務(wù)，再在這個基礎(chǔ)上細(xì)化對象，這就是一種自頂向底的方法。面向?qū)ο蠓治雠c設(shè)計(jì)與面向服務(wù)分析與設(shè)計(jì)的抽象關(guān)系如圖所示。

那么，面向服務(wù)分析與設(shè)計(jì)就是最好的了嗎？它又有什么局限性呢？

眾所周知，軟件開發(fā)的流程通常為需求、分析、設(shè)計(jì)、開發(fā)、集成測試和交付部署。不管是在面向?qū)ο蠓治雠c設(shè)計(jì)中還是在面向服務(wù)分析與設(shè)計(jì)中，系統(tǒng)的分析和設(shè)計(jì)都是分開的、割裂的，即分析人員從領(lǐng)域中收集基本的業(yè)務(wù)概念，系統(tǒng)設(shè)計(jì)人員再將基本的業(yè)務(wù)概念映射為相應(yīng)的編程工具的構(gòu)造組件。在這個過程中，由于分析和設(shè)計(jì)的模型不同，導(dǎo)致在分析和設(shè)計(jì)之間形成一條鴻溝，如圖所示。

2004 年，著名建模專家 Eric Evans 出版了其最具影響力的著名書籍 Domain Driven-Design architecture，其中提出的領(lǐng)域驅(qū)動設(shè)計(jì)（DDD）方法打破了分析和設(shè)計(jì)割裂的狀態(tài)，并給出了領(lǐng)域模型的概念，拋棄了將分析與設(shè)計(jì)分開的做法，通過使用統(tǒng)一的模型來滿足分析和設(shè)計(jì)的需求，使系統(tǒng)開發(fā)能夠更加靈活、快速地響應(yīng)需求的變化。

注意：DevOps 的出現(xiàn)又進(jìn)一步填平了開發(fā)和部署之間的鴻溝，值得注意的是，任何新技術(shù)或概念的提出都不是憑空想象的，都是為了應(yīng)對人們在生活和工作中遇到的瓶頸。架構(gòu)師也需要具備發(fā)現(xiàn)系統(tǒng)中存在的瓶頸并給出相應(yīng)解決方案的能力。

4

? ?

系統(tǒng)分析與設(shè)計(jì)的三個發(fā)展階段

下面講講系統(tǒng)分析與設(shè)計(jì)的三個發(fā)展階段。

4.1

? ?

面向數(shù)據(jù)的分析與設(shè)計(jì)

圍繞數(shù)據(jù)庫驅(qū)動的分析與設(shè)計(jì)可以說是系統(tǒng)分析與設(shè)計(jì)的第一階段。軟件設(shè)計(jì)總是從設(shè)計(jì)數(shù)據(jù)庫及其字段開始的，這一階段的特征就是圍繞數(shù)據(jù)庫編程，應(yīng)用系統(tǒng)是典型的兩層架構(gòu)：分為界面層（User Interface）和數(shù)據(jù)庫層（DataBase）。該階段的典型技術(shù)為 Delphi 和 VB 等。

這種圍繞數(shù)據(jù)庫的分析與設(shè)計(jì)方法導(dǎo)致了過程化的編程思維，因?yàn)閿?shù)據(jù)庫結(jié)構(gòu)由 DBA 設(shè)計(jì)后交由程序員編寫大量的 SQL 語句實(shí)現(xiàn)，而 SQL 語句執(zhí)行是有先后順序的，所以程序員大多養(yǎng)成了面向過程的思維方式，長此以往成了習(xí)慣就難以改變。

面向過程（Proceduce Oriented）是一種思維方式，在面對一個問題時，我們通常先關(guān)注解決這個問題的步驟，即過程。比如對于如何將大象裝入冰箱這個問題，我們想到的步驟是：第 1 步，打開冰箱；第 2 步，裝入大象；第 3 步，關(guān)上冰箱。這就是典型的面向過程的思維方式，雖然這樣更加直接、有效地可以完成問題，但是當(dāng)面對更復(fù)雜的問題時，解決問題的過程會變得非常復(fù)雜和難以理解。同樣，圍繞數(shù)據(jù)庫驅(qū)動的分析與設(shè)計(jì)有以下明顯缺點(diǎn)。

不能迅速、有效、全面地認(rèn)識反映和需求，在這種分析與設(shè)計(jì)思維中，世界不僅由簡單的關(guān)系數(shù)據(jù)組成，還使用關(guān)系數(shù)據(jù)庫反映現(xiàn)實(shí)需求，這不符合人類的自然思維，是一種扭曲的分析方法。

系統(tǒng)的性能很難提升，容易導(dǎo)致軟件運(yùn)行時負(fù)載集中在數(shù)據(jù)庫端，使系統(tǒng)變成集中式和高風(fēng)險(xiǎn)的大型單體模式（Monolithic），喪失分布式集群處理能力。

面向?qū)ο缶幊陶Z言和關(guān)系型數(shù)據(jù)庫本身是矛盾的，因?yàn)殛P(guān)系型數(shù)據(jù)庫分析與設(shè)計(jì)本身是面向過程的思維（這一矛盾在當(dāng)今的實(shí)現(xiàn)中依然存在，不過在領(lǐng)域驅(qū)動設(shè)計(jì)中已有解決方案）。

4.2

? ?

面向?qū)ο蠛头?wù)的分析與設(shè)計(jì)

隨著系統(tǒng)的復(fù)雜度越來越高，面向過程的問題也越來越突顯，因此誕生了具有劃時代意義的面向?qū)ο蠓治龊驮O(shè)計(jì)方法，應(yīng)用系統(tǒng)也變成了經(jīng)典的三層架構(gòu)模式：界面層（User Interface layer）、業(yè)務(wù)邏輯層（Business Logic Layer）和數(shù)據(jù)訪問層（Data access layer），如圖所示。

此時出現(xiàn)獨(dú)立進(jìn)行分析和設(shè)計(jì)的兩個階段，系統(tǒng)分析和設(shè)計(jì)開始上升到一個相對更高的層次，擁有自己的一套科學(xué)且藝術(shù)的方法論，但也帶來了一個致命的缺點(diǎn)，分析階段和設(shè)計(jì)階段不能很好地銜接，出現(xiàn)了難以逾越的鴻溝。因?yàn)榉治鋈藛T負(fù)責(zé)從需求領(lǐng)域中收集基本概念，而設(shè)計(jì)人員負(fù)責(zé)指明一組能在項(xiàng)目中適應(yīng)編程工具構(gòu)造的組件，這些組件必須能夠在目標(biāo)環(huán)境中有效執(zhí)行，并能夠正確解決應(yīng)用程序出現(xiàn)的問題。可以看到，分析與設(shè)計(jì)這兩個階段的目標(biāo)并不一致，分析人員只關(guān)注需求分析，并不關(guān)心是否適合設(shè)計(jì)或者能否導(dǎo)出適合設(shè)計(jì)的分析結(jié)果；而設(shè)計(jì)人員因?yàn)橐疹櫝绦虼a實(shí)現(xiàn)的可行性，因此可能抱怨分析人員給出的結(jié)果過于粗糙，不適合設(shè)計(jì)，于是分析與設(shè)計(jì)兩個階段嚴(yán)重分裂，最終可能導(dǎo)致整個項(xiàng)目的失敗。

另外，在分析和設(shè)計(jì)兩個階段雖然都使用了 UML，但是 UML 不是思想方法，只是一種分析與設(shè)計(jì)工具。假若將 UML 類比為 CAD 繪圖軟件，那么會 CAD 的繪圖員就是建筑師嗎？很顯然不是。所以 UML 不是銀彈，更不等價(jià)于分析與設(shè)計(jì)方法。

4.3

? ?

面向問題域的分析與設(shè)計(jì)

問題域模型有一個最流行的名字：領(lǐng)域模型，領(lǐng)域模型是一種概念模型，是對領(lǐng)域內(nèi)的概念類或現(xiàn)實(shí)世界中對象的可視化表示。領(lǐng)域模型也成為概念模型、領(lǐng)域?qū)ο竽Ｐ秃头治鰧ο竽Ｐ汀?/p>

Eric Evans 在 2004 年發(fā)表了 Domain-Driven Design –Tackling Complexity in the Heart of Software 的論文，主題便是領(lǐng)域驅(qū)動設(shè)計(jì)，還提出領(lǐng)域模型的分層架構(gòu)，將整個系統(tǒng)劃分為基礎(chǔ)設(shè)施層（Infrastructure）、領(lǐng)域?qū)?#xff08;Domain）、應(yīng)用層（Application）和用戶接口層（User Interface），如圖所示。

領(lǐng)域建模是一種藝術(shù)，融合了分析階段和設(shè)計(jì)階段，目的是使復(fù)雜的軟件快速應(yīng)付變化。Evans DDD 拋棄了分裂分析模型與設(shè)計(jì)的做法，使用單一模型滿足這兩方面的要求，該單一模型就是領(lǐng)域模型。領(lǐng)域模型同時滿足分析原型和程序設(shè)計(jì)，如果一個模型在實(shí)現(xiàn)時不具備可行性，就需要重新尋找新的模型，如果該模型沒有忠實(shí)表達(dá)領(lǐng)域的關(guān)鍵概念，則也必須重新尋找新的模型。所以，領(lǐng)域建模的過程把分析和設(shè)計(jì)階段變成了單個的循環(huán)階段，把分析和設(shè)計(jì)緊密聯(lián)系起來，使領(lǐng)域建模專家不再只關(guān)注需求概念的收集，也關(guān)注程序代碼的設(shè)計(jì)與實(shí)現(xiàn)。

5

? ?

面向?qū)ο蟮姆治龊驮O(shè)計(jì)

面向?qū)ο蠓治雠c設(shè)計(jì)是指根據(jù)面向?qū)ο蠓椒▽W(xué)對軟件系統(tǒng)進(jìn)行分析與設(shè)計(jì)。

在面向?qū)ο蠓治雠c設(shè)計(jì)的定義中有三個關(guān)鍵詞：面向?qū)ο蟆⒎治龊驮O(shè)計(jì)。所以，為了更好地理解面向?qū)ο蠓治雠c設(shè)計(jì)的作用，我們首先要理解什么是面向?qū)ο?#xff0c;以及面向?qū)ο蠓治龊兔嫦驅(qū)ο笤O(shè)計(jì)的原則。

5.1

? ?

什么是面向?qū)ο?/strong>

面向?qū)ο笫菍ΜF(xiàn)實(shí)世界進(jìn)行理解和抽象的方法，是計(jì)算機(jī)編程技術(shù)發(fā)展到一定階段后產(chǎn)生的一種軟件開發(fā)方法，具有抽象、封裝、繼承、多態(tài)等特征，還沉淀出設(shè)計(jì)原則和設(shè)計(jì)模式的智慧結(jié)晶。我們可以使用一張圖來更為形象地展現(xiàn)面向?qū)ο笏婕皟?nèi)容之間的關(guān)系，如圖所示。

5.2

? ?

面向?qū)ο蟮奶卣?/strong>

封裝：把對象的屬性和方法結(jié)合成一個獨(dú)立的整體，隱藏實(shí)現(xiàn)細(xì)節(jié)，并提供對外訪問接口，被封裝的對象通常被稱為抽象數(shù)據(jù)類型。我們通常將變化的內(nèi)容封裝起來，就可以在不影響其他部分的情況下修改或擴(kuò)展被封裝的部分。封裝變化是所有設(shè)計(jì)模式的基礎(chǔ)，用于提供程序的可擴(kuò)展性。

繼承：從已知的某個類中派生出一個新的類，將這個新的類叫作已知的這個類的子類，已知的這個類就是這個新的類的父類。子類繼承了父類的所有非私有化屬性和方法，并能根據(jù)自己的實(shí)際需求擴(kuò)展出新的行為。繼承實(shí)現(xiàn)了代碼的重用，因此也提供了系統(tǒng)的重用性和擴(kuò)展性；但是繼承破壞了封裝性，因?yàn)樗菍ψ宇愰_放的，修改父類會導(dǎo)致所有子類的改變。因此繼承在一定程度上破壞了系統(tǒng)的可擴(kuò)展性，因此優(yōu)先使用組合而不是繼承是面向?qū)ο箝_發(fā)中的一個重要經(jīng)驗(yàn)。

多態(tài)：同一操作作用于不同的對象，可以有不同的響應(yīng)，產(chǎn)生不同的執(zhí)行結(jié)果。接口的多種不同的實(shí)現(xiàn)方式通常被稱為多態(tài)。接口是對行為的抽象，主要目的是為不相關(guān)的類提供通用的處理服務(wù)，比如鳥會飛，但是飛機(jī)也會飛，我們可以讓鳥和飛機(jī)都實(shí)現(xiàn)飛這個接口，這樣就實(shí)現(xiàn)了系統(tǒng)的可擴(kuò)展性。

抽象：表示在對問題領(lǐng)域進(jìn)行分析、設(shè)計(jì)中得出的抽象概念，是對一系列看上去不同但本質(zhì)相同的具體概念的抽象。它其實(shí)就是一個過程，是一個提煉事物之間共同擁有的元素的過程，而這些事物之間共同擁有的元素往往是這一事物區(qū)別于其他事物的關(guān)鍵內(nèi)容，這些元素就構(gòu)成了事物的本質(zhì)。所以，抽象作為面向?qū)ο蟮幕A(chǔ)，也是面向?qū)ο蟮谋举|(zhì)或者說是面向?qū)ο蟮暮诵摹?/p>

5.3

? ?

面向?qū)ο笤O(shè)計(jì)的原則

為了設(shè)計(jì)出一個好的系統(tǒng)架構(gòu)，就必須遵照一定的規(guī)則，而衡量軟件設(shè)計(jì)質(zhì)量的首要標(biāo)準(zhǔn)就是該設(shè)計(jì)能否滿足軟件的功能需求。除了功能需求，還有很多衡量軟件設(shè)計(jì)質(zhì)量的標(biāo)準(zhǔn)，主要包括高內(nèi)聚、低耦合、可擴(kuò)展和可復(fù)用。

高內(nèi)聚：指每個模塊盡可能獨(dú)立完成自己的功能，不依賴模塊外部的代碼。一個軟件模塊由相關(guān)性很強(qiáng)的代碼組成，只負(fù)責(zé)一項(xiàng)任務(wù)，也就是常說的單一責(zé)任原則。

低耦合：一個設(shè)計(jì)良好的系統(tǒng)，模塊與模塊之間應(yīng)該盡可能獨(dú)立存在，模塊與模塊之間的接口應(yīng)該盡量少而簡單，也就是說，讓每個模塊盡可能獨(dú)立完成某個特定的子功能。模塊與模塊之間的聯(lián)系越復(fù)雜，耦合度便越高，會導(dǎo)致牽一發(fā)而動全身。如果某兩個模塊間的關(guān)系比較復(fù)雜，則最好先考慮進(jìn)一步的模塊劃分。

可擴(kuò)展：用于應(yīng)對更大規(guī)模的業(yè)務(wù)及軟件的成長，通常采用動態(tài)加載的插件、回調(diào)函數(shù)、抽象接口及認(rèn)真設(shè)計(jì)的代碼結(jié)構(gòu)和類層次結(jié)構(gòu)，使系統(tǒng)在面對不斷變化的需求時，其代碼不被大量重構(gòu)開發(fā)，比如添加新功能或修改完善現(xiàn)有功能。

可復(fù)用：又叫作重用，即重復(fù)使用，可以利用已有的代碼或者相關(guān)模塊去實(shí)現(xiàn)新的功能需求，從而得到較高的生產(chǎn)效率及隨之而來的低成本和高質(zhì)量。

之間的聯(lián)系，最后用面向?qū)ο蟮恼Z言實(shí)現(xiàn)這種客體及客體之間的聯(lián)系，它們之間的關(guān)系如圖所示。

回顧前面介紹的將大象放入冰箱的例子，我們?nèi)绾问褂妹嫦驅(qū)ο笏枷雽?shí)現(xiàn)這個例子呢？首先，找出現(xiàn)實(shí)世界中的動作和實(shí)體：1、打開冰箱；2、將大象放入冰箱；3、關(guān)閉冰箱。然后，抽象出概念：1、冰箱、可以打開門、可以存儲、可以關(guān)門；2、大象、體重、體積。最后，用計(jì)算機(jī)中的類來實(shí)現(xiàn)該邏輯關(guān)系，這樣就有了 elephant 和 fridge 兩個類。

面向?qū)ο蟮拇a實(shí)現(xiàn)如下所示：

雖然面向?qū)ο笃鸪鯇Ｖ冈诔绦蛟O(shè)計(jì)中采用封裝、繼承、多態(tài)、抽象等設(shè)計(jì)方法，然而現(xiàn)在它已經(jīng)滲透到軟件開發(fā)的各個方面，比如面向?qū)ο蟮姆治?#xff08;OOA）、面向?qū)ο蟮脑O(shè)計(jì)（OOD）和面向?qū)ο蟮木幊?#xff08;OOP）等環(huán)節(jié)，其各環(huán)節(jié)的職責(zé)如下。

6

? ?

小結(jié)

程序員的成長路線大體是在管理線和技術(shù)線上形成突破，當(dāng)然也有結(jié)合起來相得益彰的。而技術(shù)上的追求，架構(gòu)師則是一個重要的門檻，對于剛?cè)胄械某绦騿T可能會認(rèn)為架構(gòu)師就是畫架構(gòu)圖的，誠然架構(gòu)師很重要的一個職責(zé)是繪制架構(gòu)圖，但這只是其中一個很小的環(huán)節(jié)而已。

實(shí)際上架構(gòu)也只是系統(tǒng)設(shè)計(jì)里面的一個重要環(huán)節(jié)，除了架構(gòu)還包含了商業(yè)訴求，業(yè)務(wù)建模，系統(tǒng)分析，系統(tǒng)設(shè)計(jì)等重要領(lǐng)域。下一篇會講解如何從服務(wù)角度進(jìn)行業(yè)務(wù)分析，敬請期待！

推薦閱讀

微服務(wù)架構(gòu)最強(qiáng)講解，通俗易懂，寫得太好了！

2021-06-21