深入解析 18 種軟件架構設計模式 （3）

本篇介紹：微內核架構，領域驅動架構，基於組件的架構。

請關注博主，後續持續更新。

架構模式捕獲了各類系統和軟件要素的設計結構，使其可以被複用。在編寫代碼的過程中，開發者往往在項目內、公司內乃至職業生涯中多次遇到類似問題。通過創建設計模式，工程師們可以藉助一種可複用的方法來解決問題，結構化地實現項目目標。

  1. 微內核架構 Microkernel Architecture =================================

微內核架構（Microkernel Architecture） ，又稱爲可插拔架構，是一種軟件設計模式，旨在幫助開發者構建更模塊化和靈活的系統。該架構將核心系統功能與其他功能分離開來，並通過獨立的模塊實現這些額外功能。系統的核心功能由微內核（Microkernel）實現，它是系統的最基本核心，僅提供運行系統所需的基礎服務。這種架構理念可以看作一種 “即插即用”（Plug-and-Play） 的設計思路。

示例：電子商務網站

以一個電子商務網站爲例，微內核負責提供基礎服務，例如用戶身份驗證、用戶會話管理以及支付處理等。而其他功能，比如產品推薦、用戶評論、社交媒體集成功能，則通過獨立模塊來實現。

如果網站需要添加一個新功能，比如會員積分計劃，開發者可以將其作爲一個獨立的模塊進行開發並添加進系統，而無需對系統的核心功能進行任何修改。這種模塊化設計大大簡化了新增或移除功能的流程，同時確保核心系統功能的穩定性。

靈活定製

此外，網站還可以根據不同用戶的特定需求定製系統，僅選擇適合每位用戶的必要模塊。例如，針對經常購買電子產品的用戶，系統可以加載一個電子產品推薦模塊；而對於經常購買化妝品的用戶，則可以加載一個化妝品推薦模塊。這種定製能力能夠顯著提升用戶體驗。

擴展性與可維護性

最後，當網站需要擴展系統以應對更多用戶或底層硬件的變化時，可以根據需要輕鬆地添加或移除模塊。這種擴展性使得系統能夠快速適應用戶需求的變化或硬件的升級改動。

  1. 領域驅動架構 Domain-Driven Design, DDD ===================================

領域驅動設計（Domain-Driven Design, DDD） 是一種將軟件開發與業務領域緊密結合的架構設計思想。其核心在於，軟件架構的設計應以業務領域爲中心，而非單純追求技術實現。這種方法強調通過對業務領域的深入理解，提煉出領域的核心邏輯，以推動軟件系統的高效設計和開發。

領域驅動設計的關鍵特點

  1. 以領域爲核心 DDD 的目標是確保軟件系統能夠真實地反映業務領域及其規則。開發者通過與領域專家密切協作，理解業務需求，提取核心概念，並將這些概念抽象爲領域模型。這種專注於業務邏輯而非技術實現的方式，能夠幫助團隊開發出更貼合業務需求的系統。

  2. 跨領域知識共享 開發者不僅需要掌握技術知識，還需要深入瞭解領域知識（Domain Knowledge）。通過與領域專家溝通，開發團隊能更準確地捕獲業務規則和問題空間，從而避免由於對領域的誤解而導致的軟件設計偏差。

    領域建模與分解

DDD 強調對領域進行建模（Domain Modeling）。這是通過對領域的深入分析，將其分解爲多個小型的、高度聚焦的子領域。這種分解使得複雜的問題可以被拆解爲更易管理的部分，同時確保每個部分都能獨立演進。

領域模型（Domain Model）是對領域內實體及其交互關係的抽象表示。領域模型不僅是開發過程中的一個技術文檔，更是團隊成員之間的溝通工具。通過領域模型，開發團隊可以清晰地表達領域概念及其邏輯關係。

  1. 實體（Entities）：在領域中具有唯一標識的對象。例如，電商系統中的 “用戶” 或“訂單”。

  2. 值對象（Value Objects）：無需唯一標識的屬性類對象，用於描述領域中的某些特性，例如 “貨幣金額” 或“地址”。

  3. 服務（Services）：處理特定領域邏輯的無狀態操作，不屬於實體或值對象。例如，訂單結算服務。

    限界上下文（Bounded Contexts）

限界上下文是 DDD 中的核心概念，用於定義領域模型的適用範圍。一個限界上下文是一個獨立的邏輯邊界，內部使用統一的模型和語言。限界上下文之間通過清晰的接口進行交互，避免模型間的耦合。

  1. 統一語言（Ubiquitous Language）：在每個限界上下文內，開發者和領域專家使用統一的術語描述業務邏輯和技術實現，消除團隊間的語言鴻溝。

  2. 上下文映射（Context Mapping）：用於描述不同限界上下文之間的關係，例如依賴關係、集成方式或數據流動。

    聚合（Aggregates）

聚合是 DDD 中管理複雜領域邏輯的一個重要工具。聚合是一組相關實體和值對象的集合，它們共同維護領域的一致性。每個聚合都有一個根實體（Aggregate Root），外部只能通過聚合根與聚合進行交互。

例如，在訂單管理系統中，“訂單”可以作爲一個聚合，聚合內包含 “訂單明細”“支付信息” 等子實體或值對象。通過限制外部對聚合內部的直接訪問，可以保持系統的一致性和完整性。

領域驅動設計的優勢

  1. 對複雜業務的精準建模 DDD 提供了一種框架，通過領域模型、限界上下文和聚合等概念，開發者能夠更精確地捕捉和表達複雜的業務需求。

  2. 高內聚、低耦合 限界上下文和聚合的使用，使系統模塊之間的依賴關係更清晰，從而實現高內聚和低耦合。這不僅提高了系統的可維護性，還爲後續擴展提供了更大的靈活性。

  3. 跨團隊的協作效率 通過統一語言，DDD 在開發團隊和業務專家之間建立了橋樑。這種一致的語義模型，有助於減少誤解，提高團隊協作效率。

    實例：電子商務平臺

爲了更直觀地理解領域驅動設計，我們以電子商務平臺爲例。

問題領域（Problem Domain）：

領域實體（Domain Entities）：指軟件應用程序所涉及的主題或問題空間。

1.    Customer（客戶）：表示一個註冊用戶，具有屬性如姓名、郵箱和送貨地址。
2.    Order（訂單）：表示客戶的購買請求，包含商品、數量和總價等信息。
3.    Product（商品）：表示可供銷售的商品，具有名稱、描述和價格等屬性。

值對象（Value Objects）：表示特性或屬性，但沒有唯一標識。

1.    Money（貨幣）：表示金額，包括貨幣類型和金額數值。
2.    Address（地址）：表示一個物理位置，包括街道、城市、州和郵政編碼等信息。

限界上下文（Bounded Contexts）：

限界上下文定義了領域模型適用的明確邊界。不同的上下文可能有各自的模型和術語，反映了整體領域的不同視角或子系統。

1.    訂單管理上下文（Order Management Context）：關注訂單的創建、修改和履行。
2.    客戶管理上下文（Customer Management Context）：管理客戶檔案、身份驗證和地址信息。

服務（Services）：

服務封裝領域邏輯，爲領域模型提供具體功能支持。

1.    PaymentService（支付服務）：管理支付處理及與外部支付網關的集成。
2.    ShippingService（物流服務）：處理訂單的物流管理和追蹤。

倉儲（Repositories）：

倉儲負責領域模型中實體的持久化和檢索。

1.    CustomerRepository（客戶倉儲）：管理客戶信息的存儲與檢索。
2.    OrderRepository（訂單倉儲）：負責訂單數據的存儲與檢索。
  1. 基於組件的架構 Component-Based Architecture, CBA ============================================

在軟件工程中，基於組件的架構（Component-Based Architecture, CBA）是一種強調軟件可重用性的設計與開發方法。其核心思想是通過將複雜系統拆分爲更小、更易管理的組件，使軟件開發變得更加高效和可控。

什麼是軟件組件？

軟件組件是模塊化、獨立的功能單元，可以在不同系統中重複使用。組件通常具備明確定義的接口，用於指定其他組件與其交互的方式。這些接口包括組件的輸入、輸出以及行爲的描述。

基於其功能，組件可以被分類爲以下類型：

  1. 用戶界面組件（UI Components）：處理用戶界面展示與交互。

  2. 數據訪問組件（Data Access Components）：管理對數據庫或其他存儲系統的訪問。

  3. 業務邏輯組件（Business Logic Components）：實現具體的業務規則與操作。

每個組件都封裝了特定的功能，並通過定義良好的接口與其他組件交互。這種架構在軟件開發中推廣了模塊化設計、可重用性和靈活性。

基於組件架構的關鍵概念

組件（Components）

組件是獨立的軟件單元，封裝了特定功能或服務。組件可以使用不同的編程語言和技術實現，只要遵循定義好的接口規範。組件之間通過接口進行交互，而不直接依賴於其他組件的內部實現，從而增強系統的靈活性和可維護性。

接口（Interfaces）

接口定義了組件與外部交互的契約或 API。接口規範包括方法、參數和數據結構的詳細信息，明確了組件之間的通信規則。通過接口，組件能夠解耦，實現獨立開發與測試。

組件的組裝（Composition）

組件可以通過靜態組裝（編譯時綁定）或動態組裝（運行時綁定）組合在一起，以構建更大的系統或應用程序。靜態組裝：組件之間的依賴關係在系統構建階段明確。動態組裝：組件在運行時被動態實例化和連接，允許系統根據需求實時調整。

重用（Reuse）

組件通過封裝通用功能，實現跨應用或項目的代碼重用。重用減少了開發時間和工作量，因爲開發者可以直接使用現有組件，而無需從頭開始構建所有功能。

實例：Java 企業版（Java EE）中的基於組件的架構

以下通過 Java EE 的 Web 應用程序，說明基於組件的架構如何應用於實際開發中：

組件（Components）

Servlets：處理 HTTP 請求並生成動態網頁內容。

EJBs（Enterprise JavaBeans）：提供業務邏輯和事務管理。

JSP（JavaServer Pages）：用於生成 HTML 響應的模板。

接口（Interfaces）

Servlet API：定義了處理 HTTP 請求和響應的方法。

EJB 接口：指定調用業務方法的遠程和本地接口。

JSP 標籤庫（Tag Libraries）：定義標籤和屬性，用於在 HTML 頁面中嵌入 Java 代碼。

組件的組裝（Composition）

Web 應用部署描述符（web.xml）：指定 Servlets、過濾器及其他組件的配置和組合方式。

依賴注入（Dependency Injection，e.g., CDI）：在運行時動態管理組件間的依賴關係。

重用（Reuse）

標準組件：Java EE 提供瞭如 Servlets、EJBs 和 JSP 的標準組件，可在不同的 Web 應用中重用。

自定義組件：開發者可以創建自定義組件（例如自定義 Servlet 或 EJB），並在多個項目中重複使用。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/hssYzL05Xg27Rc4-fWD8RA

猜你喜歡