核心原則

---

---

軟體架構被描述為系統的組織，其中系統代表一組完成定義功能的元件。

架構風格

架構風格，也稱為架構模式，是一組塑造應用程式的原則。它根據結構組織模式定義了系統家族的抽象框架。

架構風格負責：

• 提供元件和聯結器的詞彙表，以及關於如何組合它們的規則。

• 改進分割槽並透過提供針對常見問題的解決方案來允許設計重用。

• 描述配置元件集合（具有明確定義的介面、可重用和可替換的模組）和聯結器（模組之間的通訊連結）的特定方式。

為計算機系統構建的軟體展現出多種架構風格之一。每種風格描述一個系統類別，其中包含：

• 一組元件型別，它們執行系統所需的功能。

• 一組聯結器（子程式呼叫、遠端過程呼叫、資料流和套接字），它們使不同元件之間的通訊、協調和協作成為可能。

• 語義約束，定義如何整合元件以形成系統。

• 元件的拓撲佈局，指示其執行時相互關係。

常見架構設計

下表列出了可以按其關鍵關注領域組織的架構風格：

架構型別

從企業的角度來看，有四種類型的架構，這些架構統稱為企業架構。

• 業務架構 - 定義企業內的業務戰略、治理、組織和關鍵業務流程，並專注於業務流程的分析和設計。

• 應用（軟體）架構 - 作為各個應用程式系統、其互動以及與組織業務流程關係的藍圖。

• 資訊架構 - 定義邏輯和物理資料資產以及資料管理資源。

• 資訊科技 (IT) 架構 - 定義構成組織整體資訊系統的硬體和軟體構建塊。

架構設計流程

架構設計流程側重於將系統分解成不同的元件及其互動，以滿足功能性和非功能性需求。軟體架構設計的關鍵輸入包括：

• 分析任務產生的需求。

• 硬體架構（軟體架構師反過來向系統架構師提供需求，系統架構師配置硬體架構）。

架構設計流程的結果或輸出是架構描述。基本的架構設計流程由以下步驟組成：

理解問題

• 這是最關鍵的步驟，因為它會影響後續設計的質量。

• 如果沒有對問題的清晰理解，就不可能建立有效的解決方案。

• 許多軟體專案和產品被認為是失敗的，因為它們實際上並沒有解決有效的業務問題或具有可識別的投資回報率 (ROI)。

識別設計元素及其關係

• 在此階段，建立定義系統邊界和上下文的基線。

• 根據功能需求將系統分解成其主要元件。可以使用設計結構矩陣 (DSM) 對分解進行建模，該矩陣顯示設計元素之間的依賴關係，而無需指定元素的粒度。

• 在此步驟中，透過描述多個系統例項來完成架構的第一次驗證，此步驟稱為基於功能的架構設計。

評估架構設計

• 為每個質量屬性提供估計，因此為了收集定性度量或定量資料，對設計進行評估。

• 它涉及評估架構是否符合架構質量屬性要求。

• 如果所有估計的質量屬性都符合所需標準，則架構設計流程結束。

• 如果不是，則進入軟體架構設計的第三階段：架構轉換。如果觀察到的質量屬性不滿足其要求，則必須建立新的設計。

轉換架構設計

• 此步驟在評估架構設計後執行。必須更改架構設計，直到它完全滿足質量屬性要求。

• 它關注選擇設計解決方案以改進質量屬性，同時保留領域功能。

• 透過應用設計運算子、風格或模式來轉換設計。對於轉換，請獲取現有設計並應用設計運算子，例如分解、複製、壓縮、抽象和資源共享。

• 再次評估設計，並在必要時重複多次相同的過程，甚至遞迴執行。

• 轉換（即質量屬性最佳化解決方案）通常會改進一個或多個質量屬性，同時也會對其他屬性產生負面影響。

關鍵架構原則

以下是設計架構時需要考慮的關鍵原則：

構建以改變而不是構建以持久

考慮應用程式如何需要隨著時間的推移而發生變化以滿足新的需求和挑戰，並構建靈活性以支援這一點。

降低風險並進行建模以進行分析

使用設計工具、視覺化工具、建模系統（例如 UML）來捕獲需求和設計決策。還可以分析影響。不要將模型形式化到抑制輕鬆迭代和調整設計的程度。

使用模型和視覺化作為溝通和協作工具

有效地傳達設計、決策和對設計的持續更改對於良好的架構至關重要。使用模型、檢視和其他架構視覺化來有效地與所有利益相關者溝通和共享設計。這使得能夠快速傳達對設計的更改。

識別和理解關鍵的工程決策以及最常出錯的領域。投資於第一次做出正確的關鍵決策，以使設計更靈活，並且不太可能因更改而被破壞。

使用增量和迭代方法

從基線架構開始，然後透過迭代測試來發展候選架構以改進架構。在多次傳遞中迭代地向設計新增詳細資訊以獲得全域性或正確的圖片，然後專注於細節。

關鍵設計原則

以下是設計原則，應考慮用於最大程度地降低成本、維護需求並最大程度地提高架構的可擴充套件性和可用性：

關注點分離

將系統元件劃分為特定功能，以便元件功能之間沒有重疊。這將提供高內聚和低耦合。這種方法避免了系統元件之間的相互依賴關係，這有助於輕鬆維護系統。

單一責任原則

系統的每個模組都應該具有一個特定的責任，這有助於使用者清楚地理解系統。它還有助於將元件與其他元件整合。

最小知識原則

任何元件或物件都不應該瞭解其他元件的內部細節。這種方法避免了相互依賴關係，並有助於維護性。

最大程度地減少前期大型設計

如果應用程式的需求不明確，則最大程度地減少前期大型設計。如果存在修改需求的可能性，則避免為整個系統進行大型設計。

不要重複功能

不要重複功能指定元件的功能不應重複，因此程式碼片段應僅在一個元件中實現。應用程式內功能的重複可能會使實現更改變得困難，降低清晰度並引入潛在的不一致性。

在重用功能時，優先選擇組合而不是繼承

繼承會在子類和父類之間建立依賴關係，因此它會阻止子類的自由使用。相比之下，組合提供了高度的自由度並減少了繼承層次結構。

識別元件並將它們分組到邏輯層中

識別系統中滿足需求所需的元件和關注領域。然後將這些相關的元件分組到邏輯層中，這將幫助使用者在高級別上理解系統的結構。避免在同一層中混合不同型別關注點的元件。

定義層之間的通訊協議

理解元件之間如何通訊，這需要全面瞭解部署場景和生產環境。

定義層級的資料格式

各種元件將透過資料格式相互互動。不要混合使用資料格式，以便應用程式易於實現、擴充套件和維護。嘗試對同一層級使用相同的資料格式，這樣各種元件在相互通訊時就不需要編碼/解碼資料。這可以減少處理開銷。

系統服務元件應是抽象的

與安全、通訊或系統服務（如日誌記錄、分析和配置）相關的程式碼應抽象到單獨的元件中。不要將此程式碼與業務邏輯混合，因為這樣可以輕鬆擴充套件設計並進行維護。

設計異常和異常處理機制

提前定義異常，可以幫助元件以優雅的方式管理錯誤或意外情況。整個系統中的異常管理將保持一致。

命名約定

應提前定義命名約定。它們提供了一個一致的模型，幫助使用者輕鬆理解系統。團隊成員更容易驗證其他人編寫的程式碼，從而提高可維護性。