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

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

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

什么是架構(gòu)？

軟件界的人們一直在爭(zhēng)論架構(gòu)的定義。對(duì)某些人來(lái)說(shuō)，這就像是一個(gè)系統(tǒng)的基本組織，或者是最高級(jí)別的組件連接在一起的方式。我的想法是通過(guò)與拉爾夫·約翰遜（Ralph Johnson）的郵件交流形成的，他質(zhì)疑這一措辭，認(rèn)為沒(méi)有客觀的方法來(lái)定義什么是基本的，或者是高層的？好的架構(gòu)是專(zhuān)家對(duì)系統(tǒng)設(shè)計(jì)的共同理解。

拉爾夫·約翰遜

第二種常見(jiàn)的架構(gòu)定義風(fēng)格是，它是“需要在項(xiàng)目早期做出的設(shè)計(jì)決策”，但拉爾夫也對(duì)此表示不滿(mǎn)，他說(shuō)，這更像是你希望能夠在項(xiàng)目早期做出正確的決策。

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

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

對(duì)于軟件產(chǎn)品的客戶(hù)和用戶(hù)來(lái)說(shuō)，架構(gòu)是一個(gè)棘手的話(huà)題，因?yàn)樗皇撬麄兡荞R上察覺(jué)到的東西。但是一個(gè)糟糕的架構(gòu)是導(dǎo)致軟件粗糙元素增長(zhǎng)的主要原因，這些元素阻礙了開(kāi)發(fā)人員理解軟件。包含軟件粗糙元素的系統(tǒng)是很難修改，并導(dǎo)致特性交付速度更慢，缺陷也更多。

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

image

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

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

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

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

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

應(yīng)用程序邊界

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

我不認(rèn)為應(yīng)用程序會(huì)因?yàn)橥瑯拥脑蚨?，為什么?yīng)用程序邊界如此難以劃定?；旧?strong>應(yīng)用是社會(huì)結(jié)構(gòu)：

By Martin Fowler 2003/09/11

微服務(wù)指南

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

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

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

微型前端

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

GUI架構(gòu)

在2000年代中期我正在從事一些寫(xiě)作項(xiàng)目，這些項(xiàng)目本可以變成書(shū)但還沒(méi)有成功。一個(gè)是關(guān)于用戶(hù)界面的體系結(jié)構(gòu)。作為這項(xiàng)工作的一部分，我起草了一份關(guān)于gui架構(gòu)如何發(fā)展的描述，將表單和控件的默認(rèn)方法和模型-視圖-控制器（model-view-controller，mvc）模式進(jìn)行了比較。mvc是軟件世界中最難理解的模式之一，可以理解，因?yàn)樗鼪](méi)有很好的文檔記錄。因此，我在這里的寫(xiě)作試圖更好地描述mvc的真正含義，以及它是如何通過(guò)model-view-presenter和其他形式演變的。

Presentation Domain Data Layering

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

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

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

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

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

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

企業(yè)架構(gòu)組經(jīng)常與日常開(kāi)發(fā)分離。這可能會(huì)導(dǎo)致他們對(duì)開(kāi)發(fā)工作的認(rèn)識(shí)過(guò)時(shí)，開(kāi)發(fā)團(tuán)隊(duì)沒(méi)有從公司的廣泛角度來(lái)看待問(wèn)題。我的同事（thoughtworks cto）rebecca經(jīng)常看到這種情況，她認(rèn)為通過(guò)加入開(kāi)發(fā)團(tuán)隊(duì)，企業(yè)架構(gòu)師可以更加有效。

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

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

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

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

產(chǎn)品多于項(xiàng)目

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

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

大多數(shù)內(nèi)部REST API是專(zhuān)門(mén)為單個(gè)集成點(diǎn)構(gòu)建的一次性api。在本文中，我將討論使用非公開(kāi)api的限制和靈活性，以及在多個(gè)團(tuán)隊(duì)中進(jìn)行大規(guī)模restful集成的經(jīng)驗(yàn)教訓(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.