【注】本文節(jié)譯自： Software Architecture Guide (martinfowler.com)
??當(dāng)軟件行業(yè)的人們談?wù)摗凹軜?gòu)”時(shí)，他們指的是軟件系統(tǒng)內(nèi)部設(shè)計(jì)最重要方面的一個(gè)模糊定義概念。好的架構(gòu)很重要，否則將來(lái)增加新功能會(huì)變得越來(lái)越慢，而且成本更高。

??像軟件世界中的許多人一樣，我一直對(duì)“架構(gòu)”一詞持謹(jǐn)慎態(tài)度，因?yàn)樗ǔ０凳局c編程的分離和不健康的浮夸。但是，我通過(guò)強(qiáng)調(diào)好的架構(gòu)可以支持其自身的發(fā)展，并與編程緊密地交織在一起，來(lái)解決我的擔(dān)憂。我的職業(yè)生涯大部分時(shí)間都圍繞著以下問(wèn)題：好的架構(gòu)是什么樣的，團(tuán)隊(duì)如何創(chuàng)建它，以及如何最好地在我們的開發(fā)組織中培養(yǎng)架構(gòu)思維。該頁(yè)面概述了我對(duì)軟件架構(gòu)的看法，并在這個(gè)網(wǎng)站上有關(guān)為你帶來(lái)更多關(guān)于架構(gòu)的材料。martinfowler.com 上有關(guān)軟件體系結(jié)構(gòu)的材料指南。
馬丁·福勒
2019年8月1日

什么是架構(gòu)?

??軟件界的人們長(zhǎng)期以來(lái)一直在爭(zhēng)論架構(gòu)的定義。對(duì)于某些人來(lái)說(shuō)，這就像是系統(tǒng)的基本組織，或者是將最高級(jí)別的組件連接在一起的方式。 我對(duì)此的想法是由與拉爾夫·約翰遜（Ralph Johnson）進(jìn)行的電子郵件交流形成的，后者對(duì)這一措辭提出了質(zhì)疑，認(rèn)為沒(méi)有客觀的方法來(lái)定義基礎(chǔ)知識(shí)或高級(jí)知識(shí)，而對(duì)架構(gòu)的一個(gè)更好的視角是專家開發(fā)人員達(dá)成共識(shí)的系統(tǒng)設(shè)計(jì)。

QCon拉爾夫·約翰遜（Ralph Johnson）在 QCon 上演講

拉爾夫的電子郵件構(gòu)成了我在IEEE軟件專欄的核心，該專欄討論了軟件架構(gòu)的含義和架構(gòu)師的角色。

為什么架構(gòu)很重要？

??對(duì)于軟件產(chǎn)品的客戶和用戶而言，架構(gòu)是一個(gè)棘手的問(wèn)題-因?yàn)檫@不是他們能馬上感知的東西。但是，糟糕的架構(gòu)是促成雜亂無(wú)章的主要因素，雜亂無(wú)章是軟件的要素，阻礙了開發(fā)人員理解軟件的能力。包含大量附加內(nèi)容的軟件難以修改，導(dǎo)致功能實(shí)現(xiàn)的速度更慢，缺陷也很多。

image

在2015年的OSCON上，我作了簡(jiǎn)短的演講（14分鐘），內(nèi)容涉及什么是架構(gòu)及其重要性。

應(yīng)用架構(gòu)

??軟件開發(fā)中的重要決策會(huì)隨著我們所考慮的上下文規(guī)模而變化。常見的規(guī)模是應(yīng)用程序的規(guī)模，因此是“應(yīng)用程序架構(gòu)”。
??定義應(yīng)用架構(gòu)的第一個(gè)問(wèn)題是對(duì)應(yīng)用是什么沒(méi)有明確的定義。我認(rèn)為應(yīng)用是一種社會(huì)結(jié)構(gòu)：

• 被開發(fā)人員視為一個(gè)單元的代碼體
• 業(yè)務(wù)客戶將其視為一個(gè)單元的一組功能
• 那些有錢的人將其視為單一預(yù)算

??如此寬松的定義導(dǎo)致應(yīng)用的潛在規(guī)模很多，開發(fā)團(tuán)隊(duì)的人數(shù)從幾人到幾百人不等。（您會(huì)注意到，我認(rèn)為規(guī)模是涉及的人員數(shù)量，我認(rèn)為這是衡量此類事情的最有用方法。）此架構(gòu)與企業(yè)架構(gòu)之間的主要區(qū)別在于，圍繞社會(huì)構(gòu)建有一個(gè)重要程度的統(tǒng)一目標(biāo)。

應(yīng)用邊界

??軟件開發(fā)中尚未解決的問(wèn)題之一就是確定軟件的邊界是什么。（瀏覽器是不是操作系統(tǒng)的一部分？）面向服務(wù)體系結(jié)構(gòu)的許多支持者認(rèn)為應(yīng)用將不復(fù)存在-因此，未來(lái)的企業(yè)軟件開發(fā)將致力于將服務(wù)組裝在一起。
??我不認(rèn)為應(yīng)用的消失和應(yīng)用界限難以劃分的原則一樣的。本質(zhì)上，應(yīng)用是一種社會(huì)結(jié)構(gòu)：
馬丁 · 福勒
2003.9.11

微服務(wù)指南

image

微服務(wù)架構(gòu)模式是一種將單個(gè)應(yīng)用程序開發(fā)為一組小服務(wù)的方法，每個(gè)小服務(wù)都在自己的進(jìn)程中運(yùn)行并與輕量級(jí)機(jī)制（通常是HTTP資源API）進(jìn)行通信。這些服務(wù)圍繞業(yè)務(wù)功能構(gòu)建，并且可以由完全自動(dòng)的部署機(jī)制獨(dú)立部署。這些服務(wù)可以用不同的編程語(yǔ)言編寫，使用不同的數(shù)據(jù)存儲(chǔ)技術(shù)，對(duì)這些服務(wù)可進(jìn)行最基本的集中管理。盡管它們的優(yōu)勢(shì)使它們?cè)谧罱鼛啄攴浅Ａ餍?，但它們卻伴隨著分銷增加、一致性降低和需要成熟的經(jīng)營(yíng)管理的代價(jià)。
馬丁·福勒

Serverless 架構(gòu)

image

無(wú)服務(wù)器架構(gòu)是結(jié)合第三方“后端即服務(wù)”（BaaS）服務(wù)和/或包含在“功能即服務(wù)”（FaaS）平臺(tái)上的托管臨時(shí)容器中運(yùn)行的自定義代碼的應(yīng)用設(shè)計(jì)。通過(guò)使用這些思想以及諸如單頁(yè)應(yīng)用程序之類的相關(guān)思想，這樣的架構(gòu)消除了對(duì)傳統(tǒng)的永遠(yuǎn)在線服務(wù)器組件的大量需求。無(wú)服務(wù)器架構(gòu)可能會(huì)受益于顯著降低的運(yùn)營(yíng)成本、復(fù)雜性和工程交貨時(shí)間，但代價(jià)是增加對(duì)于供應(yīng)商的依賴性和相對(duì)不成熟的支持服務(wù)的依賴。
邁克·羅伯茨
2018.5.22

微前端

image

好的前端開發(fā)很難。擴(kuò)展前端開發(fā)，使許多團(tuán)隊(duì)可以同時(shí)從事大型復(fù)雜產(chǎn)品開發(fā)則更加困難。在本文中，我們將描述最近的一種趨勢(shì)，即將前端整體拆分成許多更小、更易于管理的部分，以及這種體系結(jié)構(gòu)如何提高處理前端代碼的團(tuán)隊(duì)效率。除了討論各種收益和成本外，我們還將介紹一些可用的實(shí)現(xiàn)選項(xiàng)，并且將深入研究一個(gè)演示該技術(shù)的完整示例應(yīng)用。
卡姆·杰克遜
2019.6.19

GUI 架構(gòu)

在 21 世紀(jì)中期，我一直在從事一些寫作項(xiàng)目，這些項(xiàng)目本可以成書，但尚未完成。一個(gè)是關(guān)于用戶界面的架構(gòu)。作為這項(xiàng)工作的一部分，我起草了一份關(guān)于GUI架構(gòu)演變的描述，比較了表單和控件的默認(rèn)方法和模型-視圖-控制器（MVC）模式。MVC 是軟件世界中最難理解的模式之一，這是可以理解的，因?yàn)樗鼪](méi)有很好的文檔記錄。因此，我在這里的寫作試圖更好地了解MVC的真正含義以及它如何通過(guò)模型-視圖-表示器（Model-View-Presenter）和其他形式發(fā)展起來(lái)的。
2006.7.18

展現(xiàn)域數(shù)據(jù)屋

image

模塊化一個(gè)信息豐富的程序的一種最常見方法是將其分為三層：展現(xiàn)（UI），域邏輯（即業(yè)務(wù)邏輯）和數(shù)據(jù)訪問(wèn)。因此，你經(jīng)常會(huì)看到Web 應(yīng)用程序被劃分為Web 層（了解如何處理 HTTP 請(qǐng)求和呈現(xiàn) HTML）、業(yè)務(wù)邏輯層（包含驗(yàn)證和計(jì)算），數(shù)據(jù)訪問(wèn)層（整理如何管理數(shù)據(jù)庫(kù)或遠(yuǎn)程服務(wù)中的持久性數(shù)據(jù)） 。
馬丁·福勒
2015.8.26

企業(yè)架構(gòu)

??應(yīng)用架構(gòu)集中于某種形式的概念性應(yīng)用邊界內(nèi)的體系結(jié)構(gòu)，而企業(yè)架構(gòu)看起來(lái)是跨大型企業(yè)的體系結(jié)構(gòu)。這樣的組織通常太大了，無(wú)法將其所有軟件按任何一種有凝聚的方式進(jìn)行分組，因此需要跨多個(gè)具有相互獨(dú)立開發(fā)的代碼庫(kù)的團(tuán)隊(duì)進(jìn)行協(xié)調(diào)，并需要資金和用戶彼此獨(dú)立運(yùn)作。
??企業(yè)架構(gòu)的大部分內(nèi)容都是關(guān)于了解什么是值得集中協(xié)調(diào)的成本，以及協(xié)調(diào)應(yīng)采取什么形式。一個(gè)極端是中央架構(gòu)小組，它必須批準(zhǔn)企業(yè)中每個(gè)軟件系統(tǒng)的所有架構(gòu)決策。這樣的小組減慢了決策的速度，無(wú)法真正理解如此廣泛的系統(tǒng)組合中的問(wèn)題，從而導(dǎo)致決策不力。但是另一個(gè)極端是根本沒(méi)有協(xié)調(diào)，這導(dǎo)致團(tuán)隊(duì)重復(fù)工作，不同系統(tǒng)無(wú)法進(jìn)行互操作以及團(tuán)隊(duì)之間缺乏技能開發(fā)和交叉學(xué)習(xí)。
??像大多數(shù)具有敏捷心態(tài)的人一樣，我更喜歡在分散化方面犯錯(cuò)，因此會(huì)更趨于混亂，而不是令人窒息的控制。但是，站在渠道的那一邊仍然意味著我們必須避開險(xiǎn)阻，并以要最小化實(shí)際成本的方式最大化本地決策。

企業(yè)架構(gòu)師加入團(tuán)隊(duì)

image

企業(yè)架構(gòu)組經(jīng)常遠(yuǎn)離日常開發(fā)。這可能會(huì)導(dǎo)致他們對(duì)開發(fā)工作的了解過(guò)時(shí)，抱怨開發(fā)團(tuán)隊(duì)沒(méi)有從整個(gè)公司的角度出發(fā)。我的同事（ThoughtWorks CTO）Rebecca 經(jīng)?？吹竭@種情況發(fā)生，她認(rèn)為加入開發(fā)團(tuán)隊(duì)可以提高企業(yè)架構(gòu)師的效率。
瑞貝卡·帕森斯（Rebecca Parsons）
2005.9

企業(yè)架構(gòu)師在精益企業(yè)中的角色

image

當(dāng)組織采取敏捷的思維方式時(shí)，企業(yè)架構(gòu)不會(huì)消失，但是企業(yè)架構(gòu)師的角色會(huì)發(fā)生變化。 企業(yè)架構(gòu)師不再做出選擇，而是幫助其他人做出正確的選擇，然后傳播這些信息。企業(yè)架構(gòu)師仍然需要形成愿景，然后需要在團(tuán)隊(duì)之間建立橋梁，以構(gòu)建學(xué)習(xí)社區(qū)。這將允許團(tuán)隊(duì)與企業(yè)架構(gòu)師作為合作伙伴，在發(fā)展中探索新方法并相互學(xué)習(xí)。
凱文·?；?br> 2015.11.30

產(chǎn)品超越項(xiàng)目

軟件項(xiàng)目是一種流行的資助和組織軟件開發(fā)的方式。他們將工作組織成臨時(shí)的、只負(fù)責(zé)構(gòu)建的團(tuán)隊(duì)，并由業(yè)務(wù)案例中預(yù)計(jì)的特定收益提供資金。產(chǎn)品模式使用持久的，由構(gòu)思-構(gòu)建-運(yùn)行的團(tuán)隊(duì)來(lái)解決持續(xù)存在的業(yè)務(wù)問(wèn)題。產(chǎn)品模式使團(tuán)隊(duì)能夠快速重新定位，減少端到端的周期時(shí)間，并允許通過(guò)使用短周期迭代來(lái)驗(yàn)證實(shí)際收益，同時(shí)保持軟件體系結(jié)構(gòu)的完整性，以保持其長(zhǎng)期有效性。
斯里拉姆·納拉揚(yáng)（Sriram Narayan）
2018.2.20

建筑師電梯-參觀高層

image

許多大型組織都將其 IT 引擎與行政頂層公寓分隔開許多層，這也將業(yè)務(wù)和數(shù)字戰(zhàn)略與執(zhí)行它的重要工作區(qū)分開來(lái)。 架構(gòu)師的主要作用是乘坐頂層公寓和機(jī)房之間的電梯，在任何需要的地方停下來(lái)支持這些數(shù)字工作：自動(dòng)化軟件制造、最小化前期決策并在技術(shù)發(fā)展的同時(shí)影響組織。
格雷戈?duì)枴せ襞澹℅regor Hohpe）
2017.5.24

使用 REST 進(jìn)行企業(yè)集成

image

大多數(shù)內(nèi)部 EST API 是為單個(gè)集成點(diǎn)構(gòu)建的一次性API。在本文中，我將討論非公共 API 所具有的約束和靈活性，以及在多個(gè)團(tuán)隊(duì)之間進(jìn)行大規(guī)模 RESTful 集成的經(jīng)驗(yàn)教訓(xùn)。
布蘭登·拜爾斯（Brandon Byars）
2013.11.18