方案架構師是負責系統架構以及特定產品的技術標準(包括技術、平臺、基礎架構)的專家。他們為產品設定前景，他們的分析也是產品的定義、設計、交付和永久支持的成功關鍵。因此，構架師不僅需要了解業務需求，還需要了解符合企業技術總目標的邏輯性、可擴展性及成本效益。

[[276916]]

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

本文將一一介紹這些架構原則。

SOLID五原則

SOLID原則不僅適用于軟件開發，也適用于系統的架構。

單一功能原則

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

開閉原則

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

里氏替換原則

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

接口隔離原則

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

依賴反轉原則

高級模塊不應該依賴于低級模塊，它們都應該依賴于抽象。同樣，抽象不應該依賴于細節，而細節應該依賴于抽象。因此，該原則引入了高層和下層軟件組件或層之間的接口抽象以消除雙方的依賴關系。

“最小”原則

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

最小驚奇原則

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

這一原則適用于架構的每個方面：從命名服務到用戶界面的可視化，再到域模型的設計。

有驚喜也有驚嚇……

最小省力原則

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

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

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

這個原則的偉大之處在于它的效益是可以推斷的：只要把正確的設計放在適當的位置，就可以創建一個架構框架，這將是下一個系統構建的基礎。換言之，就能夠為組織的軟件系統建立一個成功且不過時的模板。

最簡便的道路

經濟學中的原理

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

機會成本原則

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

例如，擺在面前的有兩種選擇，一種是內部構建的系統，另一種是現成的供應商產品，如果選擇后者，那么機會成本就是開發團隊可能會開發出的令人眼前一亮的新系統。

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

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

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

最后責任時刻原則

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

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

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

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

結語

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