軟件架構指南

寫在前面

軟件行業裡，人們談起「架構」時，指的是對軟件系統內部設計最重要的方面進行模糊定義的概念。良好的架構很重要，否則將來新增功能會變得越來越慢，成本也會變高。

但「架構」一詞應謹慎對待，因為通常意味著與編程的分離，甚至浮華誇大。而我們真正關注的是能夠支持其自身的演變，並且與編程密不可分的好的架構，那麼：

好的架構是什麼樣的？
團隊怎樣才能創造出好的架構？
如何在我們的開發組織中培養架構思維？

一.什麼是架構？

架構的定義，是軟件行業一直以來爭論不休的一個話題。有人認為架構是系統的基本組織方式，也有人認為是把最高層組件連接在一起的方式。可是，「基礎」、「高層次」的客觀定義又是什麼呢？所以，更好的看法是專家開發人員對系統設計所形成的共識。

P.S.還有一種常見的定義，認為架構是需要在項目早期做出的設計決策，同樣不夠準確，因為更像是希望能夠在項目中盡早做出的決定。

Ralph Johnson 認為，架構是那些重要的東西，無論它具體是什麼：

Architecture is about the important stuff. Whatever that is.

聽起來比較老套，但有些道理，因為從架構角度考慮的核心就是要確定什麼才是重要的東西（即，什麼是架構），然後投入精心讓這些架構元素保持良好狀態。對於要成為架構師的開發者來說，要能識別出那些重要的元素，以及那些如果不加以控制就會造成嚴重後果的元素。

P.S.關於架構定義的更多信息，見 Who Needs an Architect?

二.為什麼架構如此重要？

對於軟件產品的客戶和用戶而言，架構是個棘手的問題，因為這不是他們所能立即感知到的。但糟糕的架構卻是促成雜亂無章（cruft）的主要因素，這些東西會妨礙開發者理解軟件。包含大量雜亂的東西的軟件難以修改，從而導致特性迭代速度變慢、缺陷變多：

更嚴重的是，由於這些雜亂的東西遍布整個代碼庫，會拖慢每一次功能迭代。

習慣經驗告訴我們，通常高質量的東西成本也更高，對於軟件的某些方面（比如用戶體驗），確實是這樣，但在涉及架構和內部質量的其它方面時，這種關係恰恰相反：高內部質量能加快新功能的交付速度，因為來自雜亂的東西的阻礙減少了。

誠然，短期內我們可以為了更快的交付而犧牲質量，但在雜亂的東西堆積尚未產生影響之前，人們低估了它拖慢整體交付的迅速程度。雖然無法客觀衡量，但有經驗的開發者知道，對內部質量的關注在幾周內就能得到回報（而不是幾個月）。

高內部質量的軟件前期交付慢，但後期交付速度要快得多。

P.S.關於軟件內部質量與成本的更多信息，見 Is High Quality Software Worth the Cost?

三.應用程序架構

軟件開發中的重要決策因我們所考慮的上下文範圍而異，常見的範圍是應用程序，即應用程序架構。

定義軟件架構的第一個問題是沒有明確定義什麼是應用程序，本質上，應用程序可以理解為一種社會結構：

在開發人員看來（應用程序）是一堆代碼
在業務客戶看來是一組功能
在投資人看來是一個預算計劃

這種寬鬆的定義導致存在規模大大小小的應用，開發團隊從幾個人到幾百個人不等（把規模看做所涉及的人數是最有用的衡量方式），與企業架構的主要區別在於，圍繞社會結構存在著很大程度的統一目標。

應用程序的邊界

軟件開發中尚未解決的問題之一是如何確定軟件的邊界是什麼，例如，瀏覽器是不是操作系統的一部分？

本質上，應用程序是社會結構，我們能以幾百種不同的方式描繪軟件邊界（開發人員、業務客戶、投資人等視角），在許多方面，這些界限是由人際關係和政治所劃定的，而不是基於技術及功能上的考慮。

P.S.更多詳細信息，見 ApplicationBoundary

微服務模式

微服務架構模式是一種把單個應用程序分解成一套小型服務來開發的方法，每個小服務運行在自己的進程，並通過輕量級的機制通信（通常是 HTTP 面向資源的 API）。這些服務圍繞業務功能建立，由完全自動化的部署機制獨立部署，可以用不同語言來編寫，也可以使用不同的數據存儲技術，而只需要極少的集中管理。

這些優勢讓微服務模式在過去幾年變得非常流行，但分佈式成本增加，一致性減弱，以及操作管理上的成熟度要求等代價也隨之而來。

P.S.更多詳細信息，見微服務架構（Microservices）

Serverless 架構

Serverless 架構是一種包含第三方 BaaS（Backend as a Service）服務，以及運行在 FaaS（Functions as a Service）平台上託管的臨時容器中的自定義代碼的應用程序設計。通過運用這些思想和單頁面應用等相關思想，這種架構消除了對傳統始終運行的服務端組件的大部分需求。

Serverless 架構有助於大幅降低運營成本、複雜度和工程交付周期，但代價是增加了對供應商的依賴以及相對不成熟的支持服務。

微前端模式

前端開發要做好很難，而擴展前端開發，讓多個團隊能夠同時處理大而複雜的產品更難。

微前端模式是近年來出現的一種把前端整體拆分成許多易於管理的小塊，以提升前端團隊效率的流行趨勢。

P.S.更多詳細信息，見 Micro Frontends

GUI 架構

從最初的表單加控件，到後來的 MVC、MVP 等模式，UI 架構也在不斷演進。

P.S.更多詳細信息，見 GUI Architectures

表現 - 領域邏輯 - 數據分層

對於信息豐富的程序，最常見一種模塊化方法是把它分成 3 層：

表現層（UI）
領域邏輯層（或者叫業務邏輯層）
數據訪問層

所以經常看到 Web 應用分成負責處理 HTTP 請求和渲染 HTML 的 Web 層、包含校驗與計算的業務邏輯層，以及用數據庫或遠程服務管理持久化數據的數據訪問層：

分層最大的好處在於縮窄關注範圍，讓我們能單獨考慮這 3 部分。由於確立了模塊邊界，讓換用不同的實現的影響範圍變得相對較小，也更容易獨立測試。

P.S.更多詳細信息，見 Presentation Domain Data Layering

四.企業架構

應用程序架構專注於某種形式的概念性應用程序邊界內的架構，而企業架構則是著眼於整個大型企業的架構。企業組織通常太龐大，而無法將其所有軟件按內聚的方式進行劃分，因此需要對各自擁有許多代碼庫的團隊進行協調，這些團隊彼此之間獨立開發，資金和用戶也獨立運作。

企業架構的許多內容都是關於什麼樣的中心化協調才是值當的，以及協調應採取的形式。一種極端情況是中心化架構劃分，必須批准企業下每個軟件系統的所有架構決策，這種劃分拖慢了決策速度，而且無法真正理解廣泛的系統組合中的各種問題，從而導致決策不力。另一種極端是完全沒有協調，導致團隊重複工作，不同系統之間無法進行互操作，團隊間也缺乏技能培養和交叉學習。

對此，與其進行束縛性的控制，不如權力下放，同時盡可能地加強局部決策，最大限度地減少所涉及的實際成本。

讓企業架構師加入開發團隊

企業架構組通常與日常開發分開，這會導致他們對開發工作的認知過時，而且開發團隊也沒有從全公司的廣泛視角來看。因此，企業架構師或許可以通過加入開發團隊來提高效率。

P.S.更多詳細信息，見 Enterprise Architects Join the Team

精益企業中的企業架構師角色變化

企業採用敏捷思維時，企業架構不會消失，但企業架構師的角色會發生變化：

企業架構師不再做出選擇，而是幫助他人做正確的決策，然後傳播這些信息
企業架構師仍然需要形成願景，但隨後要在團隊之間架起橋樑，建立學習社區
企業架構師要與團隊建立合作夥伴關係，在成長中探索新方法並相互學習

P.S.更多詳細信息，見 The Role of an Enterprise Architect in a Lean Enterprise

產品模式勝過項目模式

項目模式，是按軟件項目進行資金投入和組織軟件開發的一種流行方式，把工作組織成臨時的，只負責實現的團隊，並由業務場景中預計的特定收益提供資金。

而產品模式改用持久的，負責構思、實現及運行的團隊，以解決持續存在的業務問題。產品模式讓團隊能夠快速調整方向，減少端到端的周期時間，並通過短周期迭代來驗證實際收益，同時維持軟件架構的完整性來保證其長期有效。

P.S.更多詳細信息，見 Products Over Projects

架構師的職責

許多大型組織的 IT 部門與擁有決策權的高層之間都分隔著許多層樓，這也把業務和數字化戰略與實施戰略的重要工作分開了。

所以，架構師的主要職責是乘坐頂層到機房的電梯，在任何需要支持其數字化工作的地方停下來：自動化軟件生產，盡可能減少前期決策，並在技術演進的同時影響組織。

P.S.更多詳細信息，見 The Architect Elevator — Visiting the upper floors

參考資料

Software Architecture Guide