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

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

什么是架構(gòu)?

??軟件界的人們長期以來一直在爭論架構(gòu)的定義。對(duì)于某些人來說还棱，這就像是系統(tǒng)的基本組織载慈，或者是將最高級(jí)別的組件連接在一起的方式。 我對(duì)此的想法是由與拉爾夫·約翰遜（Ralph Johnson）進(jìn)行的電子郵件交流形成的珍手，后者對(duì)這一措辭提出了質(zhì)疑办铡，認(rèn)為沒有客觀的方法來定義基礎(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è)棘手的問題-因?yàn)檫@不是他們能馬上感知的東西。但是其障，糟糕的架構(gòu)是促成雜亂無章的主要因素达罗，雜亂無章是軟件的要素，阻礙了開發(fā)人員理解軟件的能力静秆。包含大量附加內(nèi)容的軟件難以修改粮揉，導(dǎo)致功能實(shí)現(xiàn)的速度更慢，缺陷也很多抚笔。

image

在2015年的OSCON上鸿秆，我作了簡短的演講（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è)問題是對(duì)應(yīng)用是什么沒有明確的定義考婴。我認(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ā)中尚未解決的問題之一就是確定軟件的邊界是什么在岂。（瀏覽器是不是操作系統(tǒng)的一部分奔则？）面向服務(wù)體系結(jié)構(gòu)的許多支持者認(rèn)為應(yīng)用將不復(fù)存在-因此，未來的企業(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ù)可以用不同的編程語言編寫食铐，使用不同的數(shù)據(jù)存儲(chǔ)技術(shù)，對(duì)這些服務(wù)可進(jìn)行最基本的集中管理僧鲁。盡管它們的優(yōu)勢使它們在最近幾年非常流行虐呻，但它們卻伴隨著分銷增加、一致性降低和需要成熟的經(jīng)營管理的代價(jià)寞秃。
馬丁·福勒

Serverless 架構(gòu)

image

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

微前端

image

好的前端開發(fā)很難馋缅。擴(kuò)展前端開發(fā)，使許多團(tuán)隊(duì)可以同時(shí)從事大型復(fù)雜產(chǎn)品開發(fā)則更加困難绢淀。在本文中萤悴，我們將描述最近的一種趨勢，即將前端整體拆分成許多更小皆的、更易于管理的部分覆履，以及這種體系結(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)樗鼪]有很好的文檔記錄遮精。因此居夹，我在這里的寫作試圖更好地了解MVC的真正含義以及它如何通過模型-視圖-表示器（Model-View-Presenter）和其他形式發(fā)展起來的。
2006.7.18

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

image

模塊化一個(gè)信息豐富的程序的一種最常見方法是將其分為三層：展現(xiàn)（UI）本冲，域邏輯（即業(yè)務(wù)邏輯）和數(shù)據(jù)訪問准脂。因此，你經(jīng)常會(huì)看到Web 應(yīng)用程序被劃分為Web 層（了解如何處理 HTTP 請(qǐng)求和呈現(xiàn) HTML）檬洞、業(yè)務(wù)邏輯層（包含驗(yàn)證和計(jì)算）意狠，數(shù)據(jù)訪問層（整理如何管理數(shù)據(jù)庫或遠(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)看起來是跨大型企業(yè)的體系結(jié)構(gòu)环戈。這樣的組織通常太大了，無法將其所有軟件按任何一種有凝聚的方式進(jìn)行分組澎灸，因此需要跨多個(gè)具有相互獨(dú)立開發(fā)的代碼庫的團(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)決策糜颠。這樣的小組減慢了決策的速度汹族，無法真正理解如此廣泛的系統(tǒng)組合中的問題，從而導(dǎo)致決策不力其兴。但是另一個(gè)極端是根本沒有協(xié)調(diào)顶瞒，這導(dǎo)致團(tuán)隊(duì)重復(fù)工作，不同系統(tǒng)無法進(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ā)工作的了解過時(shí)体啰，抱怨開發(fā)團(tuán)隊(duì)沒有從整個(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í)威恼。
凱文·掀沸眨基
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ì)來解決持續(xù)存在的業(yè)務(wù)問題植酥。產(chǎn)品模式使團(tuán)隊(duì)能夠快速重新定位，減少端到端的周期時(shí)間弦牡，并允許通過使用短周期迭代來驗(yàn)證實(shí)際收益友驮，同時(shí)保持軟件體系結(jié)構(gòu)的完整性，以保持其長期有效性驾锰。
斯里拉姆·納拉揚(yáng)（Sriram Narayan）
2018.2.20

建筑師電梯-參觀高層

image

許多大型組織都將其 IT 引擎與行政頂層公寓分隔開許多層卸留，這也將業(yè)務(wù)和數(shù)字戰(zhàn)略與執(zhí)行它的重要工作區(qū)分開來。 架構(gòu)師的主要作用是乘坐頂層公寓和機(jī)房之間的電梯椭豫，在任何需要的地方停下來支持這些數(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