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

分層模式

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

沒有預(yù)定義數(shù)量的圖層，但這些圖層是您經(jīng)?？吹降膱D層：

• Presentation(展示或UI層)

• Application(應(yīng)用層)

• Business(業(yè)務(wù)或管理層)

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

• Database(數(shù)據(jù)庫層)

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

根據(jù)應(yīng)用程序的復(fù)雜程度，您將看到相應(yīng)的變體。一些應(yīng)用程序可能會忽略應(yīng)用程序?qū)樱渌麘?yīng)用程序則會添加一個緩存層。甚至可以將兩個層合并為一個。例如，ActiveRecord模式結(jié)合了業(yè)務(wù)層和持久層。

每層責任

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

業(yè)務(wù)層是您將模型和邏輯特定于您要解決的業(yè)務(wù)問題的地方。

應(yīng)用程序?qū)游挥诒硎緦雍蜆I(yè)務(wù)層之間。一方面，它提供了一種抽象，以便表示層不需要知道業(yè)務(wù)層。理論上，您可以更改表示層的技術(shù)堆棧，而無需更改應(yīng)用程序中的任何其他內(nèi)容（例如，從WinForms更改為WPF）。另一方面，應(yīng)用程序?qū)犹峁┝朔胖貌贿m合業(yè)務(wù)或表示層的某些協(xié)調(diào)邏輯的位置。

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

優(yōu)點

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

缺點

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

適合場景

• 標準業(yè)務(wù)線應(yīng)用程序，不僅僅是CRUD（寫讀改刪）操作

微內(nèi)核

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

一個例子是任務(wù)調(diào)度器。微內(nèi)核可以包含用于調(diào)度和觸發(fā)任務(wù)的所有邏輯，而插件包含特定任務(wù)。只要插件遵循預(yù)定義的API，微內(nèi)核就可以觸發(fā)它們，而無需了解實現(xiàn)細節(jié)。

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

優(yōu)點

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

缺點

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

適合場景

• 從不同來源獲取數(shù)據(jù)的應(yīng)用程序，轉(zhuǎn)換該數(shù)據(jù)并將其寫入不同的目標
• 工作流應(yīng)用程序
• 任務(wù)和作業(yè)調(diào)度應(yīng)用程序

CQRS

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

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

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

當應(yīng)用程序需要向用戶顯示數(shù)據(jù)時，它可以通過調(diào)用讀取服務(wù)來檢索讀取的模型，如下所示。 

優(yōu)點

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

缺點

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

適合場景

• 期望大量讀取的應(yīng)用程序
• 復(fù)雜域的應(yīng)用程序

事件采購

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

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

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

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

另外，請注意我們?nèi)绾螕碛锌傊档膯卧瘛＿@只是上面單元格中所有值的總和。在Excel中，它會自動更新，因此您可以說它與其他單元格同步。它是閱讀模型，為用戶提供了一個簡單的視圖。

事件采購?fù)ǔＥcCQRS結(jié)合使用，因為重新水化對象可能會對性能產(chǎn)生影響，特別是當實例有很多事件時?？焖匍喿x模式可以顯著提高應(yīng)用程序的響應(yīng)時間。

優(yōu)點

• 該軟件體系結(jié)構(gòu)模式可以提供開箱即用的審計日志。每個事件表示在某個時間點對數(shù)據(jù)的操縱。

缺點

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

適合場景

• 需要將事件發(fā)布到外部系統(tǒng)
• 將用CQRS構(gòu)建
• 需要對數(shù)據(jù)進行更改的審計日志

微服務(wù)

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

一張圖可以解釋。 

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

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

優(yōu)點

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

缺點

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

適合：

• 應(yīng)用程序某些部分將被密集使用并需要縮放
• 為其他幾個應(yīng)用程序提供功能的服務(wù)
• 如果組合成一個整體，那么應(yīng)用程序?qū)⒆兊梅浅?fù)雜
• 應(yīng)用程序可以定義明確的有界上下文

總結(jié)

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

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