【注】本文節(jié)譯自： Software Architecture Guide (martinfowler.com)

? ? 當(dāng)軟件行業(yè)的人們談?wù)摗凹軜?gòu)”時，他們指的是軟件系統(tǒng)內(nèi)部設(shè)計最重要方面的一個模糊定義概念。好的架構(gòu)很重要，否則將來增加新功能會變得越來越慢，而且成本更高。

? ??像軟件世界中的許多人一樣，我一直對“架構(gòu)”一詞持謹(jǐn)慎態(tài)度，因為它通常暗示著與編程的分離和不健康的浮夸。但是，我通過強調(diào)好的架構(gòu)可以支持其自身的發(fā)展，并與編程緊密地交織在一起，來解決我的擔(dān)憂。我的職業(yè)生涯大部分時間都圍繞著以下問題：好的架構(gòu)是什么樣的，團隊如何創(chuàng)建它，以及如何最好地在我們的開發(fā)組織中培養(yǎng)架構(gòu)思維。該頁面概述了我對軟件架構(gòu)的看法，并在這個網(wǎng)站上有關(guān)為你帶來更多關(guān)于架構(gòu)的材料。

馬丁 · 福勒

2019年8月1日

什么是架構(gòu)?

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

??架構(gòu)的第二種常見定義方式是“需要在項目早期就做出設(shè)計決策”，但拉爾夫也對此表示抱怨，說這更像是你希望能夠在項目的早期就做出正確的決策。

??他的結(jié)論是“架構(gòu)是關(guān)于重要的東西，不管是什么。” 乍一看，這聽起來很老套，但我發(fā)現(xiàn)它帶有很豐富的內(nèi)涵。 這意味著從結(jié)構(gòu)的角度思考軟件的的核心是確定重要的東西（即什么是架構(gòu)），然后花精力保持那些架構(gòu)元素處于良好狀態(tài)。對于要成為架構(gòu)師的開發(fā)人員來說，他們需要能夠識別哪些要素很重要，以及哪些元素在被控制的情況下可能會導(dǎo)致嚴(yán)重的問題。

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

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

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

這種情況與我們通常的經(jīng)驗背道而馳。 我們習(xí)慣了“高品質(zhì)”的東西看作是價格更高的東西。對于軟件的某些方面（比如用戶體驗），這可能是正確的。但是當(dāng)涉及到架構(gòu)和內(nèi)部質(zhì)量的其他方面時，這種關(guān)系就反過來了。高的內(nèi)部質(zhì)量可以更快地交付新功能，因為減少了麻煩。

? 雖然我們可以在短期內(nèi)犧牲質(zhì)量來換取更快的交貨速度，但在貨物堆積產(chǎn)生影響之前，人們低估了貨物堆積導(dǎo)致整體交貨速度較慢的速度。雖然這不是可以客觀衡量的東西，但是經(jīng)驗豐富的開發(fā)人員認(rèn)為，關(guān)注內(nèi)部質(zhì)量只需要幾周而不是幾個月就可獲得回報。

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

? ? 軟件開發(fā)中的重要決策會隨著我們所考慮的上下文規(guī)模而變化。常見的規(guī)模是應(yīng)用程序的規(guī)模，因此是“應(yīng)用程序架構(gòu)”。

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

• 被開發(fā)人員視為一個單元的代碼體

• 業(yè)務(wù)客戶將其視為一個單元的一組功能

• 那些有錢的人將其視為單一預(yù)算

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

馬丁?· 福勒

2003.9.11

微服務(wù)指南

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

馬丁·福勒

Serverless 架構(gòu)

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

邁克·羅伯茨

2018.5.22

微前端

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

卡姆·杰克遜

2019.6.19

GUI 架構(gòu)

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

2006.7.18

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

? ? 模塊化一個信息豐富的程序的一種最常見方法是將其分為三層：展現(xiàn)（UI），域邏輯（即業(yè)務(wù)邏輯）和數(shù)據(jù)訪問。因此，你經(jīng)常會看到Web 應(yīng)用程序被劃分為Web 層（了解如何處理 HTTP 請求和呈現(xiàn) HTML）、業(yè)務(wù)邏輯層（包含驗證和計算），數(shù)據(jù)訪問層（整理如何管理數(shù)據(jù)庫或遠程服務(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)。這樣的組織通常太大了，無法將其所有軟件按任何一種有凝聚的方式進行分組，因此需要跨多個具有相互獨立開發(fā)的代碼庫的團隊進行協(xié)調(diào)，并需要資金和用戶彼此獨立運作。

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

??像大多數(shù)具有敏捷心態(tài)的人一樣，我更喜歡在分散化方面犯錯，因此會更趨于混亂，而不是令人窒息的控制。但是，站在渠道的那一邊仍然意味著我們必須避開險阻，并以要最小化實際成本的方式最大化本地決策。

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

企業(yè)架構(gòu)組經(jīng)常遠離日常開發(fā)。這可能會導(dǎo)致他們對開發(fā)工作的了解過時，抱怨開發(fā)團隊沒有從整個公司的角度出發(fā)。我的同事（ThoughtWorks CTO）Rebecca 經(jīng)常看到這種情況發(fā)生，她認(rèn)為加入開發(fā)團隊可以提高企業(yè)架構(gòu)師的效率。

瑞貝卡·帕森斯（Rebecca Parsons）

2005.9

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

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

凱文·希基

2015.11.30

產(chǎn)品超越項目

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

斯里拉姆·納拉揚（Sriram Narayan）

2018.2.20

建筑師電梯-參觀高層

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

格雷戈爾·霍佩（Gregor Hohpe）

2017.5.24

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

? ? 大多數(shù)內(nèi)部 EST API 是為單個集成點構(gòu)建的一次性API。在本文中，我將討論非公共 API 所具有的約束和靈活性，以及在多個團隊之間進行大規(guī)模 RESTful 集成的經(jīng)驗教訓(xùn)。

布蘭登·拜爾斯（Brandon Byars）

2013.11.18