山哥新作：架构师必备技能之业务分析
1
? ?
業務分析
業務分析是應用系統的思想和方法，把復雜的需求分解成簡單的對象，找出這些對象的基本屬性以及彼此之間的關系，系統分析也是系統開發中最重要、也是最困難的階段，最終的架構設計也要依據業務分析的結果，運用合理的思想和方法，才能設計出滿足逾期的系統架構，由此可見系統的分析和設計是程序員進階中最重要的能力，是產品需求到編碼實現過程中最重要的手段。
2
? ?
黃金圈法則
人人都知道自己是做什么的，有些人知道自己是怎么做的，但極少一部分人知道自己為什么這么做，這就是很著名的黃金圈法則，也叫作 2W1H 分析法。黃金圈法則源于知名廣告人 Simon Sinek 的發現，是由“為什么（Why）、怎么做（How）、做什么（What）”三部分組成的由內到外的思維方式，如圖所示。
黃金圈法則的三個層次與人腦的三個皮層精確對應，如圖所示。人腦最外層為新皮質，負責理性思維分析和語言；中間層和最里層為邊腦，負責情緒和行動，比如信任和忠誠，以及行為和決策。人們通過理智對外界信息和過往經歷進行搜集與整理，傳達給情緒，情緒影響直覺，直覺產生行動，而感覺則是直覺的直接反應，預示著如何行動。所以從外到內溝通時，通過說明“做什么”能夠幫助我們理解大量的復雜信息，利用的是理性思維，它擅長分析，但不會促使人采取行動。但從內到外溝通時，是直接對應控制決策過程的。
如果將黃金圈法則對應工作的話，則：大部分人都知道做什么，能使用技術將工作做好，通常處于執行層；而有些人知道怎么做，具有組織、管理和協調能力，通常處于管理層；而只有極少一部分人知道為什么做，能夠制定戰略、目標和計劃，具有宏觀把控能力，通常處于決策層。企業中的執行層、管理層和決策層就形成了我們的人才金字塔，如圖所示
所以，我們通過黃金圈法則能夠解釋為什么一些組織者或領導者能夠在別人覺得不可能的地方激發出靈感和潛力，表現出卓越的天賦。那么，程序員如何從被動接收任務的執行層，發展成為具備系統分析和架構設計能力的決策層呢？有什么方法或捷徑可循嗎？答案之一是對 UML 建模工具的熟練運用，因為程序員除了需要具備寫代碼的能力，還需要具備凌駕于編程語言之上的能力，即系統分析與設計的能力，UML 就是用于系統分析和設計的一種工具。
3
? ?
業務分析和設計的方法
現在，用戶的需求越來越復雜，變化也越來越快，如果仍然通過需求管理、需求跟蹤等管理方式來約束和減少需求頻繁變更對軟件開發帶來的沖擊，則會導致軟件開發變得僵硬，程序員更加疲憊。另外，用戶的需求通常來自某個專業領域，比如法律、財務或電子商務等，每個特定的需求又有其特別復雜之處，所以幾乎沒有人能夠第一時間抓住這些專業領域的需求本質。因此，用戶的需求在歷經幾次演變之后變得面目全非，每一個加工制造環節都以為做“正確的事”。
在現實工作中，這樣的局面一再上演，比如，產品經理在宣講 PRD（Product Requirement Document，產品需求文檔）時，需要將專業名詞使用通俗的業務語言翻譯給業務方，還要使用技術語言翻譯給開發人員，這就很容易導致各方信息不對等，業務方的理解和技術人員的理解可能完全不一致。
因此，聰明的工程師們引入了靈活多變的面向對象分析與設計（OOAD）方法。面向對象分析與設計方法對復雜需求的解決方法是：委派專業建模專家跟蹤理解需求，并在需求和需求之間搭建橋梁。
注意：面向對象分析與設計被拆分為系統分析和系統設計兩部分，我們國家還專門有“系統分析師”和“系統設計師”兩種職稱考試。這樣拆分的結果就是對需求分析的結果無法直接進行設計和編程，而能夠運行的代碼扭曲需求，導致客戶在運行軟件后才發現很多功能不是自己想要的，而且軟件不能快速跟進需求的變化。
雖然面向對象分析與設計的思想帶給分析和設計很大的靈活性，也對軟件開發產生了前所未有的影響，但有一定的局限性：面向對象分析與設計主要關注微觀層次的抽象，比如類和對象實例等；每個問題域通常都需要創建單獨的用例分析模型，項目或產品的大方向在許多情況下變得很模糊，很難全局把控系統的總目標，所以這樣的系統分析與設計方式存在很大的風險。
面向對象分析與設計的局限性，催生了面向服務分析與設計（SOAD）方法，它有效地彌補了面向對象分析與設計的局限性。同時，面向服務的架構（Service-Oriented Architecture，SOA）也走進了大眾的視野并很快流行起來。
面向服務分析與設計并不是一種全新的分析與設計方式，只不過是從不同的抽象角度去設計一種業務模型。面向對象分析與設計可以說是一種自底向頂的設計方式，雖然面向對象的方法比起早期面向過程的方法有了很大的改進，但是放到復雜的商業邏輯里面，面向對象就顯得遠遠不夠，需要從更高的層次分解商業邏輯，所以才需要面向服務分析與設計。在做面向服務分析與設計時，首先會分離出業務流程和服務，再在這個基礎上細化對象，這就是一種自頂向底的方法。面向對象分析與設計與面向服務分析與設計的抽象關系如圖所示。
那么，面向服務分析與設計就是最好的了嗎？它又有什么局限性呢？
眾所周知，軟件開發的流程通常為需求、分析、設計、開發、集成測試和交付部署。不管是在面向對象分析與設計中還是在面向服務分析與設計中，系統的分析和設計都是分開的、割裂的，即分析人員從領域中收集基本的業務概念，系統設計人員再將基本的業務概念映射為相應的編程工具的構造組件。在這個過程中，由于分析和設計的模型不同，導致在分析和設計之間形成一條鴻溝，如圖所示。
2004 年，著名建模專家 Eric Evans 出版了其最具影響力的著名書籍 Domain Driven-Design architecture，其中提出的領域驅動設計（DDD）方法打破了分析和設計割裂的狀態，并給出了領域模型的概念，拋棄了將分析與設計分開的做法，通過使用統一的模型來滿足分析和設計的需求，使系統開發能夠更加靈活、快速地響應需求的變化。
注意：DevOps 的出現又進一步填平了開發和部署之間的鴻溝，值得注意的是，任何新技術或概念的提出都不是憑空想象的，都是為了應對人們在生活和工作中遇到的瓶頸。架構師也需要具備發現系統中存在的瓶頸并給出相應解決方案的能力。
4
? ?
系統分析與設計的三個發展階段
下面講講系統分析與設計的三個發展階段。
4.1
? ?
面向數據的分析與設計
圍繞數據庫驅動的分析與設計可以說是系統分析與設計的第一階段。軟件設計總是從設計數據庫及其字段開始的，這一階段的特征就是圍繞數據庫編程，應用系統是典型的兩層架構：分為界面層（User Interface）和數據庫層（DataBase）。該階段的典型技術為 Delphi 和 VB 等。
這種圍繞數據庫的分析與設計方法導致了過程化的編程思維，因為數據庫結構由 DBA 設計后交由程序員編寫大量的 SQL 語句實現，而 SQL 語句執行是有先后順序的，所以程序員大多養成了面向過程的思維方式，長此以往成了習慣就難以改變。
面向過程（Proceduce Oriented）是一種思維方式，在面對一個問題時，我們通常先關注解決這個問題的步驟，即過程。比如對于如何將大象裝入冰箱這個問題，我們想到的步驟是：第 1 步，打開冰箱；第 2 步，裝入大象；第 3 步，關上冰箱。這就是典型的面向過程的思維方式，雖然這樣更加直接、有效地可以完成問題，但是當面對更復雜的問題時，解決問題的過程會變得非常復雜和難以理解。同樣，圍繞數據庫驅動的分析與設計有以下明顯缺點。
不能迅速、有效、全面地認識反映和需求，在這種分析與設計思維中，世界不僅由簡單的關系數據組成，還使用關系數據庫反映現實需求，這不符合人類的自然思維，是一種扭曲的分析方法。
系統的性能很難提升，容易導致軟件運行時負載集中在數據庫端，使系統變成集中式和高風險的大型單體模式（Monolithic），喪失分布式集群處理能力。
面向對象編程語言和關系型數據庫本身是矛盾的，因為關系型數據庫分析與設計本身是面向過程的思維（這一矛盾在當今的實現中依然存在，不過在領域驅動設計中已有解決方案）。
4.2
? ?
面向對象和服務的分析與設計
隨著系統的復雜度越來越高，面向過程的問題也越來越突顯，因此誕生了具有劃時代意義的面向對象分析和設計方法，應用系統也變成了經典的三層架構模式：界面層（User Interface layer）、業務邏輯層（Business Logic Layer）和數據訪問層（Data access layer），如圖所示。
此時出現獨立進行分析和設計的兩個階段，系統分析和設計開始上升到一個相對更高的層次，擁有自己的一套科學且藝術的方法論，但也帶來了一個致命的缺點，分析階段和設計階段不能很好地銜接，出現了難以逾越的鴻溝。因為分析人員負責從需求領域中收集基本概念，而設計人員負責指明一組能在項目中適應編程工具構造的組件，這些組件必須能夠在目標環境中有效執行，并能夠正確解決應用程序出現的問題。可以看到，分析與設計這兩個階段的目標并不一致，分析人員只關注需求分析，并不關心是否適合設計或者能否導出適合設計的分析結果；而設計人員因為要照顧程序代碼實現的可行性，因此可能抱怨分析人員給出的結果過于粗糙，不適合設計，于是分析與設計兩個階段嚴重分裂，最終可能導致整個項目的失敗。
另外，在分析和設計兩個階段雖然都使用了 UML，但是 UML 不是思想方法，只是一種分析與設計工具。假若將 UML 類比為 CAD 繪圖軟件，那么會 CAD 的繪圖員就是建筑師嗎？很顯然不是。所以 UML 不是銀彈，更不等價于分析與設計方法。
4.3
? ?
面向問題域的分析與設計
問題域模型有一個最流行的名字：領域模型，領域模型是一種概念模型，是對領域內的概念類或現實世界中對象的可視化表示。領域模型也成為概念模型、領域對象模型和分析對象模型。
Eric Evans 在 2004 年發表了 Domain-Driven Design –Tackling Complexity in the Heart of Software 的論文，主題便是領域驅動設計，還提出領域模型的分層架構，將整個系統劃分為基礎設施層（Infrastructure）、領域層（Domain）、應用層（Application）和用戶接口層（User Interface），如圖所示。
領域建模是一種藝術，融合了分析階段和設計階段，目的是使復雜的軟件快速應付變化。Evans DDD 拋棄了分裂分析模型與設計的做法，使用單一模型滿足這兩方面的要求，該單一模型就是領域模型。領域模型同時滿足分析原型和程序設計，如果一個模型在實現時不具備可行性，就需要重新尋找新的模型，如果該模型沒有忠實表達領域的關鍵概念，則也必須重新尋找新的模型。所以，領域建模的過程把分析和設計階段變成了單個的循環階段，把分析和設計緊密聯系起來，使領域建模專家不再只關注需求概念的收集，也關注程序代碼的設計與實現。
5
? ?
面向對象的分析和設計
面向對象分析與設計是指根據面向對象方法學對軟件系統進行分析與設計。
在面向對象分析與設計的定義中有三個關鍵詞：面向對象、分析和設計。所以，為了更好地理解面向對象分析與設計的作用，我們首先要理解什么是面向對象，以及面向對象分析和面向對象設計的原則。
5.1
? ?
什么是面向對象
面向對象是對現實世界進行理解和抽象的方法，是計算機編程技術發展到一定階段后產生的一種軟件開發方法，具有抽象、封裝、繼承、多態等特征，還沉淀出設計原則和設計模式的智慧結晶。我們可以使用一張圖來更為形象地展現面向對象所涉及內容之間的關系，如圖所示。
5.2
? ?
面向對象的特征
封裝：把對象的屬性和方法結合成一個獨立的整體，隱藏實現細節，并提供對外訪問接口，被封裝的對象通常被稱為抽象數據類型。我們通常將變化的內容封裝起來，就可以在不影響其他部分的情況下修改或擴展被封裝的部分。封裝變化是所有設計模式的基礎，用于提供程序的可擴展性。
繼承：從已知的某個類中派生出一個新的類，將這個新的類叫作已知的這個類的子類，已知的這個類就是這個新的類的父類。子類繼承了父類的所有非私有化屬性和方法，并能根據自己的實際需求擴展出新的行為。繼承實現了代碼的重用，因此也提供了系統的重用性和擴展性；但是繼承破壞了封裝性，因為它是對子類開放的，修改父類會導致所有子類的改變。因此繼承在一定程度上破壞了系統的可擴展性，因此優先使用組合而不是繼承是面向對象開發中的一個重要經驗。
多態：同一操作作用于不同的對象，可以有不同的響應，產生不同的執行結果。接口的多種不同的實現方式通常被稱為多態。接口是對行為的抽象，主要目的是為不相關的類提供通用的處理服務，比如鳥會飛，但是飛機也會飛，我們可以讓鳥和飛機都實現飛這個接口，這樣就實現了系統的可擴展性。
抽象：表示在對問題領域進行分析、設計中得出的抽象概念，是對一系列看上去不同但本質相同的具體概念的抽象。它其實就是一個過程，是一個提煉事物之間共同擁有的元素的過程，而這些事物之間共同擁有的元素往往是這一事物區別于其他事物的關鍵內容，這些元素就構成了事物的本質。所以，抽象作為面向對象的基礎，也是面向對象的本質或者說是面向對象的核心。
5.3
? ?
面向對象設計的原則
為了設計出一個好的系統架構，就必須遵照一定的規則，而衡量軟件設計質量的首要標準就是該設計能否滿足軟件的功能需求。除了功能需求，還有很多衡量軟件設計質量的標準，主要包括高內聚、低耦合、可擴展和可復用。
高內聚：指每個模塊盡可能獨立完成自己的功能，不依賴模塊外部的代碼。一個軟件模塊由相關性很強的代碼組成，只負責一項任務，也就是常說的單一責任原則。
低耦合：一個設計良好的系統，模塊與模塊之間應該盡可能獨立存在，模塊與模塊之間的接口應該盡量少而簡單，也就是說，讓每個模塊盡可能獨立完成某個特定的子功能。模塊與模塊之間的聯系越復雜，耦合度便越高，會導致牽一發而動全身。如果某兩個模塊間的關系比較復雜，則最好先考慮進一步的模塊劃分。
可擴展：用于應對更大規模的業務及軟件的成長，通常采用動態加載的插件、回調函數、抽象接口及認真設計的代碼結構和類層次結構，使系統在面對不斷變化的需求時，其代碼不被大量重構開發，比如添加新功能或修改完善現有功能。
可復用：又叫作重用，即重復使用，可以利用已有的代碼或者相關模塊去實現新的功能需求，從而得到較高的生產效率及隨之而來的低成本和高質量。
之間的聯系，最后用面向對象的語言實現這種客體及客體之間的聯系，它們之間的關系如圖所示。
回顧前面介紹的將大象放入冰箱的例子，我們如何使用面向對象思想實現這個例子呢？首先，找出現實世界中的動作和實體：1、打開冰箱；2、將大象放入冰箱；3、關閉冰箱。然后，抽象出概念：1、冰箱、可以打開門、可以存儲、可以關門；2、大象、體重、體積。最后，用計算機中的類來實現該邏輯關系，這樣就有了 elephant 和 fridge 兩個類。
面向對象的代碼實現如下所示：
雖然面向對象起初專指在程序設計中采用封裝、繼承、多態、抽象等設計方法，然而現在它已經滲透到軟件開發的各個方面，比如面向對象的分析（OOA）、面向對象的設計（OOD）和面向對象的編程（OOP）等環節，其各環節的職責如下。
在需求分析階段采用面向對象的分析方法，這個階段不需要思考怎么用程序實現它，只需要思考和分析需求中穩定不變的客體都是些什么，這些客體之間的關系又是什么，以及完成概要建模。
在設計階段采用面向對象的設計方式，把在第 1 步分析出來的需求通過進一步擴充模型，變成可實現的、符合成本的、模塊化的、低耦合高內聚模型。
在編程開發階段采用面向對象的編程語言來具體實現前一個階段得到的業務模型。
6
? ?
小結
程序員的成長路線大體是在管理線和技術線上形成突破，當然也有結合起來相得益彰的。而技術上的追求，架構師則是一個重要的門檻，對于剛入行的程序員可能會認為架構師就是畫架構圖的，誠然架構師很重要的一個職責是繪制架構圖，但這只是其中一個很小的環節而已。
實際上架構也只是系統設計里面的一個重要環節，除了架構還包含了商業訴求，業務建模，系統分析，系統設計等重要領域。下一篇會講解如何從服務角度進行業務分析，敬請期待！
推薦閱讀
微服務架構最強講解，通俗易懂，寫得太好了！
2021-06-21
標簽類目體系的價值與意義
2021-06-18
程超：突破瓶頸！如何不斷的提高自己
2021-06-17
資深架構師手把手教你性能優化
2021-06-07
李偉山：金融撮合架構
2021-05-31
阿里專家晨末：什么是技術一號位？
2021-07-08
資深架構專家聊架構之道：規劃、簡化和演化
2021-07-01
淺談云原生架構的 7 個原則
2021-07-23
資深架構師十幾年的架構干貨經驗總結分享！
2021-07-19
總結
以上是生活随笔為你收集整理的山哥新作：架构师必备技能之业务分析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： hdu -4284 Travel(状态压
- 下一篇： hdu-1438 钥匙计数之一