在 2015 年的 OSCON 大會上，我發表了一個簡短演講（14 分鐘），說明什麼是架構以及為什麼它很重要。
軟體架構指南
當軟體產業的人談論「架構」時，他們指的是軟體系統內部設計中最重要的面向，但定義模糊。良好的架構很重要，否則在未來新增功能時，速度會變慢、成本會變高。
就像軟體界許多人一樣，我長期以來一直對「架構」這個詞感到戒慎恐懼，因為它常常暗示與程式設計脫節，且自命不凡。但我透過強調良好的架構是支援自身演進，且與程式設計緊密交織，來解決我的疑慮。我的職涯大部分都在探討良好架構的樣貌、團隊如何建立架構，以及如何在我們的開發組織中培養架構思維。此頁面概述了我對軟體架構的看法，並提供更多關於此網站上架構的資料。
martinfowler.com 上關於軟體架構資料的指南。
什麼是架構？
軟體界的人長期以來一直爭論架構的定義。對某些人來說，它就像系統的基本組織，或最高層級元件的連接方式。我對此的想法受到 與 Ralph Johnson 的電子郵件交流 所形塑，他質疑這種說法，並主張沒有客觀的方法來定義什麼是基本或高層級，而對架構更好的看法是專家開發人員對系統設計的共識。
Ralph Johnson 在 QCon 的演講
建築的第二種常見定義風格是「專案早期需要做出的設計決策」，但 Ralph 也對此抱怨，表示這比較像是希望在專案早期就能做出的正確決策。
他的結論是「建築是關於重要的事物。無論那是什么」。乍看之下，這聽起來很陳腔濫調，但我發現它蘊含著很多豐富的意義。這表示以建築方式思考軟體的核心，是要決定什麼是重要的（即什麼是架構），然後花費精力讓這些架構元素保持良好狀態。開發人員若要成為架構師，他們需要能夠辨識哪些元素很重要，以及哪些元素在不受控的情況下可能會導致嚴重問題。
Ralph 的電子郵件構成了我在 IEEE 軟體雜誌上的專欄的核心，該專欄討論了軟體架構的意義和架構師的角色。
為什麼架構很重要？
架構對於軟體產品的客戶和使用者來說是一個棘手的問題，因為這不是他們可以立即感知到的東西。但是，糟糕的架構是軟體中阻礙開發人員理解軟體能力的元素（稱為累贅）增長的主要原因。包含大量累贅的軟體更難修改，導致功能的推出速度較慢且缺陷較多。
這種情況與我們通常的經驗相反。我們習慣將「高品質」視為成本較高的東西。對於軟體的某些方面，例如使用者體驗，這可能是真的。但是，當涉及到架構和其他內部品質方面時，這種關係就被顛倒了。高內部品質會導致新功能的交付速度加快，因為阻礙較少。
雖然我們確實可以在短期內犧牲品質以加快交付速度，在累贅累積到產生影響之前，人們低估了累贅如何快速導致整體交付速度變慢。雖然這不是可以客觀衡量的東西，但經驗豐富的開發人員認為，重視內部品質可以在幾週內而非幾個月內獲得回報。
應用程式架構
軟體開發中的重要決策會隨著我們思考的脈絡規模而有所不同。一個常見的規模是應用程式的規模，因此稱為「應用程式架構」。
定義應用程式架構的第一個問題是，對於什麼是應用程式沒有明確的定義。我的觀點是應用程式是一種社會建構
- 開發人員視為單一單位的程式碼主體
- 企業客戶視為單一單位的機能群組
- 有錢人視為單一預算的計畫
如此寬鬆的定義導致應用程式的潛在規模眾多，從開發團隊中的幾個人到幾百人不等。（你會注意到我將規模視為參與人數，我覺得這是衡量此類事項最有用的方式。）這與企業架構之間的主要差異在於，社會建構周圍存在著顯著程度的統一目的。
應用程式邊界
軟體開發中未決的問題之一是決定軟體的邊界為何。（瀏覽器是否為作業系統的一部分？）許多服務導向架構的支持者認為應用程式將會消失，因此未來的企業軟體開發將會是組合服務。
我不認為應用程式會消失，原因與應用程式邊界如此難以界定的原因相同。基本上，應用程式是社會建構
微服務指南
微服務架構模式是一種將單一應用程式開發為一組小型服務的方法，每個服務都在自己的程序中執行，並透過輕量級機制（通常是 HTTP 資源 API）進行通訊。這些服務圍繞業務功能而建構，並可透過全自動化部署機制獨立部署。這些服務的集中管理非常少，它們可能使用不同的程式語言編寫，並使用不同的資料儲存技術。儘管其優點讓它們在過去幾年中非常流行，但它們也伴隨著增加分發、減弱一致性以及需要在營運管理中成熟的成本。
無伺服器架構
無伺服器架構是應用程式設計，結合第三方「後端即服務」(BaaS) 服務，和/或包含在「功能即服務」(FaaS) 平台上以受管理的短暫容器執行的自訂程式碼。透過使用這些概念，以及相關概念（例如單頁應用程式），此類架構消除了對傳統常駐伺服器元件的大量需求。無伺服器架構可能大幅降低營運成本、複雜度和工程開發時程，但代價是更依賴供應商相依性和相對不成熟的支援服務。
微前端
良好的前端開發很困難。擴充前端開發，讓許多團隊能同時處理大型且複雜的產品，更是難上加難。在本文中，我們將說明將前端巨石拆解成許多較小、更易於管理的區塊的最新趨勢，以及此架構如何提升處理前端程式碼的團隊效能和效率。除了探討各種好處和成本，我們還會介紹一些可用的實作選項，並深入探討一個展示此技術的完整範例應用程式。
GUI 架構
在 2000 年代中期，我進行了幾個寫作專案，這些專案本可能變成書籍，但尚未實現。其中一個是關於使用者介面的架構。作為這項工作的其中一部分，我起草了一份 GUI 架構演進的說明，比較表單和控制項的預設方法與模型-檢視-控制器 (MVC) 模式。MVC 是軟體世界中理解最差的模式之一，這是可以理解的，因為它沒有經過完善的文件化。因此，我這裡的寫作嘗試提供更清晰的說明，說明 MVC 的真正意義，以及它如何透過模型-檢視-簡報和其他形式演進。
簡報網域資料分層
模組化資訊豐富程式最常見的方法之一，就是將其分為三個廣泛的層級：簡報 (UI)、網域邏輯 (又稱商業邏輯) 和資料存取。因此，你經常會看到網路應用程式分為知道如何處理 HTTP 要求和呈現 HTML 的網路層，包含驗證和計算的商業邏輯層，以及整理出如何在資料庫或遠端服務中管理持續性資料的資料存取層。
分散式系統模式目錄
分散式系統提供了一個特別的程式設計挑戰。它們通常要求我們擁有需要保持同步的多個資料副本。然而，我們無法依賴處理節點可靠地運作，而且網路延遲很容易導致不一致。儘管如此，許多組織依賴於處理資料儲存、訊息傳遞、系統管理和運算能力的核心分散式軟體。這些系統會面臨常見的問題，並使用類似的解決方案來解決這些問題。2020 年，Unmesh Joshi 開始將這些解決方案收集為模式，並在他開發這些解決方案時將它們發佈到此網站上。2023 年，這些解決方案在《分散式系統模式》一書中出版。此頁面連結到每個模式的簡短摘要，並提供 oreilly.com 上線上電子書出版品的相關章節深度連結。
功能切換 (又稱功能旗標)
功能切換（通常也稱為功能旗標）是一種強大的技術，讓團隊可以在不變更程式碼的情況下修改系統行為。它們屬於各種使用類別，在實作和管理切換時，考量此分類非常重要。切換會帶來複雜性。我們可以使用智慧切換實作做法和適當的工具來管理我們的切換設定，以控制此複雜性，但我們也應該限制系統中的切換數量。
使用既定 UI 模式模組化 React 應用程式
儘管既定 UI 模式在解決 UI 設計中的複雜問題方面已被證實有效，但在前端開發領域中卻經常未被充分利用。本文探討將既定 UI 建構模式應用於 React 世界，並透過重構歷程的程式碼範例展示其優點。重點在於分層架構如何協助組織 React 應用程式，以改善回應能力和因應未來的變更。
企業架構
應用程式架構專注於某種形式的假設應用程式界線內的架構，而企業架構則關注大型企業中的架構。此類組織通常過於龐大，無法將所有軟體分組在任何類型的凝聚式群組中，因此需要協調許多獨立開發且彼此獨立運作的資金和使用者的團隊。
企業架構的很大一部分在於了解什麼值得中央協調的成本，以及這種協調應該採取什麼形式。其中一個極端是中央架構小組，它必須批准企業中每個軟體系統的所有架構決策。此類小組會減緩決策制定，而且無法真正了解如此廣泛的系統組合中的問題，導致決策制定不佳。但另一個極端是完全沒有協調，導致團隊重複工作、不同系統無法互操作，以及團隊之間缺乏技能開發和交叉學習。
與大多數具有敏捷思維的人一樣，我比較喜歡在分散化的一方犯錯，因此會更接近混亂的岩石，而不是令人窒息的控制。但處於頻道的那一側仍然意味著我們必須避開岩石，並找到一種方法，以最大程度地進行本地決策制定，同時最大程度地降低所涉及的實際成本。
企業架構師加入團隊
企業架構小組通常與日常開發分開。這可能會導致他們對開發工作的了解過時，而開發團隊沒有採取廣泛的企業觀點。我的同事（Thoughtworks CTO）麗貝卡經常看到這種情況發生，她認為企業架構師可以通過加入開發團隊來提高效率。
建立綜合的業務和技術策略
為了有效利用技術，我們需要將我們的技術思維與基礎業務計畫保持一致。技術策略可以推動這種一致性，前提是它適當地整合業務和技術。我們已經開發了一個概念框架來幫助我們進行這種策略性思考，其基礎是認識到策略性計畫的共同方面，這讓我們找出 11 個普遍的策略方向。對於每個方向，我們概述了它們提出的關鍵業務問題，以及我們需要進行的調查以探討技術影響。我們發現，這個框架不僅可以制定更有效的技術策略，而且還能讓技術為業務思維提供資訊，開發新的收入來源。
產品重於專案
軟體專案是資助和組織軟體開發的流行方式。它們將工作組織成臨時的、僅建置團隊，並使用商業案例中預測的特定好處進行資助。產品模式則使用持久、構思-建置-執行團隊來處理持續的業務問題。產品模式讓團隊能夠快速重新調整方向、縮短端到端週期時間，並允許透過使用短週期迭代來驗證實際好處，同時維護其軟體的架構完整性以保持其長期有效性。
建築師電梯 — 參觀樓上
許多大型組織發現其 IT 引擎與執行長辦公室隔著許多樓層，這也將業務和數位策略與執行這些策略的必要工作分開。建築師的主要角色是在頂層辦公室和引擎室之間搭乘電梯，在任何需要的地方停下來以支援這些數位工作：自動化軟體製造、將前期決策制定減至最少，以及隨著技術演進影響組織。
精實企業中企業架構師的角色
當組織採用敏捷思維時，企業架構並不會消失，但企業架構師的角色會改變。企業架構師不再做出選擇，而是協助其他人做出正確的選擇，然後傳達這些資訊。企業架構師仍需要形成願景，但接著需要在團隊之間建立橋樑，以建立學習社群。這些社群將允許團隊探索新方法並彼此學習，而企業架構師則作為這些成長的合作夥伴。
使用 REST 的企業整合
大多數內部 REST API 都是一次性的 API，專門建置用於單一整合點。在本文中，我將討論非公開 API 的限制和彈性，以及從跨多個團隊進行大規模 RESTful 整合所學到的教訓。