本指南是[martinfowler.com]上關(guān)于軟件架構(gòu)的材料指南奔穿。原文地址為：https://martinfowler.com/architecture/吗讶。

當軟件行業(yè)的人們談?wù)摗?strong>架構(gòu)”時褒侧，他們指的是一個模糊定義的概念荧库，即軟件系統(tǒng)內(nèi)部設(shè)計的最重要方面涩搓。一個好的架構(gòu)是很重要的柔吼，否則在將來添加新功能會變得更慢筝尾、更昂貴。

和軟件界的許多人一樣，我一直對“架構(gòu)”這個詞保持警惕搭综，因為它常常暗示著與編程的分離和一種不健康的浮夸垢箕。但我通過強調(diào)良好的架構(gòu)是支持其自身發(fā)展的，并且與編程緊密結(jié)合的東西來解決這個問題兑巾。我的大部分職業(yè)生涯都圍繞著什么樣的架構(gòu)是好架構(gòu)的問題条获，并團隊如何創(chuàng)建它，以及如何以最好的形式培養(yǎng)我們的組織中的架構(gòu)思維蒋歌。本頁概述了我對軟件架構(gòu)的看法帅掘，并為您指出了有關(guān)本網(wǎng)站架構(gòu)的更多資料。

什么是架構(gòu)堂油？

軟件界的人們一直在爭論架構(gòu)的定義修档。對某些人來說，這就像是一個系統(tǒng)的基本組織府框，或者是最高級別的組件連接在一起的方式吱窝。我的想法是通過與拉爾夫·約翰遜（Ralph Johnson）的郵件交流形成的，他質(zhì)疑這一措辭迫靖，認為沒有客觀的方法來定義什么是基本的院峡，或者是高層的？好的架構(gòu)是專家對系統(tǒng)設(shè)計的共同理解系宜。

拉爾夫·約翰遜

第二種常見的架構(gòu)定義風(fēng)格是撕予，它是“需要在項目早期做出的設(shè)計決策”，但拉爾夫也對此表示不滿蜈首，他說实抡，這更像是你希望能夠在項目早期做出正確的決策。

他的結(jié)論是“架構(gòu)是最重要的東西欢策。不管那是什么”吆寨。乍一看，這聽起來很老套踩寇，但我發(fā)現(xiàn)它有很多豐富的內(nèi)容啄清。這意味著從架構(gòu)層面思考決定軟件的核心什么（即什么是架構(gòu)），然后花費精力保持這些架構(gòu)元素處于良好的狀態(tài)俺孙。為了讓開發(fā)人員成為架構(gòu)師辣卒，他們需要能夠認識到哪些元素是重要的，認識到如果不加以控制睛榄，哪些元素可能導(dǎo)致嚴重的問題荣茫。

什么是架構(gòu)問題？

對于軟件產(chǎn)品的客戶和用戶來說场靴，架構(gòu)是一個棘手的話題啡莉，因為它不是他們能馬上察覺到的東西港准。但是一個糟糕的架構(gòu)是導(dǎo)致軟件粗糙元素增長的主要原因，這些元素阻礙了開發(fā)人員理解軟件咧欣。包含軟件粗糙元素的系統(tǒng)是很難修改浅缸，并導(dǎo)致特性交付速度更慢，缺陷也更多魄咕。

誠然荔睹，我們可以在短期內(nèi)為更快的交付速度犧牲質(zhì)量狸演，但在粗糙元素的建立產(chǎn)生影響之前，人們低估了粗糙元素導(dǎo)致整體交付速度放緩的速度僻他。雖然這不能客觀地衡量宵距，但有經(jīng)驗的開發(fā)人員認為，對內(nèi)部質(zhì)量的關(guān)注在幾周內(nèi)而不是幾個月內(nèi)就見效了吨拗。

image

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

軟件開發(fā)中的重要決策隨著我們所考慮的上下文的規(guī)模而變化满哪。但有一個共同的尺度是應(yīng)用程序的尺度，因此是“應(yīng)用程序架構(gòu)”劝篷。

定義應(yīng)用程序架構(gòu)的第一個問題是沒有明確定義應(yīng)用程序是什么哨鸭。我認為應(yīng)用程序是一種社會結(jié)構(gòu)：

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

這樣一個松散的定義會導(dǎo)致應(yīng)用程序有許多潛在的大小，從開發(fā)團隊中的幾個人到幾百人不等娇妓。（你會注意到像鸡，我將規(guī)模視為所涉及的人員數(shù)量，我認為這是衡量這類事情的最有用的方法哈恰。）這與企業(yè)架構(gòu)的關(guān)鍵區(qū)別在于只估，在社會建設(shè)方面存在著很大程度的統(tǒng)一目標。

應(yīng)用程序邊界

軟件開發(fā)中一個尚未決定的問題是決定一個軟件的邊界是什么着绷。（瀏覽器是否是操作系統(tǒng)的一部分蛔钙？）許多面向服務(wù)架構(gòu)的支持者認為應(yīng)用程序正在消失，因此未來的企業(yè)軟件開發(fā)將是由服務(wù)組裝在一起形成的荠医。

我不認為應(yīng)用程序會因為同樣的原因而消失夸楣，為什么應(yīng)用程序邊界如此難以劃定。基本上應(yīng)用是社會結(jié)構(gòu)：

By Martin Fowler 2003/09/11

微服務(wù)指南

微服務(wù)架構(gòu)模式是一種將單個應(yīng)用程序開發(fā)為一組小型服務(wù)的方法豫喧，每個服務(wù)都在其自己的進程中運行石洗，并與輕量級機制（通常是http資源api）通信。這些服務(wù)是圍繞業(yè)務(wù)能力構(gòu)建的紧显，可以通過完全自動化的部署機制進行獨立部署讲衫。對這些服務(wù)的集中管理是最低限度的，這些服務(wù)可以用不同的編程語言編寫孵班，并使用不同的數(shù)據(jù)存儲技術(shù)涉兽。雖然它們的優(yōu)勢使它們在過去幾年中非常流行，但它們帶來的代價是增加分布計算篙程、削弱一致性和要求運維成熟枷畏。
By Martin Fowler

無服務(wù)器（Serverless）架構(gòu)

無服務(wù)器架構(gòu)是結(jié)合第三方“后端即服務(wù)”（baas）服務(wù)和/或包括在“功能即服務(wù)”（faas）平臺上的托管、臨時容器中運行的自定義代碼的應(yīng)用程序設(shè)計虱饿。通過使用這些思想和相關(guān)的思想（如單頁面應(yīng)用程序）拥诡，這樣的體系結(jié)構(gòu)消除了對傳統(tǒng)的始終在服務(wù)器上的組件的大量需求。無服務(wù)器架構(gòu)可以從顯著降低的運營成本氮发、復(fù)雜性和工程交付周期中獲益渴肉，但代價是對供應(yīng)商依賴性的增加和相對不成熟的支持服務(wù)。
By Mike Roberts 2018/05/22

微型前端

開發(fā)一個好前端非常困難爽冕。使許多團隊能夠同時處理大型復(fù)雜的產(chǎn)品更是難上加難仇祭。在這篇文章中，我們將描述一個最近的趨勢颈畸，即將前端整體分解成許多更小乌奇、更易于管理的部分，以及這種架構(gòu)如何提高前端代碼開發(fā)團隊的效率和效率眯娱。除了討論各種好處和成本外华弓，我們還將介紹一些可用的實現(xiàn)選項，并深入討論演示該技術(shù)的完整示例應(yīng)用程序困乒。
BY Cam Jackson 2019/06/19

GUI架構(gòu)

在2000年代中期我正在從事一些寫作項目寂屏，這些項目本可以變成書但還沒有成功。一個是關(guān)于用戶界面的體系結(jié)構(gòu)娜搂。作為這項工作的一部分迁霎，我起草了一份關(guān)于gui架構(gòu)如何發(fā)展的描述，將表單和控件的默認方法和模型-視圖-控制器（model-view-controller百宇，mvc）模式進行了比較考廉。mvc是軟件世界中最難理解的模式之一，可以理解携御，因為它沒有很好的文檔記錄昌粤。因此既绕，我在這里的寫作試圖更好地描述mvc的真正含義，以及它是如何通過model-view-presenter和其他形式演變的涮坐。

Presentation Domain Data Layering

模塊化一個信息豐富的程序最常用的方法之一是將它分為三個廣泛的層：表示（ui）凄贩、域邏輯（aka business logic）和數(shù)據(jù)訪問。因此袱讹，您經(jīng)常會看到web應(yīng)用程序被劃分為了解如何處理http請求和呈現(xiàn)html的web層疲扎、包含驗證和計算的業(yè)務(wù)邏輯層以及排序如何管理數(shù)據(jù)庫或遠程服務(wù)中的持久數(shù)據(jù)的數(shù)據(jù)訪問層。
BY Martin Fowler 2015/08/26

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

當應(yīng)用程序架構(gòu)集中于某種形式的概念應(yīng)用程序邊界內(nèi)的架構(gòu)時捷雕，企業(yè)架構(gòu)看起來是跨大型企業(yè)的架構(gòu)椒丧。這樣一個組織通常規(guī)模太大，無法將其所有軟件分組為任何形式的內(nèi)聚分組救巷，因此需要跨具有許多代碼庫的團隊進行協(xié)調(diào)壶熏，這些代碼庫是在相互隔離的情況下開發(fā)的，資金和用戶是相互獨立的浦译。

企業(yè)架構(gòu)的大部分內(nèi)容都是關(guān)于理解什么值得進行集中協(xié)調(diào)棒假，以及這種協(xié)調(diào)應(yīng)該采取什么形式。一個極端是一個中心架構(gòu)組管怠，它必須批準企業(yè)中每個軟件系統(tǒng)的所有架構(gòu)決策淆衷。這樣的群體會減慢決策速度缸榄，無法真正理解如此廣泛的系統(tǒng)組合中的問題渤弛，從而導(dǎo)致決策失誤。但另一個極端是完全沒有協(xié)調(diào)甚带，導(dǎo)致團隊重復(fù)努力她肯，不同系統(tǒng)無法相互操作，團隊之間缺乏技能開發(fā)和交叉學(xué)習(xí)鹰贵。

像大多數(shù)思維敏捷的人一樣晴氨，我更喜歡在分權(quán)方面犯錯誤，所以我更愿意接近混亂的巖石碉输，而不是令人窒息的控制籽前。但是，站在渠道的那一邊仍然意味著我們必須避免觸礁敷钾，并以一種能夠最大限度地降低實際成本的方式來實現(xiàn)本地決策的最大化枝哄。

企業(yè)架構(gòu)師加入團隊

企業(yè)架構(gòu)組經(jīng)常與日常開發(fā)分離。這可能會導(dǎo)致他們對開發(fā)工作的認識過時阻荒，開發(fā)團隊沒有從公司的廣泛角度來看待問題挠锥。我的同事（thoughtworks cto）rebecca經(jīng)常看到這種情況侨赡，她認為通過加入開發(fā)團隊蓖租，企業(yè)架構(gòu)師可以更加有效粱侣。

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

當一個組織采取敏捷的思維方式時，企業(yè)架構(gòu)并沒有消失蓖宦，但是企業(yè)架構(gòu)師的角色發(fā)生了變化齐婴。企業(yè)架構(gòu)師不再做出選擇，而是幫助其他人做出正確的選擇球昨，然后傳播這些信息尔店。企業(yè)架構(gòu)師仍然需要形成一個愿景，但隨后需要在團隊之間建立橋梁來構(gòu)建學(xué)習(xí)社區(qū)主慰。這將使團隊能夠探索新的方法并相互學(xué)習(xí)嚣州，而企業(yè)架構(gòu)師則是這種增長的合作伙伴。

架構(gòu)師電梯-參觀上層

許多大型組織都看到他們的it引擎被許多層樓與高層管理層隔開共螺，高層管理層也將業(yè)務(wù)和數(shù)字戰(zhàn)略與執(zhí)行it的重要工作分開该肴。架構(gòu)師的主要職責(zé)是在頂樓和機艙之間乘坐電梯，在需要支持這些數(shù)字化工作的地方停車：自動化軟件制造藐不，最小化前期決策匀哄，并在技術(shù)發(fā)展的同時影響組織。

產(chǎn)品多于項目

軟件項目是一種流行的資助和組織軟件開發(fā)的方式雏蛮。他們將工作組織成臨時的涎嚼、只建立團隊的，并通過在業(yè)務(wù)案例中預(yù)測的特定收益來提供資金挑秉。相反法梯，產(chǎn)品模式使用持久的、理想的構(gòu)建-運行團隊來處理持久的業(yè)務(wù)問題犀概。產(chǎn)品模式允許團隊快速調(diào)整方向立哑，減少端到端的周期時間，并允許通過使用短周期迭代驗證實際的好處姻灶，同時保持軟件的體系結(jié)構(gòu)完整性铛绰，以保持其長期有效性。

用REST進行企業(yè)集成

大多數(shù)內(nèi)部REST API是專門為單個集成點構(gòu)建的一次性api产喉。在本文中捂掰，我將討論使用非公開api的限制和靈活性，以及在多個團隊中進行大規(guī)模restful集成的經(jīng)驗教訓(xùn)曾沈。

原文中附帶的其他鏈接資源：

Who Needs an Architect?
Is High Quality Software Worth the Cost?
At OSCON in 2015 I gave a brief talk (14 min) on what architecture is and why it matters.