導語
在開始文章之前，我給大家舉一個發生在我身邊的例子。我們交付的軟件是面向企業的一錘子買賣，後期可能會存在個別定製化。前期我們直接按項目來走，因爲我們也不知道未來的業務長什麼樣子，只是知道大概的範圍。隨着項目的增長，我們團隊成員直接複製一份代碼，然後修修改改就適配了一個新項目，因爲認爲這麼做最快，因爲是一次性買賣啊。所以，大家也懶得打磨，就這麼交付了。大家可以腦補一下，後面會出現什麼問題？
在深入挖掘ABP 框架之前，我想先介紹開發現代企業 Web 解決方案的挑戰，以瞭解爲什麼我們需要ABP 框架。讓我們從架構開始：
架構搭建的挑戰
選型挑戰
在開始編碼之前，我們需要爲解決方案創建一個適合當前和未來一段時期的架構基礎。這是構建軟件系統最具挑戰性的階段，在此階段做出的任何決定都可能會影響應用程序的整個生命週期。
有一些常見的、知名的、系統級的架構模式，例如單體架構、模塊化架構和微服務架構。不同的架構選型會決定後續的團隊組織架構、部署和擴展，所以我們要根據需求儘量做最優的選型。
另外，軟件開發模型，例如：命令和查詢職責分離(CQRS)、領域驅動設計(DDD)、分層架構和清潔架構將決定您的基礎代碼結構。
在這個階段，我們還需要決定將使用哪種語言、框架、工具和庫。
所有這些決策都不是一件容易的事情。
我們思考一下：我們團隊的軟件架構師和開發人員具備以上這些能力和經營了嗎？
現實是並非所有團隊成員都具有豐富的經驗和知識水平。我們需要從戰略上制定標準規範，在戰術上實踐最佳編碼。
重複造輪子
不要重複自己(DRY) 是軟件開發的關鍵原則。
我們先思考一個問題：爲什麼我們在構建軟件時會重複自己呢？
身份驗證是每個軟件都需要的功能，包括單點登錄、基於令牌的身份驗證、社交登錄、雙因素身份驗證、忘記/重置密碼、電子郵件激活等等，幾乎所有的軟件項目或多或少都有相似的身份驗證需求。與其從頭開始構建所有這些，不如複用現有的解決方案（例如雲服務）更好，不管在實戰還是安全方面都更加穩定成熟。
還有一些非功能性需求，例如異常處理、驗證、授權、緩存、審計日誌和數據庫事務管理，是代碼重複源頭。這些關注點被稱爲橫切關注點，應該在每個 Web 請求中處理。
當您集成到第三方系統（例如 RabbitMQ 和 Redis）時，您通常會創建抽象和裝飾器。通過這種方式，您的業務邏輯與這些基礎設施組件隔離開來。此外，您不會在系統中到處重複相同的連接、重試、異常處理和日誌記錄邏輯。
擁有一個預先構建的基礎架構來自動執行這些重複性工作可以節省您的開發時間，以便您可以專注於您的業務邏輯。
UI 設計和選型
用戶界面(UI)也是應用的基礎。一個過時且無法使用的 UI 不會那麼吸引人，即使它在幕後具有出色的商業價值。
雖然每個應用的 UI 功能和要求各不相同，但一些基本結構是常見的，例如警報、按鈕、卡片、表單元素、選項卡和數據表。您可以使用 HTML/CSS 框架，例如 Bootstrap、Bulma 和 Ant Design，而不是爲每個應用程序創建一個設計系統。
幾乎每個 Web 應用程序都有響應式佈局，主菜單、工具欄、頁眉和頁腳、自定義顏色等。您將需要爲應用的頁面和組件實現基本 UI 工具包。這樣，UI 開發人員可以創建一致的 UI。
到目前爲止，我們介紹了一些常見的基礎架構需求，它們大多獨立於任何業務應用。下面討論常見的業務需求。
實現常見的業務需求
雖然每個應用系統是獨特的，而且其價值來自於獨特性，但是每個企業系統都有一些基本的配套需求。
基於權限的授權系統是這些基本要求之一。它用於控制應用的用戶和客戶端的權限。如果您想自己實現這一點，您應該創建一個包含數據庫表、授權邏輯、權限緩存、API 和 UI 頁面的端到端解決方案。但是，這樣的系統非常通用，完全可以開發爲可重用模塊，由多個應用共同使用。
另外，許多系統需要審計日誌報告、租戶和訂閱管理（針對 SaaS 應用）、語言管理、文件上傳和共享、多語言管理和時區管理等功能。除了預先構建的應用功能之外，可能還有低級要求，例如實現軟刪除模式和在應用程序中存儲二進制大對象(BLOB) 數據。
所有這些常見的需求都可以從頭開始構建，但是這需要我們耗費巨大的成本和精力，如果你的團隊沒有經驗豐富的架構團隊，還不一定能完成得很好。如果這些功能不是公司的主要價值，我們完全可以考慮開源社區預構建的模塊和庫，並根據特定的要求進行定製。
ABP 框架的能力清單
ABP 框架提供了一個穩定的架構用於構建企業級軟件解決方案，它遵循了.NET 和 ASP.NET Core 平臺之上的最佳實踐。它內置了基礎架構、生產級別的模塊、主題、工具、指南和文檔，並儘可能地自動化開發細節和解法我們的重複性工作。
在接下來的幾個小節中，我將從架構層面介紹 ABP是如何完成所有這些工作。
ABP 架構
ABP 是一個特殊的架構，換句話說，它是一個有個性化的框架。先解釋一下什麼是沒有個性的框架，什麼是有個性的框架。
正如我在搭建架構部分所述，爲搭建解決方案的基礎設施需要大量決策工作；比如系統架構、開發模型、技術、模式、工具和庫。
沒有個性的框架，例如 ASP.NET Core，這些決定大多由您決定。例如，您可以通過將 UI 層與數據訪問層分離來創建分層解決方案，或者您可以通過直接從 UI 頁面/視圖訪問數據庫來創建單層解決方案。您可以使用任何庫，只要它與 ASP.NET Core 兼容，並且您可以應用任何架構模式。無個性使 ASP.NET Core 在不同的場景中變得靈活和可用。但是，所有的這些都需要我們自己去做決策。
我並不是說 ASP.NET Core 完全沒有自己的個性想法。假定您正在構建基於 HTTP 規範的 Web 應用程序或 API。它清楚地定義了應該如何開發 UI 和 API 層。它還提供了一些低級的基礎設施組件，例如依賴項注入、緩存和日誌記錄。但是，它並沒有說明您的業務代碼是應該要如何組建，應該使用哪些架構模式。
換句話說，ABP 框架是一個有個性傾向的框架。它相信軟件開發方法本質上可以更好，因此可以引導開發人員在解決方案中使用更佳的架構、模式、工具和庫。
儘管 ABP 框架足夠靈活，可以使用不同的工具和庫來改變您的架構決策，但當您遵循它的實踐原則時，您將獲得最大的價值。請別擔心，因爲它爲通用架構提供了良好的、行業認可的解決方案。他的架構規則將節省您的時間，提高您的生產力，並使您專注於您的業務代碼而不是基礎設施問題。
在接下來，我將介紹 ABP 所支持的四種基本架構。
領域驅動設計
ABP 的主要目標是根據整潔代碼原則提供一個模型來構建易維護的解決方案。它提供了一個基於DDD 模式和實踐的分層架構 。它提供了一個分層的啓動模板、基礎架構以及架構應用指南。
由於 ABP 是一個軟件框架，它專注於 DDD 的技術實現。本書的第 3 部分，實現領域驅動設計，解釋了使用 ABP 框架構建基於 DDD 的最佳實踐。
模塊化
在軟件開發中，模塊化是一種拆分系統成獨立模塊的技術。最終目標是降低複雜性，提高可重用性，使不同的團隊能夠在不相互影響的情況下能並行處理不同的功能集。
ABP構建模塊化有兩個主要挑戰：
-
第一個挑戰是模塊隔離。儘管ASP.NET Core 有一些特性（例如 Razor 組件庫）來支持模塊化。但是，它仍然非常有限，因爲它是一個底層通用的框架，並且僅對 UI 和 API 部分支持。另一方面，ABP 框架提供了一個一致的模型和基礎設施來構建完全隔離的、可重用的應用模塊及數據庫、領域、應用和 UI 層。
-
第二個挑戰是模塊之間如何通信，使之成爲一個統一的應用程序。ABP 爲模塊化系統提供常見的模型，例如在模塊之間共享數據庫，在模塊之間通過事件或 API 進行通信，以及模塊安裝。
ABP 提供了許多可在任何應用程序中使用的預構建模塊。包括身份驗證模塊，它提供用戶、角色和權限管理，同時也提供登錄和註冊頁面。他們基本上都是可重用和自定義的。此外，ABP 提供了模塊啓動模板，幫助您構建可重用的應用程序。這方面的一個例子可以在[第 15 章]使用模塊化中詳細介紹。
模塊化非常適合管理複雜的大型單體系統。但是，ABP 也可以幫助您創建微服務解決方案。
微服務
微服務和分佈式架構是構建可擴展系統的公認方法。它允許不同的團隊開發不同的服務並獨立地對服務進行單獨部署和擴展。
但是，構建微服務系統在團隊開發、部署、微服務間通信、數據一致性、監控等方面存在一些重要挑戰。
微服務系統是一種將不同的學科、方法、技術和工具結合在一起來解決獨特問題的解決方案。每個微服務系統都有其要求和限制。每個團隊都有一定程度的專業知識、知識和技能。
ABP 框架從一開始就被設計爲與微服務兼容。它在具有事務支持的微服務之間提供了一個用於異步通信的分佈式事件總線。它還提供 C# 客戶端代理來輕鬆調用遠程服務的 REST API。
所有預構建的 ABP 應用模塊都經過設計，以便您可以將它們轉換爲微服務。ABP 也提供了詳細指南來解釋如何創建微服務兼容模塊。這樣，您可以從模塊化單體開始，然後將其轉換爲微服務解決方案。
ABP 團隊準備了一個使用 ABP 框架構建的開源微服務參考方案。它演示瞭如何使用 API 網關、微服務間通信、分佈式事件、分佈式緩存、多個數據庫提供程序和多個 UI 應用程序。它還包括在容器上運行解決方案的 Kubernetes 和 Helm 配置。詳情參閱。
SaaS/多租戶
軟件即服務(SaaS) 是一種廣泛使用的架構模式。以下是多租戶系統的典型特徵：
-
在租戶之間共享硬件和軟件資源。
-
每個租戶都有用戶、角色和權限。
-
在租戶之間隔離數據庫、緩存和其他資源。
-
可以啓用/禁用每個租戶的應用功能。
-
可以爲每個租戶自定義應用配置。
ABP 框架涵蓋了所有這些要求甚至更多。它可以幫助您優雅地構建多租戶系統，而您幾乎感受不到多租戶的存在。
我們會在[第 16 章]實現多租戶，介紹如何使用 ABP 框架進行多租戶應用開發。
到目前爲止，我已經介紹了四種 ABP 基本架構模式。此外，ABP 還提供了啓動模板來輕鬆創建新的解決方案。
啓動模板
使用 ASP.NET Core 自帶的模板創建新解決方案時，只能獲得單個項目，沒有分層和依賴關係。您通常會花費大量時間來設置解決方案架構，包括安裝工具和做配置基本。
ABP 框架提供了一個架構完善、分層清晰、預配置和生產就緒的啓動解決方案模板。以下截圖顯示了當您運行 ABP 框架創建的啓動模板時的初始 UI：
![]()
下面談談這個啓動模板：
ABP的啓動模板帶有UI框架和數據庫提供者的多個選項。你可以從Angular、Blazor或MVC(Razor Pages) 選擇一個作爲 UI框架，或者使用Entity Framework Core或MongoDB作爲數據庫提供者。
ABP 基礎設施
ABP 基於您已經了熟悉的工具和庫。它沒有引入新的對象關係映射器（ORM），而是使用Entity Framework Core。同樣，它使用 Serilog、AutoMapper、IdentityServer 和 Bootstrap，而不是自己創建類似的功能。它提供了一個解決方案集成了這些工具，並實現了常見的業務應用需求。
ABP 框架按照約定簡化了異常處理、驗證、授權、緩存、審計日誌和數據庫事務管理，並允許您在需要時進行精細控制。
ABP 與 IdentityServer 很好地集成，基於 cookie 和令牌的身份驗證以及單點登錄。它還提供了一個詳細的、基於權限的授權系統來幫助您控制應用的權限。
同時也提供了後臺作業、BLOB 存儲、文本模板、審計日誌和本地化等常見組件。
在 UI 部分，ABP 提供了完整的 UI 主題系統，幫助您開發無主題的模塊化應用，並輕鬆爲應用程序安裝主題。它還在 UI 方面提供了大量功能和幫助程序，以消除重複代碼。
社區
當您在公司中搭建解決方案架構時，除了開發人員沒有人會去研究它。然而，ABP 擁有一個龐大而活躍的社區。他們使用相同的架構和基礎設施，應用類似的最佳實踐，並以類似的方式開發他們的應用程序。當您遇到基礎架構問題或想要獲得解決業務問題的想法或建議時，這具有很大的優勢。由於 ABP 開發人員正在應用相同或相似的模式，因此在另一個解決方案中也更容易理解他人的代碼。
ABP 框架自 2016 年以來一直存在並不斷髮展。截至 2021 年底，它在 GitHub 上擁有 7,000 多顆星、220 多位貢獻者、22,000 多個提交、5,700 個已關閉問題，以及在 NuGet 上超過 4,000,000 次下載，超過 110 多個專業和次要版本。我的意思是，它是一個成熟的、被接受的、值得信賴的開源項目。
來自ABP 核心團隊和社區的貢獻者，有着不斷持續輸出的文章，視頻教程可供大家學習：ABP社區網站：
![]()
概括
在本章中，我們介紹了構建業務解決方案的問題，並解釋了 ABP 如何爲這些常見問題提供解決方案。ABP 還通過提供預構建架構解決方案和實現該架構所需的基礎設施來提高開發人員的生產力。
在下一章中，您將學習如何使用 ABP 的命令行界面(CLI) 工具創建新的解決方案並在您的開發環境中運行它。
最後，我們回答一下開頭的那個問題，就是項目增長後出現的問題：代碼庫版本增多了。因爲你不想通過一份代碼在內部做if和else的不同項目判斷，所以你寧願拷貝一份可能是幾百兆的項目代碼，所以第二個問題就是代碼急劇膨脹，佔用大量的代碼庫空間。管理起來十分困難。歸根結底，這一切是可以避免的，ABP給我們一個很好的啓發。不知道讀者君有沒有自己的思路，歡迎留言。
如果你也在學習ABP，也有遇到問題需要諮詢，歡迎你加入ABP的QQ羣（免費）
![]()
或者加入我的知識星球（收費），體驗更加及時和全面的服務，感謝您的閱讀。
