echo編輯整理，歡迎轉載，轉載請聲明文章來源。歡迎添加echo微信(微信號：t2421499075)交流學習。
基礎架構需要遵循什麼？設計產品架構應該需要考慮哪些因素？功能的完整性、效率、安全性、可擴展性？設計架構並不是越完美越好，越是完美的架構投入就越是高昂。在我們實際的市場應用中，我們可以看到很多的項目，基本沒有太多的考慮，先滿足業務需求，然後盡力使用最低的成本，這樣做的架構是符合標準規範的架構嗎？這算是一個悖論，市場選擇。存在既是合理。
基礎架構設計原則
- 合適原則
真正優秀的架構都是企業在當前人力、條件、業務等各方面約束條件下設計出來的，能夠合理地將資源整合一起併發揮出最大功效，並且能迅速落地。這也是很多BAT出來的架構師到了小公司或者創業團隊反而做不出成績的原因，因爲沒有大公司的平臺、資源、積累，只是生搬硬套大公司的做法，失敗的效率非常高。不管是什麼樣的需求，市場對應的現有資源是肯定能找到對應的，但是資源並不一定是你所掌握的，所以很多公司的第一考慮是先實現目的，這也是我們看到了很多的簡單的，有些缺陷的架構應用在快速的出現。
- 簡單原則
無論是結構的複雜性還是邏輯的複雜性，都會存在各種問題，這個原則跟合適原則是有很多融合性的。每一個公司的開發人員能力差異較大，合適的原則下儘可能的簡單化，這樣有助於大大的減少開發成本，對人員的要求相對來說就低了，即使人員流動也不會造成沒有人能夠接手的尷尬局面。
- 演化原則
系統架構一步到位明顯是不合理的，一般來說只要具備一定的架構能力，就能完成一些基礎的架構建設。整體來說，在一段時間內如果不是致命的架構漏洞，應該是不會有大變動或者重構的。所以我們不需要去一步到位，特別是對於互聯網公司來說，項目方向需要能夠快速掉頭，這就需要我們對架構不斷的進行改進。即使沒有很多業務上的大變更，系統架構也應該是一步一步完善，補充我們的當前架構不足的地方。
框架第一原則：高內聚低耦合原則
軟件設計中通常用耦合度和內聚度作爲衡量模塊獨立程度的標準。劃分摸塊的一個準則就是高內聚低耦合。那麼什麼是高內聚低耦合？耦合度是指模塊之間聯繫的緊密程度。當我們設計架構的時候，我們會發現，我們會對系統進行分模塊。但是怎麼分模塊？功能？數據庫？業務模型？都算是劃分依據，但是模塊之間的依賴度也是我們重要的衡量標準。舉個簡單的例子，我們創建一個訂單模塊，同時創建一個商品模塊，如果我們每一次訪問訂單的時候都要去訪問商品模塊，那是不是相對來說這樣分模塊反倒還整加了系統交互時間？
開閉原則、依賴倒置原則等是不是架構設計原則？
很多網上的第一架構原則就是開閉原則、依賴倒置，並且有很多的文章大肆的在寫這類原則規範架構設計。其實這些設計原則都是架構設計之一，架構設計原則很多很多，我們上面描述的基礎架構設計原則是比較廣泛的思維，而開閉原則、依賴倒置原則等是更具體的原則規範。在架構設計前期，我們並不需要太多的去關注那麼多的設計原則，合適、簡單就好，這也是爲什麼本文一上來就講基礎架構設計原則。
架構設計公認度很高的幾大原則
- 開閉原則
- 依賴倒置原則
- 單一職責原則
- 接口隔離原則
- 迪米特法則（最小知道原則）
- 里氏替換原則
- 合成/聚合複用原則
開閉原則
開閉原則就是說對擴展開放，對修改關閉。在多數公司裏面，項目基本不是隻進行一次開發，而是不斷迭代。如果我們公司裏面有個項目，假若項目主打文章發佈，突然業務轉型希望做視頻，那是不是意味着我們就直接把文章改成視頻？肯定不是的，而是不僅支持文章發佈，同事新增視頻功能。
依賴倒置原則
依賴倒置原則的本質就是通過抽象(接口或抽象類)使各個類或模塊的實現彼此獨立，不互相影響，實現模塊間的松耦合。
單一職責原則
對象不應承擔太多功能。一個對象到底是用於數據庫交互還是用於返回前端的應該分開使用
接口隔離原則
其實通俗來理解就是，不要在一個接口裏面放很多的方法，這樣會顯得這個類很臃腫
迪米特法則
也叫最少知識原則，當前對象本身、當前對象的成員對象、當前對象所創建的對象、當前對象的方法參數等，這些對象存在關聯、聚合或組合關係，可以直接訪問這些對象的方法
里氏替換原則
里氏替換原則是針對繼承而言的，如果繼承是爲了實現代碼重用，也就是爲了共享方法，那麼共享的父類方法就應該保持不變，不能被子類重新定義。子類只能通過新添加方法來擴展功能，父類和子類都可以實例化，而子類繼承的方法和父類是一樣的，父類調用方法的地方，子類也可以調用同一個繼承得來的，邏輯和父類一致的方法，這時用子類對象將父類對象替換掉時，當然邏輯一致，相安無事。
合成/聚合複用原則
儘量使用對象組合，而不是繼承來達到複用的目的