識別架構(gòu)特性是創(chuàng)建架構(gòu)或確定現(xiàn)有架構(gòu)有效性的第一步。?為給定的問題或應(yīng)用程序識別正確的架構(gòu)特性（“ -ilities”），不僅要求架構(gòu)師理解領(lǐng)域問題，而且還與問題域相關(guān)利益者合作，從領(lǐng)域角度確定什么是真正重要的。

架構(gòu)師通過從領(lǐng)域關(guān)注點(diǎn)，需求和隱式領(lǐng)域知識中提取出來，至少可以用三種方式揭示了架構(gòu)特性。我們在這里討論了前面討論過的兩個隱含特性。

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

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

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

案例研究：VASA

瓦薩（Vasa）最初是關(guān)于過度指定架構(gòu)特性并最終失敗項(xiàng)目的故事。它是1626年至1628年間由一位國王建造的瑞典軍艦，他想要有史以來最宏偉的戰(zhàn)艦。到目前為止，般要么是運(yùn)輸部隊(duì)，要么是戰(zhàn)艦-瓦薩兩者都要兼顧！大多數(shù)船只有一個甲板-瓦薩有兩個甲板！所有的大炮的大小都是類似船只的兩倍。盡管專業(yè)的造船者（最終不敢拒絕阿道夫斯國王）感到有些恐懼，但造船者還是完成了建造工作。為了慶祝，這艘船駛?cè)敫劭?，向一?cè)開炮致敬。不幸的是，由于這只船很重，它翻了并沉到了瑞典海灣的底部。20世紀(jì)初期，有人打撈出來了這只船，該船現(xiàn)在位于斯德哥爾摩的一家博物館中。

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

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

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

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

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

Katas架構(gòu)的起源

幾年前，著名的架構(gòu)師Ted Neward發(fā)明了KATAS架構(gòu)，這是一種聰明的方法，它提出了指導(dǎo)初出茅廬的架構(gòu)師練習(xí)從面向領(lǐng)域的描述派生架構(gòu)特性。來自日本的武術(shù)，空手道是一項(xiàng)單獨(dú)的訓(xùn)練練習(xí)，重點(diǎn)在于適當(dāng)?shù)男问胶图记伞?/p>

我們?nèi)绾潍@得優(yōu)秀的設(shè)計(jì)師？當(dāng)然，偉大的設(shè)計(jì)師會設(shè)計(jì)。

弗雷德·布魯克斯

那么，如果他們的職業(yè)生涯只獲得最多六次的機(jī)會，那么我們應(yīng)該如何去獲得優(yōu)秀的架構(gòu)師呢？

為了有抱負(fù)的架構(gòu)師提供課程，Ted創(chuàng)建了第一個架構(gòu)katas網(wǎng)站，作者Neal和Mark對其進(jìn)行了修改和更新。kata練習(xí)的基本前提為架構(gòu)師提供了一個用領(lǐng)域術(shù)語和其他上下文陳述的問題（可能不會出現(xiàn)在需求中但會影響設(shè)計(jì)的事物）。小型團(tuán)隊(duì)進(jìn)行45分鐘的設(shè)計(jì)工作，然后向其他小組展示結(jié)果，然后由其他小組對誰提出了最佳架構(gòu)進(jìn)行投票。真正符合其最初目的的架構(gòu)套件為有抱負(fù)的架構(gòu)師提供了有用的實(shí)驗(yàn)室。

每個kata都有預(yù)定義的部分：

描述

系統(tǒng)正在嘗試解決的整體領(lǐng)域問題

用戶數(shù)

系統(tǒng)的預(yù)期用戶數(shù)和/或類型

要求

架構(gòu)師可能會期望領(lǐng)域用戶/領(lǐng)域?qū)＜?領(lǐng)域級別要求

幾年后，Neal在他的博客上更新了格式，并在每個kata中添加了附加的上下文部分，并增加了重要的注意事項(xiàng)，使練習(xí)更加現(xiàn)實(shí)。

其他背景

架構(gòu)師必須考慮的許多問題并未在需求中明確表達(dá)，而是通過對問題領(lǐng)域的隱性知識來表達(dá)

我們鼓勵蓬勃發(fā)展的架構(gòu)師使用該網(wǎng)站進(jìn)行自己的kata練習(xí)。任何人都可以舉辦一個“午餐會”，一個有抱負(fù)的架構(gòu)師團(tuán)隊(duì)可以解決一個問題，并讓一個有經(jīng)驗(yàn)的架構(gòu)師來評估設(shè)計(jì)和權(quán)衡分析，無論是現(xiàn)場還是事后的簡短分析。由于練習(xí)是有時間限制的，因此設(shè)計(jì)不會很復(fù)雜。團(tuán)隊(duì)成員最好從經(jīng)驗(yàn)豐富的架構(gòu)中獲得有關(guān)遺漏的權(quán)衡和替代設(shè)計(jì)的反饋。

案例研究：Silicon Sandwiches

為了說明幾個概念，我們使用了kata架構(gòu)（有關(guān)概念的起源，請參見“ Katas的起源”）。?為了說明架構(gòu)師如何從需求中獲取架構(gòu)特性，我們介紹了Silicon Sandwiches kata。

描述

#家全國性的三明治店希望能夠?qū)崿F(xiàn)在線訂購（除了目前的叫賣服務(wù)）。

用戶數(shù)

#目前幾千，也許有一天到百萬

要求

?#用戶將下訂單，然后給他們前往商店拿起三明治的路線（商店必須與包括交通信息在內(nèi)的多個外部地圖服務(wù)集成）

?#如果商店提供送貨服務(wù)，請向駕駛員派發(fā)三明治

?#支持移動設(shè)備

?#提供全國每日促銷/特價

?#提供當(dāng)?shù)孛咳沾黉N/特價

?#在線，現(xiàn)場交付時接受付款

其他背景

?#三明治店專營權(quán)，每個店主擁有不同的所有者

?#母公司有近期計(jì)劃向海外擴(kuò)張

?#公司的目標(biāo)是雇用廉價的勞動力以使利潤最大化

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

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

顯式特性

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

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

但是，我們可能還需要彈性?-處理突發(fā)請求的能力。這兩個特性通?？雌饋硎腔煸谝黄鸬模撬鼈冇胁煌募s束。可伸縮性看起來如圖5-1所示。

圖5-1。可伸縮性衡量并發(fā)用戶的性能

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

圖5-2。彈性系統(tǒng)必須承受大量用戶

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

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

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

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

（2）如果商店提供送貨服務(wù)，請向駕駛員派發(fā)三明治。似乎不需要特殊的架構(gòu)特性來支持此要求。

（3）移動設(shè)備的可訪問性。

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

（4）提供全國性的日常促銷/特價。

（5）提供當(dāng)?shù)孛咳沾黉N/特價。

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

（6）在線，當(dāng)面或交付時接受付款。

在線支付暗含安全性，但此要求中沒有任何一項(xiàng)暗示著安全級別超出了隱含的范圍。

（7）三明治店是專營店，每個店都有不同的所有者。

此要求可能會對架構(gòu)施加成本限制-架構(gòu)師應(yīng)檢查可行性（應(yīng)用諸如成本，時間和員工技能集之類的約束），以查看是否需要使用簡單或犧牲性架構(gòu)。

（8）母公司有近期向海外擴(kuò)張的計(jì)劃。

這個要求意味著國際化，或國際化。存在許多設(shè)計(jì)技術(shù)來滿足此要求，這些技術(shù)不需要特殊的結(jié)構(gòu)即可適應(yīng)。但是，這肯定會推動設(shè)計(jì)決策。

（9）公司的目標(biāo)是雇用廉價的勞動力以最大化利潤。

這項(xiàng)要求表明可用性將很重要，但是與設(shè)計(jì)特性相比，它更關(guān)注設(shè)計(jì)。

我們從上述要求得出的第三個架構(gòu)特性是性能：沒有人愿意從性能不佳的三明治店購買，尤其是在高峰時段。但是，性能是一個微妙的概念-?架構(gòu)師應(yīng)設(shè)計(jì)什么樣的性能？我們將在第6章介紹性能的各種細(xì)微差別。

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

隱式特性

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

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

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

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

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

設(shè)計(jì)與架構(gòu)和權(quán)衡

在里面?設(shè)計(jì)師Silicon Siliconwichs kata可能會將可定制性確定為系統(tǒng)的一部分，但是問題就變成了：架構(gòu)還是設(shè)計(jì)？該架構(gòu)包含一些結(jié)構(gòu)組件，而設(shè)計(jì)則駐留在該架構(gòu)內(nèi)。在Silicon Sandwiches的可定制性案例中，架構(gòu)師可以選擇微內(nèi)核之類的架構(gòu)樣式，并為定制建立結(jié)構(gòu)化支持。但是，如果架構(gòu)師出于競爭考慮而選擇了另一種樣式，則開發(fā)人員可以使用“模板方法”設(shè)計(jì)模式實(shí)施自定義，該模式允許父類定義可以在子類中覆蓋的工作流。?哪個設(shè)計(jì)更好？

像所有架構(gòu)一樣，它取決于許多因素。首先，是否有充分的理由（例如性能和耦合）不實(shí)施微內(nèi)核架構(gòu)？其次，一個設(shè)計(jì)是否比另一個設(shè)計(jì)更難獲得其他理想的架構(gòu)特性？第三，在每個設(shè)計(jì)與模式中支持所有架構(gòu)特性需要花費(fèi)多少成本？這種類型的架構(gòu)折衷分析構(gòu)成了架構(gòu)師角色的重要組成部分。

最重要的是，對于架構(gòu)師而言，與軟件系統(tǒng)的開發(fā)人員，項(xiàng)目經(jīng)理，運(yùn)營團(tuán)隊(duì)以及其他共同構(gòu)建者進(jìn)行協(xié)作至關(guān)重要。不應(yīng)從實(shí)現(xiàn)團(tuán)隊(duì)中分離出任何架構(gòu)決策（這會導(dǎo)致可怕的象牙塔架構(gòu)師反模式）。?對于Silicon Sandwiches，架構(gòu)師，技術(shù)負(fù)責(zé)人，開發(fā)人員和領(lǐng)域分析師應(yīng)共同決定如何最好地實(shí)現(xiàn)可定制性。

架構(gòu)師設(shè)計(jì)一種架構(gòu)，該架構(gòu)不能在結(jié)構(gòu)上適應(yīng)可定制性，因此需要設(shè)計(jì)應(yīng)用程序本身來支持該行為（請參閱“設(shè)計(jì)與架構(gòu)和權(quán)衡”）。架構(gòu)師不應(yīng)為發(fā)現(xiàn)完全正確的一組架構(gòu)特性而過分強(qiáng)調(diào)-開發(fā)人員可以通過多種方式實(shí)現(xiàn)功能。但是，正確識別重要的結(jié)構(gòu)元素可能有助于簡化或更優(yōu)雅的設(shè)計(jì)。?架構(gòu)師必須記?。簺]有最佳的架構(gòu)設(shè)計(jì)，只有最差的權(quán)衡取舍。

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

原文 ：http://m.itdecent.cn/p/be678fd8f8fc

全書翻譯目錄：http://m.itdecent.cn/p/05711d172dfa

聲明：本資料僅供學(xué)習(xí)交流嚴(yán)禁使用于任何商業(yè)用途！請購買正版圖書：https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/cover.html

資料整理和翻譯：楊傳池Chris? IT老兵，人生三大愛好（愛好喝茶，喝酒和喜歡做夢）

10+年的軟件研發(fā)和項(xiàng)目管理經(jīng)驗(yàn)；

7+年大型房產(chǎn)信息化、數(shù)字化咨詢經(jīng)驗(yàn)；

50+人以上研發(fā)團(tuán)隊(duì)管理，擅長團(tuán)隊(duì)管理和人才梯隊(duì)建設(shè)；

熟悉研發(fā)管理、工程構(gòu)建、體系建設(shè)、DevOps和領(lǐng)域建模，掌握IT研發(fā)價值鏈和工具鏈。