架構設計的幾點思考

軟件架構的意義

軟件架構的意義是什麼，有不少不一樣的理解和爭議，這裏不想就軟件架構的意義給出完整的定義，而是想聊聊其中的一點：軟件架構是溝通 (Architecture is communication)，關於軟件架構的更多意義，建議參考這篇別人的舊文。

爲何軟件架構意味着溝通呢？由於軟件工程自己是一個組織一羣人爲了一個問題進行創造性勞動的過程，由於軟件工程自己的特色，因此溝通的重要性是軟件工程區別於傳統工程的一個顯著特色。關於這一點，我以前的帖子已經解釋過，這裏再也不展開。

什麼樣的架構有利於溝通呢？

在回答這個問題以前，咱們先來看一張圖。

若是汽車設計師經過這張圖來向其餘人解釋汽車是什麼的時候，我想除了相關的專家不會有人可以輕易理解每一個部件在整個汽車中的用途，以及他們是如何在一塊兒工做的。

爲何呢？在《金字塔原理》這本書裏提到，人一次可以理解的思想或者概念的數量是有限的，因此若是須要表述一個複雜的思想時，須要經過金字塔的結構來組織整個表述。回到軟件架構來講，其道理是相似的，爲了讓咱們的架構設計更好地讓你們理解，能夠經過一個金字塔的形式來組織咱們的架構設計，事實上咱們也是這麼作的。

因此下圖可能可以讓咱們更加容易理解一輛車是如何組織的（這張圖也來自網絡，不徹底匹配本文，見諒）

軟件架構中的具體問題

從上面的例子以及咱們實際的經驗來看，金字塔型的結構確實是一個很是有效的溝通組織方式，那具體應用到軟件架構來講，有哪些具體的問題和解決思路呢？

何時須要拆分？

軟件架構設計中常常碰到的一個問題就是，何時須要拆分，包括分紅不一樣的模塊，應用或者系統？關於這個問題，很難找到一個直接的答案，可是咱們能夠側面來回答這個問題，也就是團隊組織是否須要拆分。我的的建議是要考慮的是問題的複雜度和人之間的關係，當一個問題的複雜度大到一個小團隊（參考亞馬遜的two-pizza team理念）都沒法承接的時候，咱們須要考慮將其拆分紅多個系統或應用，當一個問題的複雜度大到一個工程師在平常工做中沒法承載的時候，則應該拆分紅不一樣的模塊或應用。由於現實中問題的規模自己就是模糊的，因此這裏沒有明確的量化指標，具體的拆分還須要考慮複雜度之外的因素，這裏只是強調一下，拆分的原則是須要首先考察問題的複雜度。

要不要引入抽象層？

關於引入抽象層的時機，須要從兩個角度來考慮，一方面是須要放在一塊兒討論的事物或者概念的數量大於普通人所能接受的範圍時（神奇的數字7±2），咱們可能須要考慮抽象層。
另一方面就是當明顯不在同一個抽象層面的事物擺在一塊兒討論的時候，好比說下面就是一個錯誤的例子：

發動機 車架 底盤 輪胎 示廓燈
一個簡單的判斷標準就是看看這些事物可否按照同一條規則來分類，而且共同組成高一層的抽象概念，若是不能的話，每每就是咱們把不一樣層面的事物擺到了同一個抽象層面上。

何時共享？

共享或者說複用是軟件工程師最喜歡的概念之一，可是實際上不少時候咱們想複用卻複用不了，或者複用自己帶來了比較大的成本。複用的關鍵因素在於對於問題和解決方案適當抽象，具體來講一方面咱們須要確保解決問題所須要的能力都能經過抽象接口(interface)展現出來，也就是說接口的能力必須是完整的，同時這個抽象可以屏蔽掉無關的細節，也就是儘量地簡化。

因爲實際的問題錯綜複雜，而且咱們在描述問題的時候有不少模糊的名詞，因此一個常見的誤區在於咱們一般會混淆兩個看起來相似可是有不一樣實質的問題，好比汽油發動機和柴油發動機雖然只差了一個字，可是其結構和原理是徹底不一樣的。這個例子雖然很好理解，可是實際工做中咱們卻仍是會由於名字相近就把不一樣的問題放到一塊兒去考慮，這裏就不展開了。

通常來講，當咱們可以清楚而精確地定義一個問題的時候，就是一個產品可能被共享的時候。在考慮一個產品是否能被共享的時候，咱們不要被問題域的名詞所迷惑，必定要從其對應的抽象模型，包括具體的行爲方式和特性來肯定兩個問題的實質是否同一個問題，兩個問題可否真正使用同一套模型來描述和解答。

問題的核心和邊界

咱們的一個常見的作事方式就是求大求全，卻沒有清晰的關於問題核心和邊界的概念，經常突破產品所在的抽象層次，看起來是帶來了更多的能力，實質上倒是破壞了整個架構的設計，模糊了各個概念的邊界。因爲潛在使用者沒法理解這樣的組件對應的問題，同時也擔憂其潛在的複雜邏輯關係，致使了這樣的組件反而很難被複用。

我以爲在軟件設計的過程當中，咱們必定要想清楚問題的核心是什麼，邊界是什麼。爲了解決一個問題，咱們所須要的最小的抽象模型是什麼？在服務化的架構理念裏，當咱們可以給出一個儘量簡單而有效的服務時，才更有可能在更廣闊的場景下使用這個服務。

業務架構和技術架構？

在我看來，須要咱們討論的問題的是業務架構，或者說從服務化(SOA)的角度來講，咱們更多地要考慮的是問題域和問題所對應的解決方案。這裏所說的業務，不徹底是整個公司對外提供的產品，也包括每一個服務自身的對其餘服務和產品輸出的能力。換句話說，當一個團隊明確了一個須要解決的問題的時候，這個問題就是就是這個團隊的業務，而這個問題的解決方案的模型和表述，就是咱們的軟件架構自己。

至於咱們經常談到的技術架構，在我看來不少時候是一個比較模糊的概念，不少時候咱們的技術架構僅僅是對於中間件和數據庫技術的選擇，當咱們所須要解決的問題以及相應的方案都基本肯定的時候，具體技術方案的選擇相對來講是爭議比較小的部分，這樣的技術架構沒有太多須要討論的內容。對於另一些技術架構，同時包含對於技術棧和系統邏輯關係的描述，後者大多均可以融合到咱們的軟件(業務)架構設計中去。

由於菜鳥業務的複雜性，如今已經很難有人可以對於全部的組件都有比較深刻的瞭解，而每一個業務線的同窗都會對本身所在的業務線有更加深入的理解，因此我建議技術部架構委員會更多地能夠關注以下幾個問題：

• 如何讓同窗們給出比較合理的問題模型和相應的系統架構，而非具體某個產品的系統架構
• 處於抽象層次上層的架構，也就是說重點關注和討論大的系統分工和邊界
• 系統和服務複雜度的合理性，包括團隊規模的合理性

本文做者：行易

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。