1、 架構設計時，需要將軟件的高層業務邏輯與底層的技術實現（如UI、數據庫、I/O操作等）隔離開來。前者較為穩定，后者容易變化。在設計階段，應盡量多地考慮高層的業務邏輯，將涉及技術實現的決策盡量向后推移。
2、 系統應按照用例來划分成不同模塊，因為不同的用例在未來往往有不同的變更時間和變更原因。系統的主要用例應該在其系統結構上清晰可見。用例是描述業務邏輯的，不應涉及用戶接口這樣的細節。
3、 一個良好的軟件架構從邏輯上大致可以分為用例（流程性業務邏輯）、業務實體（原子業務邏輯）、接口適配器（從抽象到具體的橋梁）、框架與驅動程序（具體技術實現）四個層次，底層依賴於上層，而不能反向依賴。
4、 可測試性是軟件的一種重要特性，在軟件設計時就要做充分考慮。測試組件實際上是最下層的程序，依賴於被測試代碼。
5、 一個良好的軟件架構應當能獨立於其所使用的程序框架、數據庫、UI等技術實現細節，並且具有可測試性。
無依賴環原則
循環依賴會導致”一覺醒來綜合征“，導致開發、測試、發布和維護的困難。
采用DIP打破既有組件的循環依賴；或者創建新的組件。
典型的組件結構圖
組件結構圖是不可能自上而下被設計出來的。它必須隨着軟件系統的變化而變化和擴張，而不可能在系統構建的最初就被完美設計出來。
因為組件依賴結構圖並不是用來描述應用程序功能的，它更像是應用程序在構建性與維護性方面的一張地圖。隨着早期被設計並實現出來的模塊越來越多，項目中就逐漸出現了要對組件依賴關系進行管理的需求，以此來預防“一覺醒來綜合征”的爆發。除此之外，我們還希望將項目變更所影響的范圍被限制得越小越好，因此需要應用單一職責原則（SRP）和共同閉包原則（CCP）來將經常同時被變更的類聚合在一起。隨着應用程序的增長，創建可重用組件的需要也會逐漸重要起來。這時CRP又會開始影響組件的組成。
如果我們在設計具體類之前就來設計組件依賴關系，那么幾乎是必然要失敗的。因為，組件依賴關系是必須要隨着項目的邏輯設計一起擴張和演進的。
穩定依賴原則(SDP)
依賴關系必須要指向更穩定的方向。穩定性應該與變更所需的工作量有關。對於軟件來說，帶有許多入向依賴關系的組件是非常難修改的，也就是非常穩定的。一般帶有很多出向依賴的組件是易修改的，也就是非常不穩定的。
I：不穩定性，I=Fan-out/（Fan-in+Fan-out）
Fan-in：入向依賴，這個指標指代了組件外部類依賴於組件內部類的數量。
Fan-out：出向依賴，這個指標指代了組件內部類依賴於組件外部類的數量。
該指標的范圍是[0,1],I=0意味着組件是最穩定的，I=1意味着組件是最不穩定的。
穩定依賴原則（SDP）的要求是讓每個組件的I指標都必須大於其所依賴組件的I指標。
穩定抽象原則(SAP)
一個組件的抽象化程度應該與其穩定性保持一致。
如果一個組件想要成為穩定組件，那么它就應該由接口和抽象類組成，以便將來做擴展。如此，這些既穩定又便於擴展的組件可以被組合成既靈活又不會受到過度限制的架構。
A：抽象程度，A=Na÷Nc。
Nc：組件中類的數量。Na：組件中抽象類和接口的數量。
A指標的取值范圍是從0到1，值為0代表組件中沒有任何抽象類，值為1就意味着組件中只有抽象類。
將SAP與SDP這兩個原則結合起來，就等於組件層次上的DIP。因為SDP要求的是讓依賴關系指向更穩定的方向，而SAP則告訴我們穩定性本身就隱含了對抽象化的要求，即依賴關系應該指向更抽象的方向。
持續補充。。。。。。
出自《架構整潔之道》