開工大吉，重溫下架構設計六大原則
今天是正月初七，我還請假在家，剛剛讀了《銀河帝國》，讀到馬洛解決了謝頓危機，成為繼哈里謝頓、賽佛哈定之後的第三位英雄。春節過得還不錯，休息了、陪伴家人了、學習了、思考了。
重溫下架構設計六大原則。
1. 單一職責原則。一個類只能有單一的職責，不同的類各司其職。如果一個類有兩個及以上的職責，說明設計有問題，對業務、架構、模型、擴充套件的認識有盲區。與 DDD 思想類似，設計程式碼必須有確定性、有明確的邊界，擴充套件一下就是 DDD 中的子域劃分。
2. 開放封閉原則。對擴充套件開放，對修改封閉。這裡可以有兩種實現方式，一種是用繼承或組合的方式來擴充套件類的功能而不直接修改類的程式碼，另一種是使用策略模式通過新的策略定製業務實現而不修改原來的程式碼。開放封閉必然涉及到邊界，邊界以內是封閉的，邊界以外是可以（非必然）開放的。
3. 里氏替換原則。繼承、多型的更高層次的理解，使用介面、父類來傳遞引用，實際執行時可以是父類例項也可以是子類例項。這個原則是實現開閉原則的重要方式之一，使用非常普遍，只要有足夠的抽象，就一定無法避免。
4. 最少知識原則/迪米特法則。通俗說，知道的越多，死的越快，不多問、不多想、不多說。在程式碼中，任何知識的傳遞都會引入新的複雜性，比如需要加入參、加依賴。上層在業務範圍內儘量少感知底層實現，底層也不要想那麼多非要去了解外面的邏輯。
5. 介面隔離原則。一個類與另一個類之間的依賴性，應該依賴於儘可能小的介面。不依賴不需要的介面，有利於程式碼的長期維護和重構。大的介面要根據用途拆分成小介面，小介面的方法數量也要好好考慮，和單一職責、最少知識有點相似。
6. 依賴倒置原則。這個原則非常有用，能夠指匯出架構核心的設計，尤其是對流程的抽象。spring IOC 就是典型的依賴倒置，程式碼可以有依賴，但是執行時到底是哪個例項，程式碼沒有必要關心。在架構核心的抽象開發中，依賴倒置是最重要的原則，只有這樣才能進行足夠的抽象和沉澱，才能讓業務進行擴充套件。
以上 6 個原則，有一個共同點，就是高內聚低耦合，滿足 6 個原則能夠設計出穩定可靠的架構。不過這是參考，具體落地還要具體情況具體分析。