圖片來源: yourspear.com
方案架構師是負責系統架構以及特定產品的技術標準（包括技術、平臺、基礎架構）的專家。他們為產品設定前景，他們的分析也是產品的定義、設計、交付和永久支持的成功關鍵。因此，構架師不僅需要了解業務需求，還需要了解符合企業技術總目標的邏輯性、可擴展性及成本效益。
架構師的重要技能之一就是能從許多不同的角度來看待架構，因為每一個單獨的角度可能不完全相關，但結合在一起就可以從總體的角度來看待產品。這些角度包括原則、標準、模式和反模式、經驗法則和經驗實踐，而這些對於決策方向確定和項目評估成功至關重要。
本文將一一介紹這些架構原則。
SOLID五原則
SOLID原則不僅適用於軟件開發，也適用於系統的架構。
單一功能原則
每個系統功能（例如服務/模塊/應用界面）應該只有一個職責，因此也只有一個變更的理由。儘可能地縮小職責範圍，用戶便會理解其功能，從而減少錯誤的發生。
開閉原則
這一原則認為，最好在不修改系統操作的情況下對其進行擴展。儘管提前預測需求的變化可能導致過於複雜的設計，但是能夠以現有組件的最小更改來適應新功能是應用程序長期使用的關鍵。
里氏替換原則
在軟件開發中，這一原則意味著派生類必須可替換為它們的基類，但這一原則與勃蘭特·梅耶的“契約式設計”關於如何應用於分佈式架構有著相似之處：兩個服務在進行多次有效溝通後，它們之間形成一種“契約”,其定義了兩者的輸入/輸出、結構和約束。因此：對於具有相同契約的兩個分佈式組件，一個組件應該可以替換為具有相同契約的其他組件，而不會改變系統的正確性。
接口隔離原則
接口或契約必須儘可能的細化及特定於客戶，因此調用客戶端並不依賴於它們不使用的功能。這與單一責任原則相輔相成：通過分組接口，我們提倡通過按角色或責任分離的組成，將派生模塊與不需要的職責分開解耦。
依賴反轉原則
高級模塊不應該依賴於低級模塊，它們都應該依賴於抽象。同樣，抽象不應該依賴於細節，而細節應該依賴於抽象。因此，該原則引入了高層和下層軟件組件或層之間的接口抽象以消除雙方的依賴關係。
“最小”原則
在下文中，將根據這些原則的名稱將他們一起來介紹。
最小驚奇原則
最小驚奇原則（或最少意外原則）指的是，當首次發現某個解決方案或方法時該領域中知識淵博的人不會感到驚訝(受眾可能不同，例如最終用戶、程序員、測試人員等)。更實際地來說，該原則的目的是利用用戶已有的知識，在使用模塊時儘量減少他學習曲線，因此任何具有高不可預測性因素的事物都是用來重新設計的好選擇。
這一原則適用於架構的每個方面：從命名服務到用戶界面的可視化，再到域模型的設計。
有驚喜也有驚嚇……
最小省力原則
最小省力原則（也稱為齊夫定律）源於一項人類的基本行為：即每個人都傾向於選擇走儘可能不費力的道路。例如，如果一項設計遵循於特定的模式，那麼下一個開發人員將一次又一次地遵循這一相同的模式，除非有簡單得多的方法出現，這時開發人員才會改變這一模式。或者更進一步說，一旦他們找到一項任務的可接受結果，就不需要立即改進當前的解決方案。
最省力等同於最少的工作量。
因此，必須通過建立正確的架構來實現一個好的開端：即設定很高的期望值，並確保每個人都明白工作質量不能在項目週期中受到影響，並且即使未來發生變化，質量也要得到保證。
這個原則的偉大之處在於它的效益是可以推斷的：只要把正確的設計放在適當的位置，就可以創建一個架構框架，這將是下一個系統構建的基礎。換言之，就能夠為組織的軟件系統建立一個成功且不過時的模板。
最簡便的道路
經濟學中的原理
以上提到的兩個原則有一個共同的主題：即都充分利用了機會成本和推遲決策成本。
機會成本原則
人們每次做選擇時，做出的選擇都會與一定的價值有關。價值分兩部分：效益和成本。選擇的機會成本是放棄其後才得到的。為了做出一個好的經濟決策，我們希望選擇效益最大但成本最低的方案。
例如，擺在面前的有兩種選擇，一種是內部構建的系統，另一種是現成的供應商產品，如果選擇後者，那麼機會成本就是開發團隊可能會開發出的令人眼前一亮的新系統。
因此，架構所要做的就是權衡不同的選擇，做出明智的決定，為項目爭取最大的價值。例如，一個非常常見的分歧就是，是創建一個戰術上的解決方案，以便快速推向市場，還是創建一個更具戰略意義的解決方案，雖說現在成本更高一些，但未來成本會降至最低。
以下是一些可供考慮的因素：
· 架構分析或評估的可用時間是多少？畢竟提出一個解決方案已經非常有挑戰性，更不用說好幾個了！
· 未來1-3年的產品路線是什麼？還有什麼其他的項目？能看到任何協同效應嗎？
· 目前可能解決的技術債務是什麼？
· 反過來想：如果尋求一個戰術解決方案將會產生多少新的技術債務？
· 哪些品質要素對企業中的系統最重要？以及它們可能將如何被提議的解決方案所影響？
· 除了架構團隊，還有誰是影響決策的利益相關方？公司？你的老闆？技術設計部門？每一個利益相關方的核心目標是什麼？如何調解有衝突的需求？
圖片來源: What is opportunity cost
最後責任時刻原則
這一原則（也稱為延遲成本）源於精益軟件開發，強調儘可能長時間地堅持採取重要行動和關鍵決策。這樣做是為了在最後一刻之前不漏掉重要的備選方案，即縮小選擇範圍，直到得到更全面的信息做出最佳選擇。
這個策略不是過早做出決定，而是推遲決定，直到不做決定的成本大於作出決定的的成本之前，保留重要且不可逆轉的決策。
而有一種緩解決策過晚風險的方法是建立概念驗證（POCs），來原型化備選方案，並向利益相關者證明他們的需求。
在項目的早期，應該儘可能少地做出有約束力的決定！
結語
架構原則可幫助我們評估整個項目中所做的決策，同時確保其不僅符合項目的總體目標，且符合企業的技術範圍。下圖集中展示了本文中所闡述的五項原則：
我們一起分享AI學習與發展的乾貨
編譯組：沈田、孫夢琪
相關鏈接：
https://towardsdatascience.com/5-key-principles-of-software-architecture-e5379cb10fd5
閱讀更多 讀芯術 的文章
