本文翻譯自土牛Halil ibrahim Kalkan的《Mastering ABP Framework》，是系列翻譯的起頭，適合ABP開發人員或者想對ABP框架進行深入演進的準架構師。
在深入挖掘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的QQ群（免費）
或者加入我的知識星球（收費），體驗更加及時和全面的服務：
