成為程序員時，我學到了幾種設計模式：單例模式，存儲庫，工廠，構建者，裝飾者等。設計模式為我們提供了一個經過驗證的解決方案，以解決現有的和重復出現的問題。我沒有學到的是，類似的機制存在于更高層次上：軟件架構模式。這些是用于整個應用程序或應用程序布局的模式。它們都有優點和缺點。它們都解決了具體問題。下面我們一一分析：

分層模式

分層模式可能是最著名的軟件體系結構模式之一。許多開發人員在不知道名稱的情況下使用它。我們的想法是將您的代碼拆分為“層”，其中每個層都有一定的責任，并為更高層提供服務。

沒有預定義數量的圖層，但這些圖層是您經常看到的圖層：

• Presentation(展示或UI層)

• Application(應用層)

• Business(業務或管理層)

• Persistence(持久性或數據訪問層)

• Database(數據庫層)

這個想法是，用戶通過執行一些操作（例如點擊一個按鈕）來啟動表示層中的一段代碼。表示層然后調用底層，即應用層。然后我們進入業務層，***，持久層將所有內容存儲在數據庫中。所以更高層依賴于并且調用較低層。 

根據應用程序的復雜程度，您將看到相應的變體。一些應用程序可能會忽略應用程序層，而其他應用程序則會添加一個緩存層。甚至可以將兩個層合并為一個。例如，ActiveRecord模式結合了業務層和持久層。

每層責任

如前所述，每一層都有自己的責任。表示層包含應用程序的圖形設計，以及處理用戶交互的任何代碼。您不應該在此圖層中添加不特定于用戶界面的邏輯。

業務層是您將模型和邏輯特定于您要解決的業務問題的地方。

應用程序層位于表示層和業務層之間。一方面，它提供了一種抽象，以便表示層不需要知道業務層。理論上，您可以更改表示層的技術堆棧，而無需更改應用程序中的任何其他內容（例如，從WinForms更改為WPF）。另一方面，應用程序層提供了放置不適合業務或表示層的某些協調邏輯的位置。

***，持久層包含訪問數據庫層的代碼。數據庫層是底層數據庫技術（例如SQL Server，MongoDB）。持久層是操縱數據庫的代碼集合：SQL語句，連接細節等。

優點

• 大多數開發人員都熟悉這種模式。
• 它提供了一種編寫組織良好，可測試的應用程序的簡單方法。

缺點

1. 它往往會導致單片應用程序之后很難分開。
2. 開發人員經常發現自己編寫了很多代碼來通過不同的圖層，而沒有在這些圖層中添加任何值。如果你所做的只是編寫一個簡單的CRUD應用程序，那么分層模式可能對你來說太過分了。

適合場景

• 標準業務線應用程序，不僅僅是CRUD（寫讀改刪）操作

微內核

當您的應用程序具有一組核心職責和一組可互換部分時，微內核模式或插件模式非常有用。微內核將提供應用程序的入口點和一般流程，而不知道不同的插件正在做什么。 

一個例子是任務調度器。微內核可以包含用于調度和觸發任務的所有邏輯，而插件包含特定任務。只要插件遵循預定義的API，微內核就可以觸發它們，而無需了解實現細節。

另一個例子是工作流程。工作流的實現包含諸如不同步驟的順序，評估步驟結果，決定下一步是什么等概念。步驟的具體實現對于工作流的核心代碼來說并不重要。

優點

• 這種模式提供了很大的靈活性和可擴展性。
• 某些實現允許在應用程序運行時添加插件。
• 微內核和插件可以由獨立的團隊開發。

缺點

• 決定什么屬于微內核，哪些不屬于微內核是很困難的。
• 預定義的API可能不適合未來的插件。

適合場景

• 從不同來源獲取數據的應用程序，轉換該數據并將其寫入不同的目標
• 工作流應用程序
• 任務和作業調度應用程序

CQRS

CQRS是命令和查詢責任分離（Command and Query Responsibility Segregation）的首字母縮略詞。這種模式的核心概念是應用程序具有必須完全分離的讀取操作和寫入操作。這也意味著用于寫操作（命令）的模型將與讀模型（查詢）不同。此外，數據將存儲在不同的位置。在關系數據庫中，這意味著將有用于命令模型的表格和用于讀取模型的表格。一些實現甚至將不同模型存儲在完全不同的數據庫中，例如命令模型的SQL Server和讀取模型的MongoDB。

這種模式通常與事件采購相結合，我們將在下面介紹。

它是如何工作的？當用戶執行操作時，應用程序會向命令服務發送命令。命令服務從命令數據庫中檢索它需要的所有數據，進行必要的操作并將其存儲回數據庫中。然后它通知讀取服務，以便可以更新讀取模型。這個流程如下所示。 

當應用程序需要向用戶顯示數據時，它可以通過調用讀取服務來檢索讀取的模型，如下所示。 

優點

• 命令模型可以專注于業務邏輯和驗證，而讀取模型可以針對特定場景量身定制。
• 您可以避免復雜的查詢（例如，SQL中的連接），這使得讀取更加高效。

缺點

• 保持命令和讀取模型同步可能會變得復雜。

適合場景

• 期望大量讀取的應用程序
• 復雜域的應用程序

事件采購

正如我上面提到的，CQRS通常與事件采購密切相關。這是一種模式，它不會將模型的當前狀態存儲在數據庫中，而是存儲模型中發生的事件。因此，當客戶名稱發生變化時，您不會將該值存儲在“名稱”列中。你將存儲一個帶有新值的“NameChanged”事件（也可能是舊的）。

當您需要檢索模型時，您將檢索其存儲的所有事件并在新對象上重新應用它們。我們稱之為補水對象。

事件采購的現實類比是會計。當您添加費用時，您不會更改總額的值。在會計中，會添加一條新行，并執行操作。如果發生錯誤，只需添加一個新行。為了讓您的生活更輕松，您可以在每次添加線路時計算總計。這個總數可以看作是讀取模型。下面的例子應該更清楚。

您可以看到我們在添加發票201805時發生了錯誤。我們添加了兩條新線，而不是更改線：首先，一條線用于取消錯誤線，然后是一條新的正確線。這就是事件采購的工作方式。你永遠不會刪除事件，因為它們在過去不可否認。為了糾正情況，我們添加了新事件。

另外，請注意我們如何擁有總值的單元格。這只是上面單元格中所有值的總和。在Excel中，它會自動更新，因此您可以說它與其他單元格同步。它是閱讀模型，為用戶提供了一個簡單的視圖。

事件采購通常與CQRS結合使用，因為重新水化對象可能會對性能產生影響，特別是當實例有很多事件時。快速閱讀模式可以顯著提高應用程序的響應時間。

優點

• 該軟件體系結構模式可以提供開箱即用的審計日志。每個事件表示在某個時間點對數據的操縱。

缺點

• 它需要一些紀律，因為你不能用數據庫中的簡單編輯修正錯誤的數據。
• 改變事件結構并不是一件容易的事情。例如，如果添加屬性，則數據庫仍包含沒有該數據的事件。您的代碼需要慷慨地處理這些缺失的數據。

適合場景

• 需要將事件發布到外部系統
• 將用CQRS構建
• 需要對數據進行更改的審計日志

微服務

當您將應用程序編寫為一組微型服務時，實際上是在編寫可以一起工作的多個應用程序。每個微服務都有自己獨特的責任，團隊可以獨立于其他微服務開發它們。他們之間唯一的依賴是溝通。由于微服務彼此通信，因此您必須確保它們之間發送的消息保持向后兼容。這需要一些協調，特別是當不同的團隊負責不同的微服務時。

一張圖可以解釋。 

在上圖中，應用程序調用一個中央API，將呼叫轉發到正確的微服務。在本例中，用戶配置文件，庫存，訂單和付款有單獨的服務。你可以想象這是一個應用程序，用戶可以訂購一些東西。單獨的微服務也可以互相調用。例如，支付服務可以在支付成功時通知訂單服務。訂單服務可以調用庫存服務來調整庫存。

目前還沒有明確規定微服務的規模。在前面的示例中，用戶配置文件服務可能負責數據，如用戶的用戶名和密碼，還包括家庭地址，頭像圖片，收藏夾等。還可以將所有這些責任分成更小的一個選項微服務。

優點

• 您可以分別編寫，維護和部署每個微服務。
• 微服務架構應該更容易擴展，因為您只能擴展需要擴展的微服務。沒有必要擴展應用程序中不常使用的部分。
• 重寫應用程序的部分更容易，因為它們更小并且與其他部分的耦合更少。

缺點

• 與您所期望的相反，開始編寫結構良好的巨集實際上更容易，稍后將其分解為微服務。隨著微服務的出現，許多額外的問題開始發揮作用：溝通，協調，向后兼容性，日志記錄等等。錯過編寫結構良好的巨集的必要技能的團隊可能很難寫出一套很好的微服務。
• 用戶的單個動作可以通過多個微服務。還有更多的失敗點，當出現問題時，可能需要更多時間來查明問題。

適合：

• 應用程序某些部分將被密集使用并需要縮放
• 為其他幾個應用程序提供功能的服務
• 如果組合成一個整體，那么應用程序將變得非常復雜
• 應用程序可以定義明確的有界上下文

總結

上面列出軟件開發中的幾種軟件架構模式，以及它們的優點和缺點。但是有比這里列出的更多的模式。將這些模式中的幾種結合起來也并不罕見。它們并不總是相互排斥的。例如，您可以擁有多個微服務，其中一些使用分層模式，而其他使用CQRS和事件源。

需要記住的重要一點是，沒有一種解決方案可以在任何地方使用。當我們提出應用程序使用哪種模式的問題時，古老的答案仍然適用：“這取決于你的項目需求！”。您應該權衡解決方案的優缺點，并做出明智的決定。