本書討論如下內(nèi)容：
- 架構(gòu)模式：許多架構(gòu)決策的技術(shù)基礎(chǔ)。
- 組件：識(shí)別、耦合、內(nèi)聚、分區(qū)和粒度。
- 軟技能：有效的團(tuán)隊(duì)管理、會(huì)議、談判、演示等。
- 現(xiàn)代性：在過去幾年中發(fā)生了根本性變化的工程實(shí)踐和操作方法。
- 架構(gòu)作為一門工程學(xué)科：可重復(fù)的結(jié)果、指標(biāo)和具體的評(píng)估為軟件體系結(jié)構(gòu)增加了嚴(yán)格性。
"軟件架構(gòu)師"職位出現(xiàn)在眾多最佳職位列表的頂部。但卻沒有科學(xué)的方法教授如何成為架構(gòu)師的原因？
- 首先，業(yè)界對(duì)軟件架構(gòu)本身沒有很好的定義。
- 第二，軟件架構(gòu)師的角色的職責(zé)范圍不斷地?cái)U(kuò)大。
- 第三，由于快速發(fā)展的軟件開發(fā)生態(tài)系統(tǒng)，軟件架構(gòu)的目標(biāo)不斷發(fā)生變化。
- 第四，關(guān)于軟件架構(gòu)的許多材料都已成為過去時(shí)。
軟件架構(gòu)由系統(tǒng)的結(jié)構(gòu)（表示支持架構(gòu)的粗黑線）和系統(tǒng)必須支持的架構(gòu)特征（``-ilities''）、架構(gòu)決策以及最終的設(shè)計(jì)原則組成。
系統(tǒng)的結(jié)構(gòu)是指系統(tǒng)所實(shí)現(xiàn)的架構(gòu)樣式的類型（如微服務(wù)，分層或微內(nèi)核）。 僅通過結(jié)構(gòu)來描述架構(gòu)并不能完全闡明架構(gòu)。
架構(gòu)特征是定義軟件架構(gòu)的另一個(gè)維度。 架構(gòu)特征定義了系統(tǒng)的成功標(biāo)準(zhǔn)，該標(biāo)準(zhǔn)通常與系統(tǒng)的功能正交。 請(qǐng)注意，列出的所有特征都不需要了解系統(tǒng)功能，但是它們是使系統(tǒng)正常運(yùn)行所必需的。
架構(gòu)決策定義了應(yīng)如何構(gòu)建系統(tǒng)的規(guī)則。
如果由于某種條件或其他約束而無法在系統(tǒng)的某個(gè)部分中實(shí)施特定的體系結(jié)構(gòu)決策，則可以通過稱為方差的方法打破該決策（或規(guī)則）。 大多數(shù)組織都有架構(gòu)審查委員會(huì)（ARB）或首席架構(gòu)師使用的差異模型。 這些模型將尋求與特定標(biāo)準(zhǔn)或架構(gòu)決策的差異的過程形式化。 ARB將分析特定架構(gòu)決策的例外情況（如果沒有ARB，則由首席架構(gòu)師進(jìn)行分析），并根據(jù)理由和權(quán)衡取舍批準(zhǔn)或拒絕該例外情況。
設(shè)計(jì)原則與體系結(jié)構(gòu)決定的不同之處在于，設(shè)計(jì)原則是一種準(zhǔn)則，而不是一成不變的規(guī)則。
與給定的角色，職務(wù)或職位描述無關(guān)，對(duì)軟件架構(gòu)師有八項(xiàng)核心期望：
- 制定架構(gòu)決策
期望架構(gòu)師定義用于指導(dǎo)團(tuán)隊(duì)、部門或整個(gè)企業(yè)的技術(shù)決策的架構(gòu)決策和設(shè)計(jì)原則。 - 持續(xù)分析架構(gòu)
期望架構(gòu)師不斷分析架構(gòu)和當(dāng)前技術(shù)環(huán)境，然后提出改進(jìn)建議。 - 緊跟最新趨勢(shì)
希望建筑師能夠了解最新的技術(shù)和行業(yè)趨勢(shì)。 - 確保遵守決定
期望架構(gòu)師確保遵守架構(gòu)決策和設(shè)計(jì)原則。 - 多樣的曝光和經(jīng)驗(yàn)
架構(gòu)師應(yīng)具有多種多樣的技術(shù)、框架、平臺(tái)和環(huán)境。 - 具有業(yè)務(wù)領(lǐng)域知識(shí)
架構(gòu)師應(yīng)具備一定水平的業(yè)務(wù)領(lǐng)域?qū)I(yè)知識(shí)。 - 具有人際交往能力
建筑師應(yīng)具備出色的人際交往能力，包括團(tuán)隊(duì)合作、促進(jìn)和領(lǐng)導(dǎo)才能。 - 了解和駕馭政治
期望架構(gòu)師了解企業(yè)的政治氛圍并能夠駕馭政治。
架構(gòu)交叉點(diǎn)
- 工程實(shí)踐
傳統(tǒng)上，軟件體系結(jié)構(gòu)與用于創(chuàng)建軟件的開發(fā)過程是分開的。 存在數(shù)十種流行的方法來構(gòu)建軟件，包括瀑布式和許多敏捷的風(fēng)格（例如Scrum方法、極限編程、精益和Crystal方法），這些方法大部分不會(huì)影響軟件體系結(jié)構(gòu)。 - 運(yùn)維/DevOps
由于對(duì)架構(gòu)公認(rèn)的一些重新思考，DevOps的出現(xiàn)是架構(gòu)與相關(guān)領(lǐng)域之間最近最明顯的交集。 多年以來，許多公司都將運(yùn)維視為與軟件開發(fā)分開的功能。 他們通常將運(yùn)維外包給另一家公司以節(jié)省成本。 在1990年代和2000年代設(shè)計(jì)的許多架構(gòu)都假定架構(gòu)師無法控制運(yùn)維，并且圍繞該限制進(jìn)行防御性的構(gòu)建。 - 流程
另一個(gè)公理是，軟件架構(gòu)通常與軟件開發(fā)過程正交。構(gòu)建軟件（過程）的方式對(duì)軟件架構(gòu)（結(jié)構(gòu)）的影響很小。因此，盡管團(tuán)隊(duì)使用的軟件開發(fā)過程對(duì)軟件架構(gòu)有一定影響（特別是在工程實(shí)踐方面），但從歷史上看，它們大多是分開的。大多數(shù)有關(guān)軟件架構(gòu)的書都忽略了軟件開發(fā)過程，對(duì)可預(yù)測(cè)性等問題做出了虛假的假設(shè)。但是，團(tuán)隊(duì)開發(fā)軟件的過程會(huì)影響軟件架構(gòu)的許多方面。例如，由于軟件的性質(zhì)，在過去的幾十年中，許多公司都采用了敏捷開發(fā)方法。敏捷項(xiàng)目中的架構(gòu)師可以進(jìn)行迭代開發(fā)，因此可以更快地反饋決策。反過來，這使架構(gòu)師可以更加積極地進(jìn)行實(shí)驗(yàn)以及依賴反饋的其他知識(shí)。 - 數(shù)據(jù)
應(yīng)用程序開發(fā)中有很大一部分包括外部數(shù)據(jù)存儲(chǔ)，通常是關(guān)系數(shù)據(jù)庫（或越來越多的NoSQL）。 但是，許多有關(guān)軟件架構(gòu)的書都只包含對(duì)架構(gòu)這一重要方面的簡(jiǎn)要介紹。 代碼和數(shù)據(jù)具有共生關(guān)系：沒有其他代碼，一個(gè)代碼就無用。
軟件架構(gòu)法則
軟件體系結(jié)構(gòu)中的所有內(nèi)容都是一個(gè)折衷方案。 ——軟件架構(gòu)第一定律
為什么比如何更重要。 ——軟件架構(gòu)第二定律
