面向對象架構設計流程

時間 2019-11-20

標籤面向對象架構設計流程欄目軟件設計简体版

原文原文鏈接

1. 引言

架構設計，一個看起來很牛B的名詞....程序員

架構設計師，一個很牛B的職位.....架構

在絕大部分公司裏，架構師就是技術人員的終極方向，是技術金字塔的頂端。工具

因此，當咱們看到一個架構師或者聽到一個架構師的名字時，是否是會情不自禁的肅然起敬，心底油然的產生一股敬意？性能

在不少人眼裏，架構就相似於藝術家，他們擁有非凡的才華，創造了一個個優秀的產品，並受到人們的尊敬，成爲了行業大牛，今後走向人生的巔峯！優化

但架構設計真的就這麼神祕和神奇嗎？咱們這些普通人難道就註定和架構設計無緣了？架構設計

實際上，沒有什麼神祕和神奇，也不須要具有藝術家的才華，只要掌握適當的方法，一步一步的逐步完善，菜鳥也可以作架構設計。設計

2. 面向對象架構設計流程

架構設計實際上是「面向對象」的思想的具體應用而已，那我麼來看看如何以面向對象的思想來指導架構設計。參考「面向對象技術流程」的作法，咱們一樣也總結出一個「面向對象架構設計流程」，把架構設計分爲幾個環環相扣的步驟：業務架構——領域架構——軟件架構。對象

2.1業務架構設計

和「用例模型」相似，主要用於描述客戶的業務整體結構。與「用例模型」不一樣的是，業務架構更抽象，更高一層，只關注總體的業務流程，不關注具體的業務需求細節，不須要考慮異常處理、替代處理等場景。圖片

2.2 領域架構設計

和「領域模型」相似，主要用於從「業務架構」中提取出來「領域架構」，爲後面的進一步架構設計作準備。開發

2.3 軟件架構設計

和「設計模型」相似，基於「領域架構」，應用架構設計原則和方法，精雕細琢，逐步迭代，得出最終的軟件架構。

有了這同樣的一個流程，原來看來頗具藝術色彩的架構設計，其實就變成了一個標準化的加工過程，只要循序漸進，一步一個腳印，即便是菜鳥，也能夠作出一架構。

但也千萬別認爲架構設計就垂手可得了，就像一樣的岩石、一樣的模型，不一樣的雕塑家獲得最後的做品也會相差很遠同樣，架構設計流程只是保證咱們可以作出一個可用的架構，是否可以作出一個優秀的架構，與架構師的水平、經驗有很大的關係，既須要架構有必定的創造天分，又須要架構師有深厚的積累。

3. 架構設計實例

3.1 全新的業務系統

在中國神話中，盤古大神開天闢地，在盤古開天闢地以前，天地不分，沒有山河湖川、風雨雷電.....世界處於一片混沌狀態！而對於架構來講，剛開始面向的也是一種混沌的狀態。

由於，咱們面對的也是一堆客戶提的需求，看到只是一篇或多篇文字描述的需求文檔，運氣好的話，需求文檔可能會條理清晰、邏輯清晰;運氣很差的話，也許這些文檔雜亂無章。有時候，甚至一篇像樣的文檔都沒有，只是簡單的幾句描述性的話。

無論怎麼樣，咱們都須要從無到有創造出一個架構，而咱們所擁有的只是客戶需求，多是通過分析的，也多是最原始的。

怎麼辦？

拍腦殼拍出一個？這跟猴子調皮敲鍵盤敲出《莎士比亞全集》的概念可能差很少。找個藝術家來創造？可是藝術家卻不懂計算機。隨便畫幾個圓圈再加幾條線？畫得不對怎麼辦？冥思苦想，看起來是沒有辦法了，但有句話說的好「驀然回首，那人卻在燈火闌珊處」，其實咱們忘記了最重要需求來源：客戶需求。

你必定會驚訝:客戶需求裏面有架構？這不是在忽悠嗎？前面還說需求可能雜亂無章，怎麼這裏就說客戶需求裏面有架構？

由於，無論什麼架構，最終都是要實現業務需求，不能天馬行空地創做，不能脫離業務範疇去作架構設計，而是要受到業務的約束，借用如今互聯網流行的一句話:情懷落不了地，就是矯情。無論是條理清晰仍是雜亂無章的需求，架構的雛形都隱藏在裏面，咱們須要的是透過紛繁複雜、千絲萬縷的需求來發現它，而這也是架構師的價值所在。

咱們知道，即便客戶不提需求給咱們，客戶的系統也已經在運做，這不是由是否使用計算機決定的，而是客戶的業務領域決定的。

舉個簡單的例子，美國第一條鐵路誕生於1830年，至今已經走過200年的發展歷程了;紐約證券交易所成立於1863年，至今已經接近150年了;而第一臺可以進行復雜運算的計算機於1940年才製造出來。

那麼在計算機誕生以前，難道美國鐵路系統和紐約交易證券所就不能運轉了嗎？顯然不是這樣的，在計算機誕生以前，美國鐵路系統和紐約證券交易所確定也是一個完整的可運行的業務系統，可以知足人們的相關需求。

計算機只是一個工具而已，能讓客戶的業務系統更加高效，更加智能、更加快速地運行，但毫不是計算機創造了客戶業務系統。所以，架構設計最初的來源就是「客戶業務系統」。

怎麼知道客戶業務系統呢？最簡單的方法固然是問客戶了。

有的人可能以爲這個太簡單了，還想知道是否還有其它更加牛B的方法。

事實上這是最簡單可是最有效的方法，也是最不會出問題的方法，雖然不牛B！

由於客戶的系統是客觀存在的，是已經通過實踐檢驗和驗證可行的系統，你不可能幫客創造出來另一套業務系統;並且，客戶的系統客戶最瞭解了，客戶是最好的信息來源。

也許你會說，若是有類似的業務系統，我照搬過來稍作修改是否能夠呢？

看來很不錯，只要找個相似的系統，微創造一把就能夠了，省時，省力又簡單！

但誰能保證你所理解的類似就是和客戶業務系統一致呢？誰也不能保證，所以，類似的系統只能作參考，不能照搬。咱們只能站在巨人的肩膀上，但不能將巨人搬走。

固然，不少時候架構師面對的並非最終的客戶，而是公司的市場人員或者需求分析人員，這時候最好的方法固然是問"需求分析"人員了。

在理想狀況下，優秀的需求分析人員對客戶業務系統瞭然於胸，有時候甚至比客戶還要更加清楚，由於爲了理解業務系統，需求分析人員可能須要和客戶的各類人員交流(例如經理、員工等)，獲取的信息更加全面。

固然，碰到不理想的狀況，需求分析人員對客戶的業務系統不瞭解，那麼也很簡單：提出你的問題，讓需求分析人員向客戶瞭解清楚。

幸運的是，大部分客戶的業務系統已經自然的分爲幾個部分了。咱們能夠簡單的舉幾個例子(只是爲了簡單說明，實際的客戶業務系統應該比這個複雜多了，僅做參考)。

沃爾瑪:至少包括"倉管"、"物流"、"店面"、"支付"等幾個部分。
中國鐵路售票系統：至少包括"訂票"、"查票"、"支付"等幾個部分。
一個網店業務系統：至少包括"商品"、"訂單"、"客服"等幾個部分。

架構的最初雛形就是源自於客戶的業務系統，簡單地說，最初的架構設計就是對客戶業務系統的模擬！所以，咱們不需求天才的創造能力，也不須要擁有藝術家的才華，只須要掌握一個很是重要技巧「問客戶」，就可以獲得最初的架構雛形了。

3.2 已有的架構優化

除了全新的建立一套系統外，還存在另外的一種狀況：已經有了一套系統，但客戶不滿意，提出了新的需求或者更高的需求。這種狀況其實很簡單，新架構的基礎就是架構，而後在已有架構上設計出新的架構。

你也許會擔憂這樣作的話，新架構是否會受限於已有的架構？

這裏關鍵是要看客戶提出的新需求或者更高要求是否改變了客戶的業務系統，若是是，則可能須要建立一套全新的系統;若是隻是對已有的系統進行加強或者調整，則在原有架構上進行調整便可。

幸運的是，不多客戶會直接提出一個顛覆性的需求或改變，緣由很簡單，客戶業務系統變動也是按部就班的，顛覆性的變化，客戶的業務代價也會很是大！

4. 業務架構實例

假設在一個未知的星球上，有電視，電話機，但就是沒有電腦，如今咱們要在這個星球上建立一個電視購物商城，名叫「星球商城」，則星球商城的業務架構能夠簡化以下：

星球商城在電視上投放商品廣告;
客戶經過看電視，獲取商品信息;
客戶打電話給商城的客戶人員下訂單;
商城的客服人員收到訂單後，客戶人員打電話給倉庫管理員下出貨單;
倉庫管理員生成出貨單，安排物流人員送貨;
客戶收到貨後，支付款項給物流人員;
物流人員收到款項後，將出貨單和款項交給結算中心結算;
結算中心確認發貨單和款項無誤後，記錄訂單，訂單完成;

通過上面的簡單例子咱們能夠看出，就算沒有電腦，這個未知的星球上的商城依然能夠正常運轉。雖然這個例子比較簡單，但已經基本上將一個電視購物商城的業務架構描述清楚了。

須要注意的是，業務架構和用例模型同樣，其實也是用文字進行描述，但比用例模型更加的抽象，也不須要關注各類異常或者分支處理流程，只須要關注描述業務的總體結構便可。

和需求分析是咱們須要關注需求的「結束和限制」同樣，業務架構除了關注業務自己的流程外，也須要包含業務的結束和限制。

以商城爲例，咱們能夠獲得商城架構的一些業務結束和限制：

性能：每秒可以處理10萬個訂單;
成本：整套方案預算不超過10000萬元;
可靠性：可靠性99.999%，整年中斷服務時間爲5分鐘;
技術性：必須用JAVA技術;
兼容性：必須與公司的其它系統兼容;

千萬別小看這些看似簡單的結束和限制，它們在架構設計的過程當中起着很是重要的做用，由於它們是架構迭代的驅動力。若是說知足業務的功能需求是基本要求，那麼知足業務的約束和限制則需求才是合格的架構。

5. 領域架構實例

有了客戶的業務系統後，咱們只須要稍微提煉下，就能夠獲得一個領域架構。具體的提煉方法以下：

提取業務模塊
肯定業務模塊之間的關係

以上面的商城爲例，咱們能夠這樣提煉業務模塊。

星球商城在電視上投放商品廣告，提煉爲「廣告」。
客戶經過看電視，獲取商品信息，提煉爲「商品」。
客戶打電話給商城的客戶人員下訂單，提煉爲「訂單」
商城的客服人員收到訂單後，客戶人員打電話給倉庫管理員下出貨單，倉庫管理人員生成出貨單，提煉爲「倉庫」。
倉庫管理員生成出貨單，安排物流人員送貨，倉庫管理人員生成出貨單，安排物流人員送貨，提煉爲「物流」。
客戶收到貨後，支付款項給物流人員，提煉爲「支付」。
物流人員收到款項後，將出貨單和款項交給結算中心結算，結算中心確認發貨單和款項無誤後，記錄訂單，訂單完成，提煉爲「結算」。

提取業務模塊後，咱們再提煉業務模塊間的關係，例如：

「廣告」模塊、「訂單」模塊、「倉庫」模塊都須要從「商品」模塊獲取「商品信息」。
「訂單」模塊下單給「倉庫」模塊。
「倉庫」模塊生成出貨單給「物流」模塊，「倉庫」模塊還須要將訂單信息同步到「結算」模塊。
「物流」模塊將出貨單和款項給「結算」模塊。

有了以上的分析和提煉，咱們就能夠獲得這樣一個簡單的領域架構，以下圖所示：

6. 軟件架構實例

5.1 第一步：照貓畫虎

有了業務架構後，接下來就是最關鍵的一步：從業務架構轉換到軟件架構。雖然這是最關鍵的一步，但有了領域架構後，咱們的工做就容易多了，甚至有點容易得讓人難以想象，咱們只須要在領域架構的基礎上將各個模塊映射爲子系統便可。例如：將"訂單"模塊映射爲「訂單子系統」，將「物流」模塊映射爲「物流子系統」 ......彷佛咱們啥都沒幹，就是加了「子系統」三個字。領域架構映射爲初始的軟件架構圖以下圖所示：

不過，咱們千萬別小看這麼一個簡單的步驟，加上「子系統」三字後，咱們就知道設計哪些相關的軟件子系統了，初始的軟件架構就基本造成了，是否是很神奇呢？

這樣的架構是否足夠了呢？不少人可能都會馬上說：「這樣確定不行」架構設計怎麼會這麼簡單呢 ......但實際上這個架構在某些場景下是可行的。例如，咱們天天只須要處理100個訂單，那麼這個架構足夠了；每一個子系統都是一個獨立的軟件，每一個子系統都部署在一臺機器上，這樣是徹底可行的。

可是更多的場景下這個架構就不可行了。例如：咱們每秒須要處理10萬訂單，那麼上面提到的「一臺機器」+「一個軟件」顯然是撐不住的，由於單臺機器、單個軟件系統的處理能力達到每秒10萬個是很難的(若是大型機之類的機器，處理性能會高一些，但也是有系統瓶頸的)；又例如，咱們須要系統的宕機時間一年不超過5分鐘，那麼「一臺機器」+「一個軟件」的架構顯然也支持不了，由於單臺機器一旦出現故障，換臺機器從新部署修復不止5分鐘，也就是說存在單點故障的問題。

綜合上面的描述能夠看到，同一個架構，有的場景可行，但有的場景不可行，那麼實踐中究竟如何判斷架構是否可行呢？

其實也沒有什麼玄機，就是看架構是否知足業務需求，但須要注意的是這裏的業務需求包含兩部分：功能需求和質量需求。只有同時知足這兩類需求才算是可行的架構方案。

按照這個標準來衡量，咱們能夠發現這個架構雖然知足了商城的功能需求，可是不能知足商城的質量需求，包含性能和可靠性都沒法知足，由於這是一個不合格的架構。爲了使最終的架構可以知足業務質量的需求，咱們還得須要繼續努力(革命還沒有成功，同志仍需努力 )。

5.1 第二步：按圖索驥

有了領域架構映射過來的初始軟件架構，業務的功能需求已經可以知足了。可是，業務的質量需求可能還沒法知足，所以第二其實就是爲了設計出可以知足業務質量需求的架構。

業務需求質量屬性有不少，例如：「性能」、「可靠性」、"成本"等，這麼多的質量屬性咱們如何下手呢？很簡單，哪裏不足就從哪裏下手。

咱們仍是以上面的商城爲例，在實始的軟件架構中「訂單子系統」沒法知足每秒處理10萬個訂單的需求，那麼咱們就須要從這個點入手，看看如何可以知足這個性能需求。

一種很直觀的方法就是增長機器。例如，咱們能夠用10臺機器來完成「訂單子系統」的功能，那麼每臺機器每秒只須要處理1萬個訂單，這個數據是合理的；若是還擔憂有問題，那麼幹脆設計20臺機器來完成「訂單子系統」的功能，這樣每臺機器每秒只須要處理5000個訂單，基本上是沒有問題了。最終的架構圖以下所示：

另一種方法就是將「訂單子系統」再拆分爲更多的子系統。例如，咱們能夠將「訂單子系統」再拆分爲「接單子系統」和「下單子系統」、「商品查詢子系統」，每一個子系統再按照業務質量的屬性去評估，若是不知足則繼續按照「哪裏不足就從哪裏下手」的思路和原則進一步的設計。好比，通過拆分後咱們發現「接單子系統」在一臺機器的狀況下仍是沒法滿「每秒處理10萬個訂單」的需求，那麼也能夠將「接單子系統」設計爲10臺機器來完成功能；考慮到「下單子系統」能夠慢慢處理「接單子系統」生成的訂單，「下單子系統」就繼續使用一臺機器完成便可；「商品查詢子系統」也是相似的。最終的架構圖以下所示：

以上樣例只是爲了知足性能需求而採起的方法，其實無論是什麼質量屬性，基本上都有一套比較成熟和固定的架構模式，這就是「按圖索驥」步驟的由來——識別不知足質量需求，找到這個質量需求對應的架構模式，質量需求就「圖」，架構模式就是「驥」。

第二步看起來很簡單，但實際上有兩個隱藏的假設條件在裏面。

架構師可以判斷在初始架構中哪裏可能不知足需求 好比上面的樣例中，架構師知道一臺機器沒法知足每秒處理10萬個訂單的，可是能夠每秒處理5000個訂單；而普的開發人員不必定知道這個限制。
架構師知道有哪此架構模式能夠解決咱們遇到的問題 好比上面的樣例中，架構師須要知道能夠經過添加機器來知足性能需求，或者拆分系統來知足性能需求。要作到以上兩點，沒有放之四海皆準標準作法，而主要是依靠架構師的經驗和積累，並且同一個架構師的經驗和積累，換個行業可能就徹底不適應了。由於是依靠經驗和積累，因此架構師會以爲這些作法是理所固然，順手拈來；但對於一個則入門的程序員來講，就會以爲架構師很牛B、很厲害。

5.3 第三步：深思熟慮

到目前爲止，咱們的架構設計一直是順風順水的，沒有遇到什麼挑戰和困難，但若是覺得架構設計真的這麼簡單就太天真了，前面的各個步驟都是準備工做，真正的挑戰從這一步開始——萬里長征，始於足下。「

那麼具體是什麼擋路呢？這個步驟的名稱「深思熟慮」已經很好的歸納了兩個挑戰：「深思」和「熟慮」的具體含義以下： - 深思：全面評估各個備選方案的優缺點 - 熟慮：挑選最優的方案

5.3.1 深思：評估方案

在第二步」按圖索驥「中，咱們以商城爲例，給出了兩個高性能的解決方案，但在實踐中確定不可能兩個方案都作一遍，只能挑選其中的一個方案來實施。那麼問題來了：高性能的方案如何選擇？哪一個方案強？

若是單純從高性能的角度來評估兩個方案，兩個方案都可以知足高性能的需求，那是否意味着咱們像抓鬮同樣，隨便選一個就能夠了呢？

這個老是就涉及了架構設計的第一個難點：如何評價方案的優劣？

抓鬮是確定不行的，憑感受和碰運氣差很少，憑經驗有點虛，沒有把握，有沒有一種方法既可以有理有據，又可以簡單易行呢？

有，這就是方案」360「度評估，或者叫」綜合評價「。具體的方法爲：評估方案的多個質量屬性，而後進行選擇。

這裏咱們仍是以商城爲例，對比兩個高性能的架構方案，以下表所示：

注：以上表格能夠根據須要添加更多的對比維度，此處只是爲了簡單起見只對比了5個維度。有了以上這樣一個「360度評估」表格，方案的優劣點一目瞭然，咱們不再用瞎猜、瞎蒙或碰運氣了，真正作到了「有理有據，簡單易行」。

5.3.2 熟慮：挑選方案

咱們雖然可以從「360度評估」表格一目瞭然地看到各個方案的優劣點，但這樣一個表格也只能幫助咱們分析各個備選方案，仍是沒有告訴咱們具體選擇哪一個方案。那麼如何選擇方案是否也有「有理有據，簡單易行」方法呢？。

這個問題就涉及了架構設計的第二難點：如何選擇方案？

有人可能看到「360度評估」表格，可能會覺得「哪一個方案優勢多就選擇哪一個方案」。這樣確實很簡單，但實際操做並不徹底可行。緣由一是一樣的質量屬性，不一樣的業務和團隊要求不同。好比上面表格中的」成本「和」複雜性」兩個質量屬性，若是是外包公司可能很是注重成本，而互聯網公司更加的注重業務的迭代速度；緣由二就是有時候可能會出現兩方案的優缺點個數都是同樣的，好比上面表格中的方案1和方案2，在這種狀況下沒辦法分出勝負。

既然不能簡單地以數學運算來決定方案的優劣，那咱們就須要找到更靠譜的方法。這個方法就是「按優先級選擇」，即：優先選擇咱們最關注的質量屬性表現佔優的方案，若是兩個方案在最關注的質量屬性上表現一致，那麼就繼續比較其它關注的質量屬性，以此類推，最後挑選出符合咱們心意的方案。

按照這個方法，即便是外包公司也能夠優先選擇「成本低」的方案，而互聯網公司也能夠優先選擇「複雜度」低的方案1。

直到這一步，咱們纔算最終的肯定了架構的方案。