【注】本文節譯自： software architecture guide (martinfowler.com)
當軟體行業的人們談論「架構」時，他們指的是軟體系統內部設計最重要方面的乙個模糊定義概念。好的架構很重要，否則將來增加新功能會變得越來越慢，而且成本更高。
像軟體世界中的許多人一樣，我一直對「架構」一詞持謹慎態度，因為它通常暗示著與程式設計的分離和不健康的浮誇。但是，我通過強調好的架構可以支援其自身的發展，並與程式設計緊密地交織在一起，來解決我的擔憂。我的職業生涯大部分時間都圍繞著以下問題：好的架構是什麼樣的，團隊如何建立它，以及如何最好地在我們的開發組織中培養架構思維。該頁面概述了我對軟體架構的看法，並在這個**上有關為你帶來更多關於架構的材料。
martinfowler.com 上有關軟體體系結構的材料指南。
馬丁 · 福勒
2023年8月1日
軟體界的人們長期以來一直在爭論架構的定義。對於某些人來說，這就像是系統的基本組織，或者是將最高端別的元件連線在一起的方式。 我對此的想法是由與拉爾夫·詹森（ralph johnson）進行的電子郵件交流形成的，後者對這一措辭提出了質疑，認為沒有客觀的方法來定義基礎知識或高階知識，而對架構的乙個更好的視角是專家開發人員達成共識的系統設計。
qcon拉爾夫·詹森（ralph johnson）在 qcon 上演講
架構的第二種常見定義方式是「需要在專案早期就做出設計決策」，但拉爾夫也對此表示抱怨，說這更像是你希望能夠在專案的早期就做出正確的決策。
他的結論是「架構是關於重要的東西，不管是什麼。」 乍一看，這聽起來很老套，但我發現它帶有很豐富的內涵。 這意味著從結構的角度思考軟體的的核心是確定重要的東西（即什麼是架構），然後花精力保持那些架構元素處於良好狀態。對於要成為架構師的開發人員來說，他們需要能夠識別哪些要素很重要，以及哪些元素在被控制的情況下可能會導致嚴重的問題。
拉爾夫的電子郵件構成了我在ieee軟體專欄的核心，該專欄討論了軟體架構的含義和架構師的角色。
對於軟體產品的客戶和使用者而言，架構是乙個棘手的問題-因為這不是他們能馬上感知的東西。但是，糟糕的架構是促成雜亂無章的主要因素，雜亂無章是軟體的要素，阻礙了開發人員理解軟體的能力。包含大量附加內容的軟體難以修改，導致功能實現的速度更慢，缺陷也很多。
這種情況與我們通常的經驗背道而馳。 我們習慣了「高品質」的東西看作是**更高的東西。對於軟體的某些方面（比如使用者體驗），這可能是正確的。但是當涉及到架構和內部質量的其他方面時，這種關係就反過來了。高的內部質量可以更快地交付新功能，因為減少了麻煩。
雖然我們可以在短期內犧牲質量來換取更快的交貨速度，但在貨物堆積產生影響之前，人們低估了貨物堆積導致整體交貨速度較慢的速度。雖然這不是可以客觀衡量的東西，但是經驗豐富的開發人員認為，關注內部質量只需要幾周而不是幾個月就可獲得回報。
在2023年的oscon上，我作了簡短的演講（14分鐘），內容涉及什麼是架構及其重要性。
軟體開發中的重要決策會隨著我們所考慮的上下文規模而變化。常見的規模是應用程式的規模，因此是「應用程式架構」。
如此寬鬆的定義導致應用的潛在規模很多，開發團隊的人數從幾人到幾百人不等。（您會注意到，我認為規模是涉及的人員數量，我認為這是衡量此類事情的最有用方法。）此架構與企業架構之間的主要區別在於，圍繞社會構建有乙個重要程度的統一目標。
軟體開發中尚未解決的問題之一就是確定軟體的邊界是什麼。（瀏覽器是不是作業系統的一部分？）面向服務體系結構的許多支持者認為應用將不復存在-因此，未來的企業軟體開發將致力於將服務組裝在一起。
我不認為應用的消失和應用界限難以劃分的原則一樣的。本質上，應用是一種社會結構：
馬丁 · 福勒
2003.9.11
微服務架構模式是一種將單個應用程式開發為一組小服務的方法，每個小服務都在自己的程序中執行並與輕量級機制（通常是http資源api）進行通訊。這些服務圍繞業務功能構建，並且可以由完全自動的部署機制獨立部署。這些服務可以用不同的程式語言編寫，使用不同的資料儲存技術，對這些服務可進行最基本的集中管理。儘管它們的優勢使它們在最近幾年非常流行，但它們卻伴隨著分銷增加、一致性降低和需要成熟的經營管理的代價。
馬丁·福勒
邁克·羅伯茨
2018.5.22
好的前端開發很難。擴充套件前端開發，使許多團隊可以同時從事大型複雜產品開發則更加困難。在本文中，我們將描述最近的一種趨勢，即將前端整體拆分成許多更小、更易於管理的部分，以及這種體系結構如何提高處理前端**的團隊效率。除了討論各種收益和成本外，我們還將介紹一些可用的實現選項，並且將深入研究乙個演示該技術的完整示例應用。
卡姆·傑克遜
2019.6.19
在 21 世紀中期，我一直在從事一些寫作專案，這些專案本可以成書，但尚未完成。乙個是關於使用者介面的架構。作為這項工作的一部分，我起草了乙份關於gui架構演變的描述，比較了表單和控制項的預設方法和模型-檢視-控制器（mvc）模式。mvc 是軟體世界中最難理解的模式之一，這是可以理解的，因為它沒有很好的文件記錄。因此，我在這裡的寫作試圖更好地了解mvc的真正含義以及它如何通過模型-檢視-表示器（model-view-presenter）和其他形式發展起來的。
2006.7.18
模組化乙個資訊豐富的程式的一種最常見方法是將其分為三層：展現（ui），域邏輯（即業務邏輯）和資料訪問。因此，你經常會看到web 應用程式被劃分為web 層（了解如何處理 http 請求和呈現 html）、業務邏輯層（包含驗證和計算），資料訪問層（整理如何管理資料庫或遠端服務中的永續性資料） 。
馬丁·福勒
2015.8.26
應用架構集中於某種形式的概念性應用邊界內的體系結構，而企業架構看起來是跨大型企業的體系結構。這樣的組織通常太大了，無法將其所有軟體按任何一種有凝聚的方式進行分組，因此需要跨多個具有相互獨立開發的**庫的團隊進行協調，並需要資金和使用者彼此獨立運作。
企業架構的大部分內容都是關於了解什麼是值得集中協調的成本，以及協調應採取什麼形式。乙個極端是**架構小組，它必須批准企業中每個軟體系統的所有架構決策。這樣的小組減慢了決策的速度，無法真正理解如此廣泛的系統組合中的問題，從而導致決策不力。但是另乙個極端是根本沒有協調，這導致團隊重複工作，不同系統無法進行互操作以及團隊之間缺乏技能開發和交叉學習。
像大多數具有敏捷心態的人一樣，我更喜歡在分散化方面犯錯，因此會更趨於混亂，而不是令人窒息的控制。但是，站在渠道的那一邊仍然意味著我們必須避開險阻，並以要最小化實際成本的方式最大化本地決策。
企業架構組經常遠離日常開發。這可能會導致他們對開發工作的了解過時，抱怨開發團隊沒有從整個公司的角度出發。我的同事（thoughtworks cto）rebecca 經常看到這種情況發生，她認為加入開發團隊可以提高企業架構師的效率。
瑞貝卡·帕森斯（rebecca parsons）
2005.9
當組織採取敏捷的思維方式時，企業架構不會消失，但是企業架構師的角色會發生變化。 企業架構師不再做出選擇，而是幫助其他人做出正確的選擇，然後傳播這些資訊。企業架構師仍然需要形成願景，然後需要在團隊之間建立橋梁，以構建學習社群。這將允許團隊與企業架構師作為合作夥伴，在發展中探索新方法並相互學習。
凱文·希基
2015.11.30
軟體專案是一種流行的資助和組織軟體開發的方式。他們將工作組織成臨時的、只負責構建的團隊，並由業務案例中預計的特定收益提供資金。產品模式使用持久的，由構思-構建-執行的團隊來解決持續存在的業務問題。產品模式使團隊能夠快速重新定位，減少端到端的週期時間，並允許通過使用短週期迭代來驗證實際收益，同時保持軟體體系結構的完整性，以保持其長期有效性。
斯里拉姆·納拉揚（sriram narayan）
2018.2.20
許多大型組織都將其 it 引擎與行政頂層公寓分隔開許多層，這也將業務和數字戰略與執行它的重要工作區分開來。 架構師的主要作用是乘坐頂層公寓和機房之間的電梯，在任何需要的地方停下來支援這些數字工作：自動化軟體製造、最小化前期決策並在技術發展的同時影響組織。
格雷戈爾·霍佩（gregor hohpe）
2017.5.24
大多數內部 est api 是為單個整合點構建的一次性api。在本文中，我將討論非公共 api 所具有的約束和靈活性，以及在多個團隊之間進行大規模 restful 整合的經驗教訓。
布蘭登·拜爾斯（brandon byars）
2013.11.18
14 系統架構師指南 軟體專案角色指南系列文章
系統架構師這個職位的重要性是不言而喻的，在專案設計開發過程中處於高層的作用。系統架構師需要在專案的需求相對穩定之後就進行系統架構設計，以及在專案開發過程中對編碼的開發架構和編碼技術等問題進行解決。系統架構師在實際的專案系統設計過程中就具有其重要性，在專案系統開發過程中可能需要不斷的調整架構上的細節，...
遊戲架構快速指南
基本遊戲類包括表示玩家 盟友 敵人的功能以及使用玩家輸入或ai邏輯控制這些角色的功能。還有一些類用於為玩家建立 抬頭顯示資訊及相機。最後，像gamemode gamestate及playerstate這樣的類用於設定遊戲規則，並且跟蹤遊戲及玩家的進展情況。這些類都會建立某種型別的actor，這些ac...
DevOps 軟體架構師行動指南1 8 小結
1.8 小結 本章的主要知識點是 人們從不同的視角定義devops。例如，運維人員採用敏捷實踐，開發人員承擔運維責任，以及其他一些視角的定義。但共同目標是縮短乙個功能或改進點從業務思路構想到最終部署給使用者的時間。由於文化及技術上的挑戰，devops面臨著障礙。它可能對團隊架構 軟體架構 運維的傳統...