軟件架構指南

【注】本文節譯自： Software Architecture Guide (martinfowler.com)
  當軟件行業的人們談論「架構」時，他們指的是軟件系統內部設計最重要方面的一個模糊定義概念。好的架構很重要，不然未來增長新功能會變得愈來愈慢，並且成本更高。

  像軟件世界中的許多人同樣，我一直對「架構」一詞持謹慎態度，由於它一般暗示着與編程的分離和不健康的浮誇。可是，我經過強調好的架構能夠支持其自身的發展，並與編程緊密地交織在一塊兒，來解決個人擔心。個人職業生涯大部分時間都圍繞着如下問題：好的架構是什麼樣的，團隊如何建立它，以及如何最好地在咱們的開發組織中培養架構思惟。該頁面概述了我對軟件架構的見解，並在這個網站上有關爲你帶來更多關於架構的材料。martinfowler.com 上有關軟件體系結構的材料指南。
馬丁·福勒
2019年8月1日

什麼是架構?

  軟件界的人們長期以來一直在爭論架構的定義。對於某些人來講，這就像是系統的基本組織，或者是將最高級別的組件鏈接在一塊兒的方式。 我對此的想法是由與拉爾夫·約翰遜（Ralph Johnson）進行的電子郵件交流造成的，後者對這一措辭提出了質疑，認爲沒有客觀的方法來定義基礎知識或高級知識，而對架構的一個更好的視角是專家開發人員達成共識的系統設計。

  架構的第二種常見定義方式是「須要在項目早期就作出設計決策」，但拉爾夫也對此表示抱怨，說這更像是你但願可以在項目的早期就作出正確的決策。
  他的結論是「架構是關於重要的東西，無論是什麼。」 乍一看，這聽起來很老套，但我發現它帶有很豐富的內涵。 這意味着從結構的角度思考軟件的的核心是肯定重要的東西（即什麼是架構），而後花精力保持那些架構元素處於良好狀態。對於要成爲架構師的開發人員來講，他們須要可以識別哪些要素很重要，以及哪些元素在被控制的狀況下可能會致使嚴重的問題。

爲何架構很重要？

  對於軟件產品的客戶和用戶而言，架構是一個棘手的問題-由於這不是他們能立刻感知的東西。可是，糟糕的架構是促成雜亂無章的主要因素，雜亂無章是軟件的要素，阻礙了開發人員理解軟件的能力。包含大量附加內容的軟件難以修改，致使功能實現的速度更慢，缺陷也不少。

  這種狀況與咱們一般的經驗背道而馳。 咱們習慣了「高品質」的東西看做是價格更高的東西。對於軟件的某些方面（好比用戶體驗），這多是正確的。可是當涉及到架構和內部質量的其餘方面時，這種關係就反過來了。高的內部質量能夠更快地交付新功能，由於減小了麻煩。
  雖然咱們能夠在短時間內犧牲質量來換取更快的交貨速度，但在貨物堆積產生影響以前，人們低估了貨物堆積致使總體交貨速度較慢的速度。雖然這不是能夠客觀衡量的東西，可是經驗豐富的開發人員認爲，關注內部質量只須要幾周而不是幾個月就可得到回報。

應用架構

  軟件開發中的重要決策會隨着咱們所考慮的上下文規模而變化。常見的規模是應用程序的規模，所以是「應用程序架構」。
  定義應用架構的第一個問題是對應用是什麼沒有明確的定義。我認爲應用是一種社會結構：

• 被開發人員視爲一個單元的代碼體
• 業務客戶將其視爲一個單元的一組功能
• 那些有錢的人將其視爲單一預算

  如此寬鬆的定義致使應用的潛在規模不少，開發團隊的人數從幾人到幾百人不等。（您會注意到，我認爲規模是涉及的人員數量，我認爲這是衡量此類事情的最有用方法。）此架構與企業架構之間的主要區別在於，圍繞社會構建有一個重要程度的統一目標。

應用邊界

  軟件開發中還沒有解決的問題之一就是肯定軟件的邊界是什麼。（瀏覽器是否是操做系統的一部分？）面向服務體系結構的許多支持者認爲應用將不復存在-所以，將來的企業軟件開發將致力於將服務組裝在一塊兒。
  我不認爲應用的消失和應用界限難以劃分的原則同樣的。本質上，應用是一種社會結構：
馬丁 · 福勒
2003.9.11

微服務指南

微服務架構模式是一種將單個應用程序開發爲一組小服務的方法，每一個小服務都在本身的進程中運行並與輕量級機制（一般是HTTP資源API）進行通訊。這些服務圍繞業務功能構建，而且能夠由徹底自動的部署機制獨立部署。這些服務能夠用不一樣的編程語言編寫，使用不一樣的數據存儲技術，對這些服務可進行最基本的集中管理。儘管它們的優點使它們在最近幾年很是流行，但它們卻伴隨着分銷增長、一致性下降和須要成熟的經營管理的代價。
馬丁·福勒

Serverless 架構

無服務器架構是結合第三方「後端即服務」（BaaS）服務和/或包含在「功能即服務」（FaaS）平臺上的託管臨時容器中運行的自定義代碼的應用設計。經過使用這些思想以及諸如單頁應用程序之類的相關思想，這樣的架構消除了對傳統的永遠在線服務器組件的大量需求。無服務器架構可能會受益於顯着下降的運營成本、複雜性和工程交貨時間，但代價是增長對於供應商的依賴性和相對不成熟的支持服務的依賴。
邁克·羅伯茨
2018.5.22

微前端

好的前端開發很難。擴展前端開發，使許多團隊能夠同時從事大型複雜產品開發則更加困難。在本文中，咱們將描述最近的一種趨勢，即將前端總體拆分紅許多更小、更易於管理的部分，以及這種體系結構如何提升處理前端代碼的團隊效率。除了討論各類收益和成本外，咱們還將介紹一些可用的實現選項，而且將深刻研究一個演示該技術的完整示例應用。
卡姆·傑克遜
2019.6.19

GUI 架構

在 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

使用 REST 進行企業集成

大多數內部 EST API 是爲單個集成點構建的一次性API。在本文中，我將討論非公共 API 所具備的約束和靈活性，以及在多個團隊之間進行大規模 RESTful 集成的經驗教訓。 布蘭登·拜爾斯（Brandon Byars） 2013.11.18