方案架構(gòu)師是負責系統(tǒng)架構(gòu)以及特定產(chǎn)品的技術(shù)標準(包括技術(shù)、平臺、基礎(chǔ)架構(gòu))的專家。他們?yōu)楫a(chǎn)品設(shè)定前景，他們的分析也是產(chǎn)品的定義、設(shè)計、交付和永久支持的成功關(guān)鍵。因此，構(gòu)架師不僅需要了解業(yè)務(wù)需求，還需要了解符合企業(yè)技術(shù)總目標的邏輯性、可擴展性及成本效益。

[[276916]]

架構(gòu)師的重要技能之一就是能從許多不同的角度來看待架構(gòu)，因為每一個單獨的角度可能不完全相關(guān)，但結(jié)合在一起就可以從總體的角度來看待產(chǎn)品。這些角度包括原則、標準、模式和反模式、經(jīng)驗法則和經(jīng)驗實踐，而這些對于決策方向確定和項目評估成功至關(guān)重要。

本文將一一介紹這些架構(gòu)原則。

SOLID五原則

SOLID原則不僅適用于軟件開發(fā)，也適用于系統(tǒng)的架構(gòu)。

單一功能原則

每個系統(tǒng)功能(例如服務(wù)/模塊/應(yīng)用界面)應(yīng)該只有一個職責，因此也只有一個變更的理由。盡可能地縮小職責范圍，用戶便會理解其功能，從而減少錯誤的發(fā)生。

開閉原則

這一原則認為，最好在不修改系統(tǒng)操作的情況下對其進行擴展。盡管提前預測需求的變化可能導致過于復雜的設(shè)計，但是能夠以現(xiàn)有組件的最小更改來適應(yīng)新功能是應(yīng)用程序長期使用的關(guān)鍵。

里氏替換原則

在軟件開發(fā)中，這一原則意味著派生類必須可替換為它們的基類，但這一原則與勃蘭特·梅耶的“契約式設(shè)計”關(guān)于如何應(yīng)用于分布式架構(gòu)有著相似之處：兩個服務(wù)在進行多次有效溝通后，它們之間形成一種“契約”,其定義了兩者的輸入/輸出、結(jié)構(gòu)和約束。因此：對于具有相同契約的兩個分布式組件，一個組件應(yīng)該可以替換為具有相同契約的其他組件，而不會改變系統(tǒng)的正確性。

接口隔離原則

接口或契約必須盡可能的細化及特定于客戶，因此調(diào)用客戶端并不依賴于它們不使用的功能。這與單一責任原則相輔相成：通過分組接口，我們提倡通過按角色或責任分離的組成，將派生模塊與不需要的職責分開解耦。

依賴反轉(zhuǎn)原則

高級模塊不應(yīng)該依賴于低級模塊，它們都應(yīng)該依賴于抽象。同樣，抽象不應(yīng)該依賴于細節(jié)，而細節(jié)應(yīng)該依賴于抽象。因此，該原則引入了高層和下層軟件組件或?qū)又g的接口抽象以消除雙方的依賴關(guān)系。

“最小”原則

在下文中，將根據(jù)這些原則的名稱將他們一起來介紹。

最小驚奇原則

最小驚奇原則(或最少意外原則)指的是，當首次發(fā)現(xiàn)某個解決方案或方法時該領(lǐng)域中知識淵博的人不會感到驚訝(受眾可能不同，例如最終用戶、程序員、測試人員等)。更實際地來說，該原則的目的是利用用戶已有的知識，在使用模塊時盡量減少他學習曲線，因此任何具有高不可預測性因素的事物都是用來重新設(shè)計的好選擇。

這一原則適用于架構(gòu)的每個方面：從命名服務(wù)到用戶界面的可視化，再到域模型的設(shè)計。

有驚喜也有驚嚇……

最小省力原則

最小省力原則(也稱為齊夫定律)源于一項人類的基本行為：即每個人都傾向于選擇走盡可能不費力的道路。例如，如果一項設(shè)計遵循于特定的模式，那么下一個開發(fā)人員將一次又一次地遵循這一相同的模式，除非有簡單得多的方法出現(xiàn)，這時開發(fā)人員才會改變這一模式。或者更進一步說，一旦他們找到一項任務(wù)的可接受結(jié)果，就不需要立即改進當前的解決方案。

最省力等同于最少的工作量。

因此，必須通過建立正確的架構(gòu)來實現(xiàn)一個好的開端：即設(shè)定很高的期望值，并確保每個人都明白工作質(zhì)量不能在項目周期中受到影響，并且即使未來發(fā)生變化，質(zhì)量也要得到保證。

這個原則的偉大之處在于它的效益是可以推斷的：只要把正確的設(shè)計放在適當?shù)奈恢茫涂梢詣?chuàng)建一個架構(gòu)框架，這將是下一個系統(tǒng)構(gòu)建的基礎(chǔ)。換言之，就能夠為組織的軟件系統(tǒng)建立一個成功且不過時的模板。

最簡便的道路

經(jīng)濟學中的原理

以上提到的兩個原則有一個共同的主題：即都充分利用了機會成本和推遲決策成本。

機會成本原則

人們每次做選擇時，做出的選擇都會與一定的價值有關(guān)。價值分兩部分：效益和成本。選擇的機會成本是放棄其后才得到的。為了做出一個好的經(jīng)濟決策，我們希望選擇效益最大但成本最低的方案。

例如，擺在面前的有兩種選擇，一種是內(nèi)部構(gòu)建的系統(tǒng)，另一種是現(xiàn)成的供應(yīng)商產(chǎn)品，如果選擇后者，那么機會成本就是開發(fā)團隊可能會開發(fā)出的令人眼前一亮的新系統(tǒng)。

因此，架構(gòu)所要做的就是權(quán)衡不同的選擇，做出明智的決定，為項目爭取最大的價值。例如，一個非常常見的分歧就是，是創(chuàng)建一個戰(zhàn)術(shù)上的解決方案，以便快速推向市場，還是創(chuàng)建一個更具戰(zhàn)略意義的解決方案，雖說現(xiàn)在成本更高一些，但未來成本會降至最低。

以下是一些可供考慮的因素：

• 架構(gòu)分析或評估的可用時間是多少?畢竟提出一個解決方案已經(jīng)非常有挑戰(zhàn)性，更不用說好幾個了!
• 未來1-3年的產(chǎn)品路線是什么?還有什么其他的項目?能看到任何協(xié)同效應(yīng)嗎?
• 目前可能解決的技術(shù)債務(wù)是什么?
• 反過來想：如果尋求一個戰(zhàn)術(shù)解決方案將會產(chǎn)生多少新的技術(shù)債務(wù)?
• 哪些品質(zhì)要素對企業(yè)中的系統(tǒng)最重要?以及它們可能將如何被提議的解決方案所影響?
• 除了架構(gòu)團隊，還有誰是影響決策的利益相關(guān)方?公司?你的老板?技術(shù)設(shè)計部門?每一個利益相關(guān)方的核心目標是什么?如何調(diào)解有沖突的需求?

最后責任時刻原則

這一原則(也稱為延遲成本)源于精益軟件開發(fā)，強調(diào)盡可能長時間地堅持采取重要行動和關(guān)鍵決策。這樣做是為了在最后一刻之前不漏掉重要的備選方案，即縮小選擇范圍，直到得到更全面的信息做出最佳選擇。

這個策略不是過早做出決定，而是推遲決定，直到不做決定的成本大于作出決定的的成本之前，保留重要且不可逆轉(zhuǎn)的決策。

而有一種緩解決策過晚風險的方法是建立概念驗證(POCs)，來原型化備選方案，并向利益相關(guān)者證明他們的需求。

在項目的早期，應(yīng)該盡可能少地做出有約束力的決定!

結(jié)語

架構(gòu)原則可幫助我們評估整個項目中所做的決策，同時確保其不僅符合項目的總體目標，且符合企業(yè)的技術(shù)范圍。下圖集中展示了本文中所闡述的五項原則：