軟件體系架構基于一組適用于各種軟件系統的基本原則，有經驗的架構師知道這些原則，并且能夠在軟件產品的正確位置實現特定的原則。下面我們快速瀏覽一下架構師日常遵循的基本原則。

1. 依賴倒置（Dependency Inversion）

這一原則表明依賴的方向應該是抽象的，而不是具體實現。如果編譯時依賴在運行時執行的方向上流動，就形成了直接依賴。通過依賴倒置，可以反轉依賴控制的方向。下面的文章更深入的討論了這一原則：

https://medium.com/p/de6abf20e423

2. 關注點分離（Separation of Concerns）

這一原則指出，軟件系統應該按照所做的工作類型來劃分。比方說可以按照業務邏輯、基礎設施或用戶界面劃分為不同的部分。通過將系統劃分為基于不同活動區域的不同部分，使得開發/測試/部署更加容易。SoC是軟件架構模式（如領域驅動設計、六邊形架構、整潔架構）背后的驅動力。

3. 控制反轉（Inversion of Control）

該原則類似于依賴倒置原則，但適用于更廣泛的背景。IoC反轉了由不同的第三方框架（如Spring Framework）管理的控制流。與傳統Java EE程序（由開發工程師按程序初始化Beans）不同，Spring控制Bean的配置，這意味著控制倒置。

4. 依賴注入（Dependency Injection）

該原則意味著依賴應該在運行時通過構造函數注入。在下面的例子中，Action Interface通過HumanAction Implementation注入到Human類中，從而決定在運行時實現哪個特定的動作。這種技術提供了控制依賴的靈活性：

packageaz.alizeynalli.di;

publicinterfaceAction{
voiddo();
}

publicclassHumanActionimplementsAction{

@Override
publicvoiddo(){
System.out.print("run");
}
}

publicclassHuman{

Actionaction;

publicHuman(Actionaction){
this.action=action;
}

@Override
publicvoiddo(){
actoin.do();
}
}

publicstaticvoidmain(String[]args){
Humanhuman=newHuman(newHumanAction);
human.do();
}

5. 單一職責（Single Responsibility）

該原則的主要思想是限定軟件系統的每個構建塊只承擔唯一的責任。無論構建塊的作用域是什么，是插件、包、類、函數，甚至是變量，應該只有一個職責。這篇文章更深入的討論了這一原則：

https://medium.com/p/6b886f6d943e

6. DRY（Don’t Repeat Yourself）

該原則旨在通過避免重復代碼來消除冗余。如果存在針對某些行為的現有功能，則應該重復使用，而不是在多個實例中拷貝相同的代碼片段。

每個知識片段在系統中都必須有單一、明確、權威的表示。

7. 開閉原則（Open-Closed）

軟件構件應該對擴展開放，對修改關閉。

這一原理的簡單描述首先是由Bertrand Meyer提出的。每次都需要修改的軟件系統只會變得一團糟，并且這種混亂的程序很容易在每次修改時出現錯誤。每個新功能都應該最大限度的增加新代碼，最小限度減少舊代碼的更改，理想情況下對舊代碼的更改為零。

8. 持久化透明（Persistence Ignorance）

持久化透明的理念是，代碼應該不受任何數據庫或持久性技術的影響。業務邏輯應該與任何技術無關。如果明天，有更好、更有效、更便宜的持久化技術，應該能夠以不影響上層抽象的方式改變系統的這一部分。

9. YAGNI

You ain’t gonna need it. 這一原則試圖避免軟件系統的過早優化。開發人員通常會在系統中過度設計一些東西，以期在將來的某個時候會有幫助，但這一時刻往往不會到來。

10. 童子軍規則（Boy Scout Rule）

在離開的時候要讓露營地比來的時候更干凈。

這里的主要思想是，當開發時遇到反模式，要堅持重構代碼。隨著時間的推移，這會提高代碼質量。

11. 里氏替換原則（Liskov-Subsititution）

如果對于每個類型為S的對象o1，都有一個類型為T的對象o2，這樣對于用T定義的所有程序P，當o1取代o2時，P的行為不變，那么S就是T的子類型。

Barbara Liskov的這個定義可能聽起來很混亂，但本質上這個原則簡單易懂。如果重述上面的定義，該原則的意思是: 在使用繼承時，繼承的層次結構應該在功能和業務邏輯方面保持一致。子類應該是可以相互替換的，并且不能改變父類的行為。作為一個簡單的例子，可以用“臭名昭著的正方形/矩形”問題。其中正方形不應該是矩形的子類型，因為這兩個幾何形狀的高度和長度的定義是不同的（正方形的高度和長度是相等的，而矩形的高度和長度是不同的）。

12. 封裝（Encapsulation）

軟件系統的不同構建塊應該通過封裝來限制外界對其組件的訪問，可以通過在類范圍內設置組件為私有或在插件范圍內設置訪問限制來實現（就Java而言），從而隱藏信息。

13. 松耦合（Loose Coupling）

軟件架構中最重要的原則之一是松耦合，這一原則表明軟件系統的依賴關系應該松散，系統的一部分發生變化，對其他部分的影響應該最小。松耦合可以通過依賴倒置、異步消息中間件、事件源等實現。下面的文章深入探討了軟件工程中不同形式的耦合：

https://medium.com/p/4d5cf2b3e99e

14. 內聚（Cohesion）

內聚是指模塊內的元素依賴的程度。某種意義上說，是對類的方法和數據以及該類所服務的某種統一目的或概念之間關系強度的度量。

構建高內聚的類是一種最佳實踐，有利于實現單一責任原則、松耦合等。

15. 接口隔離（Interface Segregation）

接口隔離原則指出，不應強迫客戶端依賴不使用的方法。

應該明確的是，這個原則主要適用于靜態類型的編程語言，如Java、C等。在像Python或Ruby這樣的動態類型語言中，這個原則沒有太大意義。

可以想象這樣一種情況，我們的Income和Expense用例都依賴于支持這兩種用例的業務邏輯功能。因此Income用例的很多依賴都和Expense用例相關，而Expense用例的依賴情況也有相同的問題?；谝陨嫌懻摚琁SP違規情況如下：

packageaz.alizeynalli.cashflow.core.service;

publicinterfaceConverterService{
IncomeconvertIncome(Incomeincome);
ExpenseconvertExpense(Expenseexpense);
}

@Component
publicclassExpenseConverterServiceImplimplementsConverterService{

@Override
publicIncomeconvertIncome(Incomeincome){
thrownewUnsupportedOperationException();
}

@Override
publicExpenseconvertExpense(Expenseexpense){
//convertexpensehere
returnexpense;
}
}

@Component
publicclassIncomeConverterServiceImplimplementsConverterService{

@Override
publicIncomeconvertIncome(Incomeincome){
//convertincomehere
returnincome;
}

@Override
publicExpenseconvertExpense(Expenseexpense){

thrownewUnsupportedOperationException();
}
}

16. 限界上下文（Bounded Context）

限界上下文是領域驅動設計的中心模式。通過將大型應用程序或組織分解為單獨的概念模塊，提供了一種處理復雜性的方法。每個概念模塊代表一個上下文，該上下文與其他上下文分離（因此是有邊界的），并且可以獨立發展。理想情況下，每個限界上下文應該可以自由的為其中的概念選擇自己的名稱，并且應該獨占的訪問自己的持久化存儲。

17. 依賴穩定原則（Stable Dependencies）

這一原則指出，軟件系統的不同構建塊應該只依賴于可靠、穩定的工件。這個原則在Docker鏡像術語中更有意義，當我們從docker hub導入不同的依賴時，甚至不知道它們是否可靠/穩定。

18. 多態（Polymorphism）

這實際上屬于面向對象編程的4大支柱，鼓勵使用可以以多種形式提供的接口，多態性意味著具有多種形式的實體。

19. 模塊化（Modularization）

模塊化是將軟件系統劃分為多個獨立模塊的過程，每個模塊獨立工作。這一原則是應用于軟件系統靜態架構的單一職責分離原則的另一種形式。

20. 抽象（Abstraction）

這也屬于面向對象編程的四大支柱:

在研究物體或系統時去除物理的、空間的或時間的細節或屬性以集中注意力于更重要的部分，本質上與泛化過程相似。

21. KISS（Keep It Simple, Stupid）

按照字面意思理解，這一原則激勵工程師保持代碼簡單和愚蠢（容易理解），避免他人誤解。

22. 增量/迭代方法（Incremental/Iterative Approach）

這一原則是敏捷軟件開發宣言的基礎，基于軟件系統應該以增量和迭代的方式開發的思想，每一次迭代都會增加系統功能并保證其運行。

23. 最少知識原則（Least Knowledge）

或者叫信息嫉妒（information envying），是封裝或信息隱藏原則的另一個術語，規定軟件系統的不同部分應該只擁有需要的知識。

審核編輯 ：李倩