軟件架構設計原則
基本原則
原則1： KISS (Keep it simple,sutpid) 和保持每件事情都儘可能的簡單，用最簡單的解決方案來解決問題。
原則2： YAGNI（你不需要它）原則 ，只在需要時構建
原則3： 先學會爬，然後再學會走，最後學會跑。換句話說，先保證能夠正常運行，然後優化它使其更好，最後逐漸讓它變得完美。使用迭代開發，採用敏捷開發模式。爲每個功能制定一個開發週期（最多2周），然後不斷迭代。
原則4： 自動化測試是構建穩定、高質量產品的唯一方法。通過自動化測試提升創造力，所有一切都可以自動化！在設計時應當好好考慮自動化。
原則5： 注重投資回報率（ROI）並將最多的注意力放在最重要的地方。
原則6： 瞭解用戶並相應地平衡資源。大多數產品都有數千個最終用戶，大致需要20個開發人員和100個 DevOps 人員。不要花費數月的時間來構建一個不太可能使用 DevOps 的用戶界面（他們更喜歡腳本）。這是原則5的特例。
原則7： 功能的設計和測試儘可能獨立。如果在設計時考慮到這一點，長遠來看，它將省去很多麻煩，否則只有一切構建完成時你纔可以開始測試整個系統。此外，遵循這個原則，版本發佈也會更加順利。
原則8： 警惕搜索引擎中花裏胡哨的架構方案。我們天生都喜歡令人奪目的設計。如果你按奈不住， 就可能把太多根本不需要的功能和解決方案引入到你的架構中。
功能選擇
原則9： 想要準確知道用戶如何使用我們的產品是很難的。所以我們要推行MVP（最小可行產品）。該理念的核心在於：先制定一些用例，完成用例所涉及的相關功能，立即發佈產品，然後根據反饋和經驗對產品進行優化。
原則10： 儘可能減少功能，如有疑問則將其刪除。許多功能可能從未使用，你只需爲其留一個擴展接口即可。
原則11： 聽取客戶的意見，看他們想要什麼功能。
原則12： 當客戶要求的功能影響到其他模塊時，要勇於和客戶辯論。從大局出發，嘗試找到另一種方法來處理問題。就像 Fords 所說的那樣“每當我問顧客需要什麼的時候,他們總是會說需要跑得更快的馬”。請記住，你纔是專家。你應該主導一切，做出正確和專業的決定。雖然用戶可能當時有些疑惑，但最終他們會感謝你的。
服務端設計和併發
原則13： 要知道一個server是如何運行的，從硬件到操作系統，直到編程語言。優化IO調用的數量是你通往最好架構的首選之路。
原則14： 遵循 Amdhal 的同步定律。線程之間共享的可變數據會降低程序速度。如果可以，請使用併發數據結構，並且僅在必要時使用同步。儘可能少地使用鎖。如果你打算在線程鎖期間阻塞，請確保自己足夠了解具體細節，因爲這裏存在極大的隱患。
原則15： 如果你的設計是基於事件驅動的非阻塞架構，那就不要阻塞線程或者在線程中執行 IO 操作。一旦這樣做，系統將慢如蝸牛。
分佈式系統
原則16： 無狀態系統具有良好的擴展性。我們要儘可能瞭解和使用無分享架構。
原則17： 除非你能夠掌控客戶端和服務器的所有代碼，否則消息傳遞失敗的情況在所難免。儘量減少你的系統依賴的因素（例如使用原則18）。
原則18： 儘可能實施冪等操作。這樣它就很容易恢復，你至少可以保證交付沒問題。
原則19： 瞭解 CAP 定理。可擴展的事務（分佈式事務）是很難的 。儘可能使用補償，基於 RDBMS 的事務很難擴展。
原則20： 分佈式系統共識不支持擴展，也無法進行組通信，不支持羣集範圍內的可靠消息傳遞。其最大節點限制大約是八個節點。
原則21： 在分佈式系統中，你很難隱藏分佈式系統中的延遲和故障。（參見分佈式計算的謬誤解釋 ）。
用戶體驗
原則22： 瞭解你的用戶以及他們的目標：他是新手、專家還是臨時用戶？他對計算機科學瞭解多少？極客看重擴展功能，開發人員關注示例和腳本，普通人則更在乎界面。
原則23： 最好的產品應當不需要用戶手冊，用戶應該一看就會用。
原則24： 當你無法在兩個選項之間做出決定時，請不要通過配置選項的方式來呈現問題。這會給用戶和架構師帶來麻煩。對於系統如何運作的細節，他們沒有你瞭解，他們怎麼能做出決定呢？最好的方案是找到一個每次都有效的選擇；其次是自動做出選擇；第三個方案是添加配置參數並設置合理的默認值。
原則25： 始終具有合理的配置默認值。
原則26： 設計不良的配置會製造麻煩，始終配置幾個示例值。
原則27： 詢問用戶配置值的時候，注意選擇用戶無需即可設置的值（例如，不要問用戶需要的最大緩存條目數量，而是要問他想要用於緩存的內存數量）
原則28： 如果發現未知配置，則拋出錯誤。永遠不要忽視它。在調試過程中，無提示的配置錯誤會浪費我們很多調式時間。
難點
原則29：嘗試新語言很容易，但要正確使用卻很難。除非公司願意組建一個十人團隊並花一年的時間來學習，否則儘量不要這樣做。如果你仍不死心，請閱讀有關語言設計的五個問題後再做定奪。
原則30： 可組合的拖放 UI 很難實現，除非團隊準備投入10人年的資源，否則不要去做。
原文地址 架構設計的30條設計原則