識(shí)別驅(qū)動(dòng)架構(gòu)特征是創(chuàng)建架構(gòu)或確定現(xiàn)有架構(gòu)有效性的第一步。 為給定問題或應(yīng)用識(shí)別正確的架構(gòu)特征 ("-ilities")，要求架構(gòu)師不僅了解領(lǐng)域問題，而且還與問題領(lǐng)域利益相關(guān)者合作，從領(lǐng)域角度確定真正重要的事情。

架構(gòu)師通過從領(lǐng)域關(guān)注點(diǎn)，需求和隱式領(lǐng)域知識(shí)中提取出來，至少以三種方式揭示了架構(gòu)特征。 前面我們討論了隱式特性，在此介紹另外兩個(gè)。

從領(lǐng)域關(guān)注中提取架構(gòu)特征

架構(gòu)師必須能夠轉(zhuǎn)換領(lǐng)域關(guān)注點(diǎn)，以識(shí)別正確的架構(gòu)特征。例如，可伸縮性是最重要的問題，還是容錯(cuò)性，安全性或性能？也許系統(tǒng)需要將所有四個(gè)特征組合在一起。了解關(guān)鍵的領(lǐng)域目標(biāo)和領(lǐng)域情況，可使架構(gòu)師將這些領(lǐng)域問題轉(zhuǎn)換為"-ilities"，從而為正確、合理的架構(gòu)決策奠定基礎(chǔ)。

與領(lǐng)域涉眾合作定義驅(qū)動(dòng)架構(gòu)特征的一個(gè)技巧是努力使最終清單盡可能短。架構(gòu)中的常見反模式需要嘗試設(shè)計(jì)一種通用架構(gòu)，該架構(gòu)支持所有架構(gòu)特征。架構(gòu)支持的每種架構(gòu)特征使整個(gè)系統(tǒng)的設(shè)計(jì)變得復(fù)雜；在架構(gòu)師和開發(fā)人員甚至沒有開始解決問題域（編寫軟件的原始動(dòng)機(jī)）之前，支持太多的架構(gòu)特征就導(dǎo)致越來越復(fù)雜。不要著迷于特征的數(shù)量，而是要保持設(shè)計(jì)簡(jiǎn)潔的動(dòng)機(jī)。

許多架構(gòu)師和領(lǐng)域涉眾都希望確定應(yīng)用或系統(tǒng)必須支持的最終架構(gòu)特征的優(yōu)先級(jí)。盡管這當(dāng)然是合乎需要的，但在大多數(shù)情況下，這是愚蠢的事，不僅會(huì)浪費(fèi)時(shí)間，而且還會(huì)導(dǎo)致與主要利益相關(guān)者的不必要的挫敗感和分歧。所有利益相關(guān)者很少會(huì)就每個(gè)特征的優(yōu)先級(jí)達(dá)成一致。更好的方法是讓領(lǐng)域涉眾從最終列表中以任何順序選擇前三個(gè)最重要的特征。這不僅容易達(dá)成共識(shí)，而且還引發(fā)了關(guān)于最重要內(nèi)容的討論，并幫助架構(gòu)師在做出重要的架構(gòu)決策時(shí)分析了權(quán)衡取舍。

大多數(shù)架構(gòu)特征來自于聆聽關(guān)鍵領(lǐng)域的利益相關(guān)者并與他們合作以確定從領(lǐng)域角度來看重要的事情。盡管這似乎是一項(xiàng)簡(jiǎn)單的活動(dòng)，但問題是架構(gòu)師和領(lǐng)域涉眾使用不同的語言。架構(gòu)師談?wù)摽缮炜s性、互操作性、容錯(cuò)性、可學(xué)習(xí)性和可用性。領(lǐng)域利益相關(guān)者討論并購(gòu)、用戶滿意度、上市時(shí)間和競(jìng)爭(zhēng)優(yōu)勢(shì)。發(fā)生的是“翻譯丟失”問題，在該問題中，架構(gòu)師和領(lǐng)域利益相關(guān)者彼此不了解。架構(gòu)師不知道如何創(chuàng)建一種架構(gòu)來支持用戶滿意度，并且領(lǐng)域利益相關(guān)者也不了解為什么如此集中精力，而談?wù)搼?yīng)用的可用性、互操作性、可學(xué)習(xí)性和容錯(cuò)性。幸運(yùn)的是，通?？梢詫㈩I(lǐng)域關(guān)注轉(zhuǎn)換為架構(gòu)特征。下表顯示了一些更常見的域問題以及支持它們的相應(yīng)"-ilities"。

表——將領(lǐng)域關(guān)注點(diǎn)轉(zhuǎn)換為架構(gòu)特征

需要注意的重要一件事是敏捷性不等于上市時(shí)間。相反，它是敏捷性+可測(cè)試性+可部署性。這是許多架構(gòu)師在翻譯領(lǐng)域問題時(shí)會(huì)陷入的陷阱。只關(guān)注其中一種成分就像忘記將面粉放入面糊中一樣。例如，某個(gè)領(lǐng)域的利益相關(guān)者可能會(huì)說“由于監(jiān)管要求，我們必須要按時(shí)完成日末基金定價(jià)?！毙实拖碌募軜?gòu)師可能只關(guān)注性能，因?yàn)檫@似乎是該領(lǐng)域關(guān)注的重點(diǎn)。但是，該架構(gòu)師將由于許多原因而失敗。首先，如果系統(tǒng)在需要時(shí)不可用，則系統(tǒng)的速度并不重要。其次，隨著領(lǐng)域的增長(zhǎng)和更多資金的產(chǎn)生，該系統(tǒng)還必須能夠擴(kuò)展以及時(shí)完成日終處理。第三，該系統(tǒng)不僅必須可用，而且還必須可靠，以免在計(jì)算日末基金價(jià)格時(shí)崩潰。第四，如果日末基金定價(jià)已完成約85％，并且系統(tǒng)崩潰，會(huì)發(fā)生什么情況？它必須能夠恢復(fù)并在價(jià)格停止的地方重新啟動(dòng)。最后，該系統(tǒng)可能很快，但是是否正確計(jì)算了基金價(jià)格？因此，除了性能之外，架構(gòu)師還必須同樣關(guān)注可用性、可伸縮性、可靠性、可恢復(fù)性和可審計(jì)性。

從需求中提取架構(gòu)特征

一些架構(gòu)特征來自需求文檔中的明確聲明。例如，明確的預(yù)期用戶數(shù)量和規(guī)模通常會(huì)出現(xiàn)在域或域問題中。其他方面則來自架構(gòu)師固有的領(lǐng)域知識(shí)，這是領(lǐng)域知識(shí)始終對(duì)架構(gòu)師有益的眾多原因之一。例如，假設(shè)一名架構(gòu)師設(shè)計(jì)了一個(gè)處理大學(xué)生班級(jí)注冊(cè)的應(yīng)用。為了簡(jiǎn)化數(shù)學(xué)模型，假設(shè)學(xué)校有1,000名學(xué)生和10個(gè)小時(shí)的注冊(cè)時(shí)間。架構(gòu)師是否應(yīng)該設(shè)計(jì)一個(gè)假設(shè)規(guī)模不變的系統(tǒng)，并隱式地假設(shè)學(xué)生在注冊(cè)過程中會(huì)隨著時(shí)間的推移平均分配自己？或者，基于對(duì)大學(xué)生習(xí)慣和傾向的了解??，架構(gòu)師是否應(yīng)該設(shè)計(jì)一個(gè)系統(tǒng)來處理過去10分鐘內(nèi)嘗試注冊(cè)的所有1,000名學(xué)生？任何了解刻板刻板的學(xué)生數(shù)量的人都知道這個(gè)問題的答案！這樣的細(xì)節(jié)很少會(huì)出現(xiàn)在需求文檔中，但是它們確實(shí)可以為設(shè)計(jì)決策提供依據(jù)。

案例研究：硅谷三明治

為了說明幾個(gè)概念，我們使用了體系結(jié)構(gòu)Kata。為了說明架構(gòu)師如何從需求中獲取架構(gòu)特征，我們介紹了硅谷三明治Kata。

描述
一家國(guó)家三明治店希望啟用在線訂購(gòu)（除了其當(dāng)前的呼叫服務(wù)之外）。

用戶
千，也許有一天百萬

需求

• 用戶將下訂單，然后有時(shí)間拿起三明治和前往商店的路線（商店必須與包括交通信息在內(nèi)的多個(gè)外部地圖服務(wù)集成）
• 如果商店提供送貨服務(wù)，請(qǐng)向駕駛員派發(fā)三明治和三明治
• 移動(dòng)設(shè)備可訪問性
• 提供全國(guó)每日促銷/特價(jià)
• 提供當(dāng)?shù)孛咳沾黉N/特價(jià)
• 接受在線付款，親自付款或在交貨時(shí)付款

其他背景

• 三明治店專營(yíng)權(quán)，每個(gè)店主擁有不同的所有者
• 母公司近期計(jì)劃向海外擴(kuò)張
• 公司目標(biāo)是雇用廉價(jià)勞動(dòng)力以最大程度地提高利潤(rùn)

在這種情況下，架構(gòu)師將如何得出架構(gòu)特征？需求的每個(gè)部分都可能對(duì)架構(gòu)的一個(gè)或多個(gè)方面有所貢獻(xiàn)（很多方面不會(huì)）。架構(gòu)師不會(huì)在這里設(shè)計(jì)整個(gè)系統(tǒng)-仍然必須花費(fèi)大量精力來編寫代碼來解決域聲明。而是，架構(gòu)師尋找影響或影響設(shè)計(jì)的事物，尤其是結(jié)構(gòu)。

首先，將候選架構(gòu)特征分為顯式和隱式特征。

顯式特征

明確的架構(gòu)特征作為必需設(shè)計(jì)的一部分出現(xiàn)在需求規(guī)范中。例如，購(gòu)物網(wǎng)站可能希望支持特定數(shù)量的并發(fā)用戶，這是領(lǐng)域分析師在要求中指定的。架構(gòu)師應(yīng)考慮需求的每個(gè)部分，以了解其是否有助于架構(gòu)特征。但是首先，架構(gòu)師應(yīng)該考慮關(guān)于預(yù)期指標(biāo)的域級(jí)預(yù)測(cè)，如Kata的“用戶”部分所述。

用戶數(shù)量應(yīng)引起架構(gòu)師的關(guān)注，其中第一個(gè)細(xì)節(jié)是用戶數(shù)量：目前有數(shù)千名用戶，也許一天有數(shù)百萬人（這是一家雄心勃勃的三明治店?。?。因此，可伸縮性（在不嚴(yán)重降低性能的情況下處理大量并發(fā)用戶的能力）是最重要的架構(gòu)特征之一。請(qǐng)注意，問題說明并未明確要求可擴(kuò)展性，而是將該要求表示為預(yù)期的用戶數(shù)量。架構(gòu)師必須經(jīng)常將領(lǐng)域語言解碼為等效的工程設(shè)計(jì)。

但是，我們可能還需要彈性—處理突發(fā)請(qǐng)求的能力。這兩個(gè)特征通?？雌饋硎腔煸谝黄鸬?，但是它們有不同的約束?？蓴U(kuò)展性看起來如圖所示。

image.png

另一方面，彈性可衡量流量的爆發(fā)，如圖所示。

image.png

一些系統(tǒng)是可伸縮的，但不是彈性的。例如，考慮一個(gè)旅館預(yù)訂系統(tǒng)。如果沒有特殊的銷售或活動(dòng)，用戶數(shù)量可能會(huì)保持一致。相反，考慮音樂會(huì)門票預(yù)訂系統(tǒng)。隨著新票的發(fā)售，狂熱的粉絲將涌入現(xiàn)場(chǎng)，這需要高度的彈性。彈性系統(tǒng)通常還需要可伸縮性：處理突發(fā)事件和大量并發(fā)用戶的能力。

彈性要求未出現(xiàn)在“硅三明治”要求中，但架構(gòu)師應(yīng)將其確定為重要考慮因素。需求有時(shí)會(huì)直截了當(dāng)?shù)刂赋黾軜?gòu)特征，但在問題領(lǐng)域內(nèi)卻有些潛伏?？紤]一個(gè)三明治店。整天的流量是否一致？還是在進(jìn)餐時(shí)間忍受交通擁擠？幾乎可以肯定是后者。因此，好的架構(gòu)師應(yīng)該確定這種潛在的架構(gòu)特征。

架構(gòu)師應(yīng)依次考慮所有這些業(yè)務(wù)需求，以查看架構(gòu)特征是否存在：

1. 用戶將下訂單，然后有時(shí)間拿起三明治和前往商店的路線（商店必須提供與包含交通信息的外部地圖服務(wù)集成的選項(xiàng)）。
   外部映射服務(wù)暗示集成點(diǎn)，這可能會(huì)影響可靠性等方面。例如，如果開發(fā)人員構(gòu)建的系統(tǒng)依賴于第三方系統(tǒng)，但是調(diào)用失敗，則會(huì)影響調(diào)用系統(tǒng)的可靠性。但是，架構(gòu)師還必須警惕過度指定的架構(gòu)特征。如果外部交通服務(wù)中斷了怎么辦？ 硅谷三明治網(wǎng)站網(wǎng)站是否應(yīng)該失敗，或者在沒有交通信息的情況下其效率會(huì)降低一點(diǎn)？建筑師應(yīng)始終防止在設(shè)計(jì)中造成不必要的脆性或脆弱性。

2. 如果商店提供送貨服務(wù)，請(qǐng)向駕駛員派發(fā)三明治。
   似乎不需要特殊的體系結(jié)構(gòu)特征來支持此要求。

3. 移動(dòng)設(shè)備的可訪問性。
   此要求將主要影響應(yīng)用程序的設(shè)計(jì)，指向構(gòu)建便攜式Web應(yīng)用程序或幾個(gè)本機(jī)Web應(yīng)用程序?？紤]到預(yù)算的限制和應(yīng)用程序的簡(jiǎn)單性，架構(gòu)師可能會(huì)認(rèn)為構(gòu)建多個(gè)應(yīng)用過于刻薄，因此設(shè)計(jì)指向了針對(duì)移動(dòng)設(shè)備進(jìn)行了優(yōu)化的Web應(yīng)用。因此，架構(gòu)師可能希望為頁面加載時(shí)間和其他對(duì)移動(dòng)敏感的特性定義一些特定的性能架構(gòu)特性。請(qǐng)注意，架構(gòu)師不應(yīng)在這種情況下獨(dú)自行動(dòng)，而應(yīng)與用戶體驗(yàn)設(shè)計(jì)師，領(lǐng)域利益相關(guān)者以及其他有關(guān)方面合作，以審查此類決定。

4. 提供全國(guó)性的日常促銷/特價(jià)。

5. 提供當(dāng)?shù)孛咳沾黉N/特價(jià)。
   這兩個(gè)要求都指定了促銷和特價(jià)中的可定制性。請(qǐng)注意，需求1還隱含基于地址的自定義交通信息?；谒羞@三個(gè)需求，架構(gòu)師可以將可定制性視為架構(gòu)特征。例如，微內(nèi)核架構(gòu)等架構(gòu)樣式通過定義插件架構(gòu)，可以很好地支持自定義行為。在這種情況下，默認(rèn)行為會(huì)出現(xiàn)在核心中，并且開發(fā)人員會(huì)根據(jù)位置通過插件編寫可選的自定義部件。但是，傳統(tǒng)設(shè)計(jì)也可以通過設(shè)計(jì)模式（例如模板方法）來滿足此要求。這個(gè)難題在架構(gòu)中很常見，需要架構(gòu)師不斷權(quán)衡各種競(jìng)爭(zhēng)方案之間的權(quán)衡。我們將在“設(shè)計(jì)與架構(gòu)和權(quán)衡”中詳細(xì)討論特定的權(quán)衡。

6. 在線，當(dāng)面或交付時(shí)接受付款。
   在線支付暗含安全性，但此要求中沒有任何一項(xiàng)表明安全性比隱含的安全性特別高。

7. 三明治店是專營(yíng)店，每家店都有不同的所有者。
   此要求可能會(huì)對(duì)架構(gòu)施加成本限制—架構(gòu)師應(yīng)檢查可行性（應(yīng)用諸如成本，時(shí)間和員工技能集之類的約束），以查看是否需要使用簡(jiǎn)單或犧牲性架構(gòu)。

8. 母公司有近期向海外擴(kuò)張的計(jì)劃。
   此要求意味著國(guó)際化，即國(guó)際化。有許多設(shè)計(jì)技術(shù)可以滿足這一要求，而這些技術(shù)不需要特殊的結(jié)構(gòu)即可適應(yīng)。但是，這肯定會(huì)推動(dòng)設(shè)計(jì)決策。

9. 公司的目標(biāo)是雇用廉價(jià)的勞動(dòng)力以最大化利潤(rùn)。
   該要求表明可用性將很重要，但同樣，設(shè)計(jì)更關(guān)注而不是架構(gòu)特征。

從前面的要求中得出的第三個(gè)體系結(jié)構(gòu)特征是性能：沒有人愿意從性能不佳的三明治店購(gòu)買，尤其是在高峰時(shí)段。但是，性能是一個(gè)微妙的概念—架構(gòu)師應(yīng)設(shè)計(jì)什么樣的性能？

我們還希望結(jié)合可伸縮性數(shù)字來定義性能數(shù)字。換句話說，我們必須建立沒有特定規(guī)模的性能基準(zhǔn)，并確定給定數(shù)量的用戶可接受的性能水平。通常，架構(gòu)特性會(huì)相互影響，從而迫使架構(gòu)師彼此定義關(guān)系。

隱式架構(gòu)

需求文檔中并未指定許多架構(gòu)特征，但是它們構(gòu)成了設(shè)計(jì)的重要方面。系統(tǒng)可能要支持的一個(gè)隱式架構(gòu)特征是可用性：確保用戶可以訪問三明治站點(diǎn)?？煽啃耘c可用性密切相關(guān)：可靠性確保網(wǎng)站在交互過程中保持正常運(yùn)行—沒有人愿意從繼續(xù)斷開連接的站點(diǎn)購(gòu)買產(chǎn)品，從而迫使他們重新登錄。

安全似乎是每個(gè)系統(tǒng)的隱含特征：沒有人愿意創(chuàng)建不安全的軟件。但是，可以根據(jù)關(guān)鍵程度對(duì)其進(jìn)行優(yōu)先級(jí)排序，這說明了我們定義的內(nèi)在聯(lián)系。如果安全性影響設(shè)計(jì)的某些結(jié)構(gòu)方面并且對(duì)應(yīng)用程序至關(guān)重要或很重要，則架構(gòu)師會(huì)將安全性視為架構(gòu)特征。

對(duì)于硅谷三明治，架構(gòu)師可能會(huì)假設(shè)付款應(yīng)由第三方處理。因此，只要開發(fā)人員遵循一般的安全習(xí)慣（不將信用卡號(hào)作為純文本傳遞，不存儲(chǔ)太多信息，等等），架構(gòu)師就不需要任何特殊的結(jié)構(gòu)設(shè)計(jì)來適應(yīng)安全性；在應(yīng)用中進(jìn)行良好的設(shè)計(jì)就足夠了。每個(gè)架構(gòu)特征相互影響，導(dǎo)致架構(gòu)師過度說明架構(gòu)特征的共同陷阱，這與未充分說明架構(gòu)特征一樣有害，因?yàn)檫@會(huì)使系統(tǒng)設(shè)計(jì)過于復(fù)雜。

硅谷三明治需要支持的最后一個(gè)主要架構(gòu)特征包括需求中的幾個(gè)細(xì)節(jié)：可定制性。請(qǐng)注意，問題域的某些部分提供了自定義行為：配方，本地銷售和可能在本地被覆蓋的指示。因此，架構(gòu)應(yīng)支持促進(jìn)自定義行為的能力。通常，這將屬于應(yīng)用的設(shè)計(jì)。但是，正如我們的定義所指出的那樣，部分依賴自定義結(jié)構(gòu)來支持它的問題域進(jìn)入了結(jié)構(gòu)特征領(lǐng)域。但是，此設(shè)計(jì)元素對(duì)于應(yīng)用的成功并不關(guān)鍵。重要的是要注意，選擇架構(gòu)特征時(shí)沒有正確的答案，只有不正確的答案：

在架構(gòu)上沒有錯(cuò)誤的答案，只有昂貴的答案。

架構(gòu)師可以設(shè)計(jì)一種架構(gòu)，該架構(gòu)在結(jié)構(gòu)上無法適應(yīng)可定制性，因此需要設(shè)計(jì)應(yīng)用本身來支持這種行為。架構(gòu)師不應(yīng)該過多地強(qiáng)調(diào)發(fā)現(xiàn)完全正確的架構(gòu)特征集，開發(fā)人員可以通過多種方式實(shí)現(xiàn)功能。但是，正確識(shí)別重要的結(jié)構(gòu)元素可能有助于簡(jiǎn)化或更優(yōu)雅的設(shè)計(jì)。架構(gòu)師必須記住：沒有最佳的架構(gòu)設(shè)計(jì)，只有最差的權(quán)衡取舍。

架構(gòu)師還必須優(yōu)先考慮這些架構(gòu)特征，以嘗試找到最簡(jiǎn)單的必需集合。一旦團(tuán)隊(duì)在確定架構(gòu)特征上走了第一步之后，一個(gè)有用的練習(xí)就是嘗試確定最不重要的一個(gè)-如果您必須消除一個(gè)，那會(huì)是什么？通常，由于許多隱式架構(gòu)支持普遍成功，因此架構(gòu)師更傾向于選擇顯式架構(gòu)特征。我們定義對(duì)成功至關(guān)重要或最重要的方法，可以幫助架構(gòu)師確定應(yīng)用是否真正需要每種架構(gòu)特征。通過嘗試確定最不適用的方法，架構(gòu)師可以幫助確定關(guān)鍵需求。對(duì)于硅谷三明治，我們確定的哪個(gè)架構(gòu)特征最不重要？同樣，不存在絕對(duì)正確的答案。但是，在這種情況下，解決方案可能會(huì)失去可定制性或性能。我們可以消除可定制性作為一種架構(gòu)特征，并計(jì)劃將這種行為實(shí)現(xiàn)為應(yīng)用設(shè)計(jì)的一部分。在運(yùn)維架構(gòu)的特征中，性能對(duì)于成功至關(guān)重要。當(dāng)然，開發(fā)人員并不是要構(gòu)建具有糟糕性能的應(yīng)用，而是要建立一個(gè)不將性能置于其他特性（例如可伸縮性或可用性）之上的應(yīng)用。