1.3 軟件架構設計的原則與模式

與軟件需要進行設計一樣，軟件架構也需要進行設計。軟件架構設計是開發者對一個軟件內部元素及其關系的主觀映射，是一系列相關的抽象模式，用于指導大型軟件各個方面的設計。在進行軟件架構設計時，空間體系結構設計通常是核心，時間流程決策是關鍵。軟件架構的設計通常遵循空間體系結構的設計原則，并與時間流程上的決策相結合。

1.3.1 軟件架構設計的原則

面向對象的編程和軟件設計模式通常會遵循6個原則，其中，前5個組合到一起就是我們常說的SOLID設計原則。這些原則也可以擴展到軟件架構設計領域。

1.單一職責原則

所謂單一職責原則（Single Responsibility Principle，SRP），是指對一個類、模塊或子系統而言，應該僅有一個引起它變化的原因。在軟件空間體系結構中，元素的劃分需要保持職責的清晰，最好不要滿足多種不同的需求，否則會導致耦合過強，不利于后期的擴展和維護。劃分職責的困難在于缺乏一個標準，最終需要從實際需求出發去考慮。領域驅動的軟件架構設計在很多情況下是一種行之有效的方法。

2.開閉原則

軟件空間體系結構中的類、函數、模塊乃至子系統等元素應該對擴展開放，對修改封閉。也就是說，這些元素應該易于擴展，在需要根據需求變化時不需要去修改基礎的邏輯代碼。換句話說，一個軟件實體應該通過擴展來實現變化，而不是通過修改已有的代碼來實現改變，這是高內聚的另一種體現，這就是所謂的開閉原則（Open Close Principle，OCP）。

3.里氏替換原則

在面向對象的編程設計中，里氏替換原則（Liskov Substitution Principle，LSP）指的是在基類出現的任何地方，其子類也可以出現，并且不會引發錯誤。換句話說，凡是基類適用的地方，子類一定也適用。在擴展的軟件架構設計領域中，里氏替換指的是軟件空間體系結構中類、函數、模塊甚至子系統的可替代性。里氏替換原則是軟件容錯和災備的指導原則，也是松耦合的一種體現。

4.接口隔離原則

軟件空間體系中的不同元素，一般通過接口實現交互。但是我們必須避免建立臃腫龐大的接口，盡量建立功能單一的接口。換句話說，接口應該盡可能細化，同時方法的數量應該盡量少。單一職責原則的重點在于職責的劃分，通常根據業務邏輯進行劃分；而接口隔離原則（Interface Segregation Principle，ISP）則要求盡量減少接口中的方法，不依賴不需要的接口，這樣更便于進行重構、變更和重新部署。接口是對外的承諾，我們應該提高接口和類的處理能力，減少對外的交互。簡而言之，單一職責原則的目的是松耦合，接口隔離原則的目的是高內聚。

5.依賴倒置原則

依賴倒置原則（Dependence Inversion Principle，DIP）指的是高層次的軟件空間體系結構元素不依賴于低層次的軟件空間體系結構元素的實現細節，而是依賴于抽象，換句話說就是面向接口編程。在分布式軟件中，通信方式和協議的實現是依賴倒置原則的具體體現。

6.迪米特原則

迪米特原則（Least Knowledge Principle，LKP）又稱最少知識原則，指的是軟件空間體系結構中類、函數、模塊乃至子系統等元素應該對其他元素了解最少，也就是說，一個軟件實體對自己的依賴感知最少，只關心那些必需的接口。它是對接口隔離原則的有益補充，是松耦合的另一種體現。

總而言之，在面向空間體系結構的軟件架構設計中，可通過上述設計原則來實現松耦合和高內聚。

1.3.2 軟件架構設計的模式

有交互就代表會涉及時序，軟件架構中的空間體系結構必然會與時間流程決策相結合，而且隨著軟件工程的不斷發展產生了一系列架構模式。

1.分層架構模式

分層架構模式是最常見的架構模式，也被稱為N層架構模式。它是單一職責原則的宏觀體現，強調分離。通過將組件劃分到不同的層次，組件能夠輕松實現各自的角色和職責。每個層次中的組件僅負責該層次的邏輯，這樣更容易進行開發、測試、管理和維護。分層隔離有助于降低整個軟件的復雜性。某些功能并不需要經過每一層，因此需要根據開閉原則來簡化實現。

2.微內核架構模式

微內核架構模式也被稱為插件架構模式，可用于實現基于產品的應用，如Eclipse。在微內核的基礎上添加插件，可以提供不同的產品。微內核架構主要包含兩個組件——核心系統和插件模塊。應用邏輯通過分成核心系統和插件模塊對外提供可擴展、高靈活和特性隔離的功能。

實際上，許多架構模式都可以作為整個系統的插件。換句話說，微內核架構模式可以嵌入其他架構模式中，通過插件還可以提供演化和增量開發的功能。

3.事件驅動架構模式

事件驅動架構模式是一種流行的分布式異步架構模式，用于創建可伸縮的軟件。這種模式適用于各種規模的軟件，并具有自適應性。它由高度解耦的、單一目的的事件處理組件組成，可以異步接收和處理事件。

一般來說，事件驅動架構模式主要包含4個組件：事件隊列、調停者、事件通道和事件處理器。客戶端創建事件并將其發送到事件隊列，調停者接收事件并將其傳遞給事件通道，事件通道將事件傳遞給事件處理器，最終由事件處理器完成事件處理。調停者類似于集中調度中心。一種常見的事件驅動架構模式變體是使用分布式調度中心，將事件通道直接置于消息隊列中。

4.微服務架構模式

微服務架構模式是SOLID設計原則的集中體現，其核心概念是具備高可伸縮性、易于部署和交付的獨立部署單元，包含業務邏輯和處理流程的服務組件。內部服務組件之間的通信方式有兩種：基于HTTP的同步機制（REST API和RPC^[1]）和基于消息隊列的異步消息處理機制。

從空間上來說，服務組件可以是單一的模塊或者一個大的軟件，這兩者都代表單一功能。

5.云服務架構模式

云服務架構模式是XaaS的綜合體，基于云的架構可以使應用規模對服務的影響最小化。云服務架構模式起源于分布式共享內存的想法，典型代表是無服務架構。

要打破規模化，就要移除中心數據庫，使用可復制的內存網格。應用的數據保存在所有活動的處理單元的內存中。可以根據應用規模加入和移除處理單元。小型軟件可以使用一個處理單元，大型軟件可以分隔成多個處理單元。處理單元還包括數據網格。虛擬化中間件負責管理和通信，并處理數據的同步和請求。這就是云服務架構模式的工作原理。

各種架構模式都或多或少地體現了邏輯架構、數據架構、物理拓撲架構、開發架構和運行架構，所以說它們是軟件架構時空視角的結合體。