公司決定使用軟件解決特定問題，因此它收集了該系統(tǒng)的需求列表。 存在多種用于執(zhí)行需求收集的技術，這些技術通常由團隊使用的軟件開發(fā)過程定義。 但是，架構師在設計軟件解決方案時必須考慮許多其他因素，如圖所示。

image.png

架構師可以在定義域或業(yè)務需求方面進行協(xié)作，但是一項主要職責是定義、發(fā)現(xiàn)和分析軟件必須執(zhí)行的與領域或業(yè)務不直接相關的所有事情：架構特征。

軟件架構與編碼和設計的區(qū)別是什么？許多事情，包括架構師在定義架構特征方面的角色，是獨立于問題域的系統(tǒng)方面的重要問題。許多組織使用各種術語（包括非功能性需求）來描述軟件的這些功能，但是我們不喜歡該術語，因為它是貶義的。架構師創(chuàng)建該術語是為了將架構特征與功能需求區(qū)分開來，但是從語言的角度來看，命名非功能性的東西會帶來負面影響：如何說服團隊充分注意“非功能性”的東西？另一個流行的術語是質量屬性，我們不喜歡它，因為它暗示事后質量評估而不是設計。我們更喜歡架構特征，因為它描述了對架構以及整個系統(tǒng)的成功至關重要的關注點，同時又不影響其重要性。

架構特征滿足三個條件：

• 指定非領域設計注意事項
• 影響設計結構的某些方面
• 對應用程序的成功至關重要

我們定義的這些相互聯(lián)系的部分如圖所示。

image.png

圖中所示的定義除了列出的三個修飾符外，還列出了三個組件：

• 指定非領域設計注意事項
  在設計應用程序時，要求指定了應用程序應執(zhí)行的操作；架構特征指定了成功的運維和設計標準，涉及如何實施的要求以及為何做出某些選擇。例如，一個常見的重要架構特征為應用程序指定了一定的性能水平，而這通常不會出現(xiàn)在需求文檔中。更相關的示例是：沒有需求文檔指出“技術債務”，但這是架構師和開發(fā)人員的常見設計考慮因素。我們在“從領域問題中提取架構特征”中深入討論了顯性和隱性特征之間的區(qū)別。

• 影響設計結構的某些方面
  架構師試圖在項目上描述架構特征的主要原因與設計注意事項有關：此架構特征是否需要特殊的結構考慮才能成功？例如，安全實際上是每個項目的關注點，并且所有系統(tǒng)都必須在設計和編碼過程中采取預防措施基準。但是，當架構師需要設計一些特殊的東西時，它會上升到架構特征的水平。在示例系統(tǒng)中，考慮兩種圍繞付款的情況：

  • 第三方付款處理器
    如果在集成點處理付款明細，則該架構不需要特殊的結構考慮。該設計應包含標準的安全措施，例如加密和散列，但不需要特殊的結構。

  • 應用程序內付款處理
    如果正在設計的應用程序必須處理付款，則架構師可以為此目的設計特定的模塊、組件或服務，以從結構上隔離關鍵的安全問題?，F(xiàn)在，架構特征對架構和設計都有影響。

當然，在很多情況下，即使是這兩個標準也不足以做出此決定：在此決策過程中，可能會出現(xiàn)過去的安全事件，與第三方集成的性質以及許多其他標準。它仍然顯示了架構師在確定如何為某些功能進行設計時必須考慮的一些注意事項。

• 對應用程序成功至關重要
  應用程序可以支持大量的架構特征，但是不應該如此。對每個架構特征的支持增加了設計的復雜性。因此，對于架構師來說，一項關鍵工作在于選擇最少的架構特征，而不是選擇最大的可能性。

我們進一步將架構特征細分為隱式和顯式架構特征。隱性需求很少出現(xiàn)在需求中，但它們對于項目成功是必不可少的。例如，可用性、可靠性和安全性實際上是所有應用程序的基礎，但很少在設計文檔中指定它們。架構師必須在分析階段使用他們對問題領域的了解來發(fā)現(xiàn)這些架構特征。例如，高頻交易公司可能不必在每個系統(tǒng)中都指定低延遲，但是該問題領域的架構師知道這有多重要。明確的架構特征出現(xiàn)在需求文檔或其他特定說明中。

在圖中，故意選擇三角形：每個定義元素都支持其他元素，而后者又支持系統(tǒng)的整體設計。三角形創(chuàng)建的支點說明了以下事實，即這些架構特征經常相互交互，從而導致架構師在折衷一詞中普遍使用。

已列出架構特征（部分）

架構特征存在于整個軟件系統(tǒng)中，范圍從低級代碼特征（例如模塊化）到復雜的操作問題（例如可伸縮性和彈性）。盡管過去曾嘗試編成標準，但沒有真正的通用標準存在。相反，每個組織都會對這些術語創(chuàng)建自己的解釋。此外，由于軟件生態(tài)系統(tǒng)變化如此之快，因此不斷出現(xiàn)新的概念、術語、度量和驗證，從而為架構特征定義提供了新的機會。

盡管數(shù)量眾多、規(guī)模龐大，但架構師通常將架構特征分為幾大類。以下各節(jié)描述了一些示例。

運維架構特征

運維架構的特性涵蓋了性能、可伸縮性、彈性、可用性和可靠性等功能。下表列出了一些運維i架構特征。

表——一般運維架構特征

運維架構特征與運維和DevOps關注點嚴重重疊，在許多軟件項目中形成了這些關注點的交集。

結構架構特征
架構師必須關注代碼結構。 在許多情況下，架構師對代碼質量問題負全責或共同承擔責任，例如良好的模塊化，組件之間的受控耦合，可讀代碼以及許多其他內部質量評估。 下表列出了一些結構架構特征。

表——結構架構特征

橫切架構特征

盡管許多架構特征屬于易于識別的類別，但許多特征屬于不合理的分類，但卻構成了重要的設計約束和考慮因素。 下表說明了其中一些。

表——橫切架構特征

任何架構特征列表都必然是不完整的列表。 任何軟件都可以基于獨特因素來發(fā)明重要的架構特征。

此外，許多先前的術語不精確且含糊不清，有時是由于細微的差別或缺乏客觀的定義。例如，互操作性和兼容性可能看起來是等效的，這在某些系統(tǒng)中是正確的。但是，它們之間存在差異，因為互操作性意味著易于與其他系統(tǒng)集成，而后者又意味著已發(fā)布的，已記錄的API。另一方面，兼容性更關注行業(yè)和領域標準。另一個例子是學習能力。一個定義是用戶學習使用軟件的難易程度，另一個定義是系統(tǒng)可以自動了解其環(huán)境以使用機器學習算法進行自我配置或自我優(yōu)化的級別。

許多定義重疊。例如，考慮可用性和可靠性，它們幾乎在所有情況下都重疊。但是請考慮基于TCP的互聯(lián)網協(xié)議UDP。 UDP通過IP可用，但不可靠：數(shù)據(jù)包可能會亂序到達，接收方可能不得不再次要求丟失數(shù)據(jù)包。

沒有完整的標準列表。國際標準組織（ISO）發(fā)布了按功能組織的列表，與我們列出的許多功能重疊，但主要是建立了不完整的類別列表。以下是一些ISO定義：

• 性能效率
  相對于已知條件下使用的資源量的性能度量。這包括時間行為（響應的度量、處理時間和/或吞吐率的度量），資源利用率（使用的資源的數(shù)量和類型）和容量（超出最大已建立限制的程度）。

• 兼容性
  產品、系統(tǒng)或組件可以在共享相同硬件或軟件環(huán)境的同時與其他產品、系統(tǒng)或組件交換信息和/或執(zhí)行其所需功能的程度。它包括共存（可以在與其他產品共享公共環(huán)境和資源的同時有效地執(zhí)行其所需的功能）和互操作性（兩個或多個系統(tǒng)可以交換和利用信息的程度）。

• 易用性
  用戶可以針對其預期目的有效、高效且令人滿意地使用該系統(tǒng)。它包括適當性可識別性（用戶可以識別軟件是否適合他們的需求）、可學習性（用戶可以輕松學習如何使用軟件）、用戶錯誤保護（防止用戶犯錯誤）和可訪問性（使軟件可用）給具有最廣泛特征和能力的人）。

• 可靠性
  系統(tǒng)在指定條件下指定時間段內運行的程度。此特征包括以下子類別：成熟度（軟件是否滿足正常運行下的可靠性需求）、可用性（軟件可運行且可訪問）、容錯（軟件是否在硬件或軟件故障的情況下仍按預期運行）和可恢復性（通過恢復任何受影響的數(shù)據(jù)并重新建立系統(tǒng)的所需狀態(tài)，軟件可以從故障中恢復）。

• 安全
  該軟件可以保護信息和數(shù)據(jù)的程度，從而使人員或其他產品或系統(tǒng)擁有與其權限類型和授權級別相適應的數(shù)據(jù)訪問程度。這一系列特征包括機密性（只有授權訪問的人才能訪問數(shù)據(jù)）、完整性（軟件可防止未經授權訪問或修改軟件或數(shù)據(jù)）、不可否認性（可以證明已采取行動或事件）、問責制（是否可以跟蹤用戶的用戶操作）和真實性（證明用戶身份）。

• 可維護性
  表示開發(fā)人員可以修改軟件以對其進行改進，糾正或使其適應環(huán)境和/或要求的變化的有效性和效率。此特性包括模塊化（軟件由離散組件組成的程度），可重用性（開發(fā)人員可以在多個系統(tǒng)中使用資產或用于構建其他資產的程度），可分析性（開發(fā)人員如何輕松地收集有關組件的具體指標）軟件），可修改性（開發(fā)人員可以在不引入缺陷或不降低現(xiàn)有產品質量的情況下修改軟件的程度）和可測試性（開發(fā)人員及其他人員測試軟件的容易程度）。

• 可移植性
  開發(fā)人員可以將系統(tǒng)，產品或組件從一種硬件，軟件或其他操作或使用環(huán)境轉移到另一種環(huán)境的程度。此特征包括適應性的子特性（開發(fā)人員可以有效地并有效地使軟件適應不同或不斷發(fā)展的硬件、軟件或其他操作或使用環(huán)境）、可安裝性（可以在指定的環(huán)境中安裝和/或卸載軟件）和可替換性（開發(fā)人員以其他軟件輕松替換功能）。

ISO列表中的最后一項針對軟件的功能方面，我們認為它不屬于該列表：

• 功能適用性
  此特性表示在特定條件下使用時，產品或系統(tǒng)提供滿足規(guī)定和隱含需求的功能的程度。此特征由以下子特征組成：
  • 功能完整性
    功能集涵蓋所有指定任務和用戶目標的程度。
  • 功能正確性
    產品或系統(tǒng)以所需的精度提供正確結果的程度。
  • 功能適當性
    功能在多大程度上促進了特定任務和目標的完成。這些不是架構特征，而是構建軟件的動機要求。這說明了如何思考架構特征和問題域之間的關系。

權衡與最差的架構

由于多種原因，應用程序只能支持我們列出的部分架構特征。首先，每個受支持的特征都需要進行設計工作，也許還需要結構上的支持。其次，更大的問題在于以下事實：每個架構特征通常會對其他特征產生影響。例如，如果架構師想要提高安全性，那么幾乎可以肯定會對性能產生負面影響：應用程序必須進行更多的動態(tài)加密，隱藏私密信息的間接操作以及可能降低性能的其他活動。

隱喻將有助于說明這種相互聯(lián)系。顯然，飛行員經常難以學習如何駕駛直升機，因為這需要對每只手和每只腳進行控制，而改變一只手會影響另一只手。因此，駕駛直升機是一項平衡的工作，它很好地描述了選擇架構特征時的權衡過程。架構師設計支持的每種架構特征都可能使總體設計復雜化。

因此，架構師很少遇到能夠設計系統(tǒng)并使每個架構特征最大化的情況。通常，決策歸結為幾個相互競爭的問題之間的權衡。

提示
永遠不要追求最佳架構，而要追求最差的架構。

太多的架構特征導致通用解決方案試圖解決每個業(yè)務問題，并且這些架構很少起作用，因為設計變得笨拙。

這表明架構師應該努力設計架構，使其盡可能地迭代。如果您可以更輕松地對架構進行更改，則可以減少在第一次嘗試中發(fā)現(xiàn)確切正確內容的壓力。敏捷軟件開發(fā)最重要的教訓之一就是迭代的價值。這在軟件開發(fā)的各個級別（包括架構）都適用。