軟件體系架構(gòu)基于一組適用于各種軟件系統(tǒng)的基本原則，有經(jīng)驗的架構(gòu)師知道這些原則，并且能夠在軟件產(chǎn)品的正確位置實現(xiàn)特定的原則。下面我們快速瀏覽一下架構(gòu)師日常遵循的基本原則:

1. 依賴倒置(Dependency Inversion)

這一原則表明依賴的方向應(yīng)該是抽象的，而不是具體實現(xiàn)。如果編譯時依賴在運行時執(zhí)行的方向上流動，就形成了直接依賴。通過依賴倒置，可以反轉(zhuǎn)依賴控制的方向。下面的文章更深入的討論了這一原則: How to apply SOLID Software Design Principles to Spring Boot Application (Part 5)[2]

2. 關(guān)注點分離(Separation of Concerns)

這一原則指出，軟件系統(tǒng)應(yīng)該按照所做的工作類型來劃分。比方說可以按照業(yè)務(wù)邏輯、基礎(chǔ)設(shè)施或用戶界面劃分為不同的部分。通過將系統(tǒng)劃分為基于不同活動區(qū)域的不同部分，使得開發(fā)/測試/部署更加容易。SoC是軟件架構(gòu)模式(如領(lǐng)域驅(qū)動設(shè)計、六邊形架構(gòu)、整潔架構(gòu))背后的驅(qū)動力。

3. 控制反轉(zhuǎn)(Inversion of Control)

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

4. 依賴注入(Dependency Injection)

該原則意味著依賴應(yīng)該在運行時通過構(gòu)造函數(shù)注入。在下面的例子中，Action Interface通過HumanAction Implementation注入到Human類中，從而決定在運行時實現(xiàn)哪個特定的動作。這種技術(shù)提供了控制依賴的靈活性:

package az.alizeynalli.di;

public interface Action {
    void do();
}

public class HumanAction implements Action {
 
    @Override
    public void do() {
        System.out.print("run");
    }
}

public class Human  {
     
    Action action;
     
    public Human(Action action) {
        this.action = action;
    }
 
    @Override
    public void do() {        
        actoin.do();        
    }
}

    public static void main(String[] args) {
        Human human = new Human(new HumanAction);
        human.do();
    }

5. 單一職責(zé)(Single Responsibility)

該原則的主要思想是限定軟件系統(tǒng)的每個構(gòu)建塊只承擔(dān)唯一的責(zé)任。無論構(gòu)建塊的作用域是什么，是插件、包、類、函數(shù)，甚至是變量，應(yīng)該只有一個職責(zé)。這篇文章更深入的討論了這一原則: How to apply SOLID Software Design Principles to Spring Boot Application (Part 1)[3]

6. DRY(Don’t Repeat Yourself)

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

每個知識片段在系統(tǒng)中都必須有單一、明確、權(quán)威的表示。

7. 開閉原則(Open-Closed)

軟件構(gòu)件應(yīng)該對擴展開放，對修改關(guān)閉。

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

8. 持久化透明(Persistence Ignorance)

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

9. YAGNI

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

10. 童子軍規(guī)則(Boy Scout Rule)

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

這里的主要思想是，當(dāng)開發(fā)時遇到反模式，要堅持重構(gòu)代碼。隨著時間的推移，這會提高代碼質(zhì)量。

11. 里氏替換原則(Liskov-Subsititution)

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

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

12. 封裝(Encapsulation)

軟件系統(tǒng)的不同構(gòu)建塊應(yīng)該通過封裝來限制外界對其組件的訪問，可以通過在類范圍內(nèi)設(shè)置組件為私有或在插件范圍內(nèi)設(shè)置訪問限制來實現(xiàn)(就java而言)，從而隱藏信息。

13. 松耦合(Loose Coupling)

軟件架構(gòu)中最重要的原則之一是松耦合，這一原則表明軟件系統(tǒng)的依賴關(guān)系應(yīng)該松散，系統(tǒng)的一部分發(fā)生變化，對其他部分的影響應(yīng)該最小。松耦合可以通過依賴倒置、異步消息中間件、事件源等實現(xiàn)。下面的文章深入探討了軟件工程中不同形式的耦合: 9 Forms of Coupling in Software Architecture[4]

14. 內(nèi)聚(Cohesion)

內(nèi)聚是指模塊內(nèi)的元素依賴的程度。某種意義上說，是對類的方法和數(shù)據(jù)以及該類所服務(wù)的某種統(tǒng)一目的或概念之間關(guān)系強度的度量。

構(gòu)建高內(nèi)聚的類是一種最佳實踐，有利于實現(xiàn)單一責(zé)任原則、松耦合等。

15. 接口隔離(Interface Segregation)

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

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

可以想象這樣一種情況，我們的Income和Expense用例都依賴于支持這兩種用例的業(yè)務(wù)邏輯功能。因此Income用例的很多依賴都和Expense用例相關(guān)，而Expense用例的依賴情況也有相同的問題?；谝陨嫌懻?，ISP違規(guī)情況如下:

package az.alizeynalli.cashflow.core.service;

public interface ConverterService {
    Income convertIncome(Income income);
    Expense convertExpense(Expense expense);
}

@Component
public class ExpenseConverterServiceImpl implements ConverterService {

    @Override
    public Income convertIncome(Income income) {
        throw new UnsupportedOperationException();
    }

    @Override
    public Expense convertExpense(Expense expense) {
        // convert expense here
        return expense;
    }
}

@Component
public class IncomeConverterServiceImpl implements ConverterService {

    @Override
    public Income convertIncome(Income income) {
        // convert income here
        return income;
    }

    @Override
    public Expense convertExpense(Expense expense) {
        
        throw new UnsupportedOperationException();
    }
}

16. 限界上下文(Bounded Context)

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

17. 依賴穩(wěn)定原則(Stable Dependencies)

這一原則指出，軟件系統(tǒng)的不同構(gòu)建塊應(yīng)該只依賴于可靠、穩(wěn)定的工件。這個原則在docker鏡像術(shù)語中更有意義，當(dāng)我們從docker hub導(dǎo)入不同的依賴時，甚至不知道它們是否可靠/穩(wěn)定。

18. 多態(tài)(Polymorphism)

這實際上屬于面向?qū)ο缶幊痰?大支柱，鼓勵使用可以以多種形式提供的接口，多態(tài)性意味著具有多種形式的實體。

19. 模塊化(Modularization)

模塊化是將軟件系統(tǒng)劃分為多個獨立模塊的過程，每個模塊獨立工作。這一原則是應(yīng)用于軟件系統(tǒng)靜態(tài)架構(gòu)的單一職責(zé)分離原則的另一種形式。

20. 抽象(Abstraction)

這也屬于面向?qū)ο缶幊痰乃拇笾е?

在研究物體或系統(tǒng)時去除物理的、空間的或時間的細(xì)節(jié)或?qū)傩砸约凶⒁饬τ诟匾牟糠?，本質(zhì)上與泛化過程相似。

21. KISS(Keep It Simple, Stupid)

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

22. 增量/迭代方法(Incremental/Iterative Approach)

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

23. 最少知識原則(Least Knowledge)

或者叫信息嫉妒(information envying)，是封裝或信息隱藏原則的另一個術(shù)語，規(guī)定軟件系統(tǒng)的不同部分應(yīng)該只擁有需要的知識。