峭據辭￥

目錄

第1章什么是架構

作為名詞

作為動詞

第2章架構的種類

它們的共同點是什么

第3章軟件架構是什么

應用程序架構

系統架構

軟件架構

企業架構：戰略而非代碼

第4章敏捷軟件架構是什么

理解“敏捷”

好的架構帶來敏捷

你需要有多敏捷

第5章架構對上設計

找出區別

理解意義

第6章軟件架構重要嗎

缺乏軟件架構將引發問題

軟件架構的好處

所有軟件項目都需要軟件架構嗎

第7章問題

PartII軟件架構的角色

第8章軟件架構的角色

1.架構驅動力

2.設計軟件

3.技術風險

4.架構演化

5.編寫代碼

6.質量保證

合作或失敗

技術領導是一個角色而非級別

提出你自己對這個角色的定義

第9章軟件架構師應該編碼嗎

編寫代碼

構建原型、框架和基礎

進行代碼評審

實驗并與時俱進

軟件架構師和雇主之間的矛盾

你不必放棄編碼

不要把全部時間都用于編碼

第10章軟件架構師應該是建造大師

聯盟的狀態

回顧過去

建造大師真的會建造嗎

象牙塔

建造大師角色的差異

實現角色

架構師要和團隊一起工作

第11章從開發者到架構師

經驗是一個好的評價標準，但你需要看得更深

模糊的界線

跨越界線是我們的責任

第12章拓展T

進一步的技術能力

知識面寬

軟件架構師是通才型專家

軟件架構是技術活

第13章軟技能

保持積極

第14章軟件架構不是接力運動

解決方案架構師

要有人負責大局

第15章軟件架構要引入控制嗎

提供指導，追求一致性

控制的程度

控制因文化而不同

操縱桿，而非按鈕

第16章小心鴻溝

開發者關注底層細節

閉門造車的獨裁架構師

拉近距離

如果你是軟件架構師

如果你是軟件開發者

軟件架構的合作方式

第17章未來的軟件架構師在哪里

指導、輔導和師徒關系

我們正在失去技術導師

軟件團隊需要休息

第18章每個人都是架構師，除非他們有其他身份

每個人都是架構師

除非他們有其他身份

敏捷需要架構嗎

第19章軟件架構咨詢師

領域知識

權威

第20章問題

PartIII設計軟件

第21章架構驅動力

功能需求

質量屬性

約束

原則

理解影響

第22章質量屬性（非功能需求）

哪些對你重要

第23章處理非功能需求

捕捉

提煉

挑戰

第24章約束

時間和預算的約束

技術約束

人員約束

組織約束

約束都是不好的嗎

約束可以劃分優先級

傾聽約束

第25章原則

開發原則

架構原則

謹防最佳實踐

第26章技術不是實現細節

你有復雜的非功能需求嗎

你有約束嗎

你有一致性嗎

推遲與解耦

每個決策都是權衡

第27章更多分層等于更高復雜度

非功能需求

時間和預算：沒有什么是免費的

第28章協同設計是一把雙刃劍

經驗影響軟件設計

第29章軟件架構是對話的平臺

軟件開發不只是交付特性

第30章SharePoint項目也需要軟件架構

很多SharePoint實現都不只是SharePoint

非功能性需求仍然適用于SharePoint解決方案

SharePoint項目很復雜，也需要技術領導力

SharePoint解決方案仍然需要編寫文檔

強大的領導力和紀律不只是針對軟件開發項目

第31章問題

PartIV可視化軟件

第32章溝通障礙

拋棄UML

敏捷需要良好的溝通

第33章對草圖的需要

測試驅動開發與圖表

為什么人們應該學習如何畫草圖

畫草圖不是藝術

畫草圖不是綜合模型

畫草圖可以是協作活動

第34章無效的草圖

采購清單

只有框沒有線

“功能視圖”

航線圖

一般正確

推遲技術

部署和執行上下文

太多假設

無家可歸的C#對象（HOCO）

選擇你自己的冒險

應該用白板

創建有效的草圖

第35章C4：語境、容器、組件和類

通用的抽象集合

總結軟件的靜態視圖

通用標記法的通用抽象

圖應該簡單且腳踏實地

第36章語境圖

意圖

結構

用戶、演員、角色、人物等

IT系統

交互

動機

受眾

示例

第37章容器圖

意圖

結構

容器

交互

系統邊界

動機

受眾

示例

第38章組件圖

意圖

結構

組件

交互

動機

受眾

示例

第39章是否包含技術選擇

在設計過程中繪圖

回顧性繪圖

架構圖應該概念化

明確技術選擇

第40章你會那樣編碼嗎

共享組件

分層策略

圖應該反映現實

第41章軟件架構和編碼

職責驅動設計和組件分解

我們談論組件但編寫類

用層封裝代碼

用特性封裝

用組件封裝

對齊軟件架構和代碼

第42章你不需要UML工具

有很多類型的UML工具

既有效又簡單

UML的用途

沒有銀彈

第43章有效的草圖

標題

標簽

形狀

職責

線條

顏色

邊框

布局

方向

要點

圖表的評審清單

傾聽問題

第44章C4的常見問題

語境圖上的系統名稱

混合的抽象層次

共享組件

工具組件

從IT的角度勾畫企業語境

第45章問題

PartV為軟件生成文檔

第46章代碼不會講述完整的故事

代碼未描繪的設計意圖

輔助信息

第47章軟件文檔即指南

1.地圖

2.景色

3.歷史和文化

4.實用信息

保持短小簡潔

注意“視圖”

產品與項目文檔

第48章語境

意圖

結構

動機

受眾

是否必須

第49章功能性概覽

意圖

結構

動機

受眾

是否必須

第50章質量屬性

意圖

結構

動機

受眾

是否必須

第51章約束

意圖

結構

動機

受眾

是否必須

第52章原則

意圖

結構

動機

受眾

是否必須

第53章軟件架構

意圖

結構

動機

受眾

是否必須

第54章外部接口

意圖

結構

動機

受眾

是否必須

第55章代碼

意圖

結構

動機

受眾

是否必須

第56章數據

意圖

結構

56.3動機

受眾

是否必須

第57章基礎設施架構

意圖

結構

動機

受眾

是否必須

第58章部署

意圖

結構

動機

受眾

是否必須

第59章運營和支持

意圖

結構

動機

受眾

是否必須

第60章決策口志

意圖

結構

動機

受眾

是否必須

第61章問題

PartVI開發生命周期中的軟件架構

第62章敏捷和架構的沖突：神話還是現實

沖突1：團隊結構

沖突2：流程和產出

軟件架構提供了TDD、BDD、DDD、RDD和代碼整潔的分界線

從象牙塔和大型預先設計中分離出架構

第63章量化風險

概率與影響

設定風險的優先級

第64章風險風暴

步驟1:畫一些架構圖

步驟2：分別識別風險

步驟3：匯總圖中的風險

步驟4：對風險設定優先級

緩解策略

何時使用風險風暴

集體所有制

第65章恰如其分的預先設計

回到方法學

要做到“恰如其分”

多少預先設計是太少

多少預先設計是太多

多少是“恰如其分”

把恰如其分的預先設計置于適當的語境

第66章初識軟件架構

軟件架構應該容易理解

一些實用的建議

1.宣傳教育

2.回顧架構

3.完成標準

4.分配軟件架構角色

5.架構培訓班

推動變革發生

軟件架構的本質

第67章問題

PartVP金融風險系統

第68章金融風險系統

背景

交易數據系統

參考數據系統

功能需求

非功能需求

性能

可伸縮性

可用性

故障轉移

安全性

審計

容錯和恢復

國際化和木地化

監測和管理

數據保存和歸檔

互操作性

PartVIII附錄：“技術部落”的軟件指南

介紹

語境

用戶

外部系統

功能性概覽

人和部落

內容

用戶

博弈引擎

質量屬性

性能

可伸縮性

安全性

可用性

國際化

本地化

瀏覽器兼容性

約束

預算

原則

組件封裝

自動化測試

酉己置

Spring自動裝酉己

軟件架構

容器

組件：內容更新器

組件：核心

基礎設施架構

線上環境

部署

軟件

構建“技術部落”

部署“技術部落”

配置

運營和支持

啟動MySQL

啟動MongoDB

啟動Web服務器

啟動內容更新器

監測

備份

PartI什么是軟件架構

通過學習這部分，我們將了解軟件架構是什么，架構和設計的區別，敏捷的架構意味著什

么，以及為什么思考軟件架構很重要。

第1章什么是架構

在不同的人眼里“架構”一詞的意思大相徑庭，互聯網上對架構的定義也多如牛毛。過去幾

年里我問過上百人同一個問題，在他們看來“架構"意味著什么。得到的答案概括如下（排

名不分先后）：

?模塊、連接、依賴和接口；

?大局觀；

?改變成本很高的事情；

?難以改變的事情；

?更加兼顧全局的設計；

?接口而非實現；

?審美（比如：藝術般的整潔代碼）：

?概念模型；

?滿足非功能需求/質量屬性；

?每件事都有“架構"；

?溝通能力（抽象、語言、詞匯）；

?計戈也

?一定程度的嚴格和可靠性；

?藍圖;

?系統、子系統、交互和接口;

?管理；

?戰略決策的產出；

?必要的約束；

?結構（組件和交互）；

?技術方向；

?戰略和愿景；

?結構單元；

?實現目標的過程；

?標準和準則；

?整個系統；

?工具和方法；

?從需求到最終產品的道路；

?指導原則；

?技術領導力；

?構成產品的元素之間的關系;

?對環境約束和限制的意識；

?基礎；

?抽象的觀點；

?把問題化整為零的過程；

?產品的骨架、支柱。

難怪找不到一個合適的定義！好在還可以分為名詞和動詞兩大類。無論我們談論的是建造

一個物理建筑或一個軟件系統，都適用。

作為名詞

架構作為名詞來解釋時，概括起來都與結構有關：將產品分解為一系列組件、模塊和交互。

這需要考慮整個產品，包括處理（建筑物的）供電、供水、空調，或處理（軟件的）安全、

配置、錯誤處理等橫切關注點的基礎設施服務。

作為動詞

架構作為動詞來解釋時，包括了理解你需要構建什么、設定愿景以便于進行構建和做出恰

當的設計決策。所有這些都要以需求為基礎，因為需求驅動架構。關鍵在于，架構是關

于交流愿景以及引入技術領導力的，這樣參與構建產品的每個人都能理解這個愿景，并為

產品的成功做出積極貢獻。

第2章架構的種類

單是IT行業就有很多不同種類的架構和架構師。下面列出了人們在被問及該問題時給出

的最普遍回答（排名不分先后）：

?基礎設施；

?安全；

?技術；

?解決方案；

?網絡；

?數據；

?硬件；

?企業；

?應用程序；

?系統;

?集成;

?IT；

?數據庫；

?信息；

?流程；

?商務；

?軟件。

有些遺憾的是，這個列表中的有些詞，特別是其定義相互依賴的，比其他詞容易定義。比

如，"解決方案架構”到底是什么意思？對一些組織來說，"解決方案架構師"就是"軟件架構

師”，而有些組織則有一個特定的專注于整體“方案”設計（但不包括實施細節的討論）的

角色。類似地，"技術架構”通常指軟件、硬件，或者兩者兼有。

有趣的是，當我請人們列出他們知道的IT架構種類時，"軟件架構”往往是最后被提及的。

這或許反映了這個詞帶給人們的困惑。

它們的共同點是什么

那么，所有這些詞有什么共同點呢？除了都以“架構"或“架構師"結尾之外，所有架構類型

都具有結構和愿景。

以“基礎設施架構”為例，想象你要在兩個辦公室之間建立網絡連接，而這兩個辦公室遠隔

千里。一種做法是找一卷最長的網線，然后從一個辦公室直接連接到另一個辦公室。假設

你有足夠的線纜，這可能行得通，但現實中為了達到這個目標，你要考慮很多環境約束和

非功能特性。這就是架構的過程以及設定實現目標愿景的重要之處。

采用一條很長的線纜是一種方法，但由于現實世界的約束，這個方法并不可行。因為這個

原因，網絡往往要復雜得多，需要一組協同工作的組件來滿足目標。那么從基礎設施的角

度出發，我們談論結構時你期望看到的是這一領域內的通用組件，比如路由器、防火墻、

包整形器、交換機等。

不管你是構建軟件系統、網絡還是數據庫，任何成功的方案都需要你理解問題，并設定一

個愿景可以和每個參與構建最終產品的人溝通。不論何種領域的架構，其實主要就是結

構和愿景.

第3章軟件架構是什么

乍一看，"軟件架構”似乎很容易定義。它就是講軟件的架構，對吧？沒錯，但它并不局限

于軟件。

應用程序架構

對于我們軟件開發者來說，最熟悉的應該是應用程序架構，特別是通常由單一技術編寫的

"應用程序"（比如Java網絡應用程序、Windows桌面應用程序，等等）。應用程序架構

的關注點是應用程序，通常包括將應用程序解構為類和組件，確保設計模式的正確應用，

構建或使用框架，等等。本質上，應用程序架構談論的是軟件設計的低級別切面，通常只

考慮單一的技術棧（比如Java、微軟.NET等）。

結構單元主要以軟件為基礎，包括編程語言和結構、類庫、框架、API等。它由類、組件、

模塊、函數、設計模式等加以描述。應用程序架構著重考慮軟件和代碼組織。

系統架構

我喜歡把系統架構看作是更大規模的應用程序架構。大多數軟件系統實際上是由橫跨不同

層次和技術的多個應用程序組成。舉個例子，你可能有這樣一個軟件系統，JavaEE中間

層消費Oracle數據庫提供的數據，同時向.NETSilverlight客戶端提供Web服務。每個部

分都有自己的應用程序架構。

要讓整個軟件系統工作起來，就要思考如何組合這些單獨的應用程序。換句話說，要有端

到端軟件系統在較高層次上的整體結構。另外，大多數軟件系統都不是孤立的，因此系統

架構還關注互操作性和與環境中其他系統的集成。

結構單元就是各種軟硬件，從編程語言和軟件框架到服務器和基礎設施。跟應用程序架構

相比，系統架構描述為從組件和服務到子系統等更高層次的抽象。系統架構的定義大多數

都包括了軟件和硬件。畢竟，一個成功的軟件系統離不開硬件，即使是云上的虛擬硬件。

軟件架構

應用程序和系統架構相對較容易理解，但人們對“軟件架構”一詞的理解不盡相同。我想把

軟件架構定義得盡可能簡單，而不去受制于各種定義的復雜性和細微差別。對我而言，軟

件結構就是應用程序和系統架構的結合。

換句話說，從代碼結構和基礎到將代碼成功部署到生產環境，與一個軟件系統重要元素相

關的所有東西就是軟件架構。從開發者的角度考慮軟件開發，關注點多數會放在代碼上。

在這里，我們考慮的是有助于構架更好軟件的東西，比如面向對象的原則、類、接口、控

制反轉、重構、自動化單元測試、代碼整潔和其他不勝枚舉的技術實踐。如果你團隊里的

人都只考慮這些，那么誰來考慮其他事情？

?橫切關注點，比如登錄和異常處理；

?安全性，包括認證、授權和敏感數據保密；

?性能、可伸縮性、可用性和其他質量屬性；

?審計及其他監管需求；

?客觀環境的約束；

?互操作性、與其他軟件系統的集成；

?運營、支持和維護的需求；

?結構和整個代碼庫解決問題、實現特性的方法的一致性；

?評估正在構建的基礎有助于交付按計劃進行。

有時你需要退一步，遠離代碼和你的開發工具。這并不意味著低層次的細節不重要，因為

可用的軟件最終還是要靠交付可運行的代碼。細節同樣重要，但就大局而言，對軟件的整

體視角可以確保你的代碼符合整體愿景而非背道而馳。

企業架構：戰略而非代碼

企業架構一般是指整個組織的中心工作，著眼于如何組織與利用人員、流程和技術來使企

業有效和高效地工作。換句話說，它是關于企業如何分成組或部門，業務流程如何在上層

運作，以及技術如何支撐這一切。這跟軟件架構形成了強烈對比，因為企業架構沒有必要

關注技術細節。相反，企業架構可能看重的是如何在整個組織中最好地利用技術，而無需

實際介入這些技術的工作原理。

有些開發者和軟件架構師把企業架構看作職業發展的下一站，然而大多數人卻并非如此。

從事企業架構工作所需要的思維方式和軟件架構大相徑庭，對于技術及其在組織中的應用,

視角很不一樣。企業架構需要更高層次的抽象。這關乎廣度而非深度，關乎戰略而非代碼。

第4章敏捷軟件架構是什么

以我的經驗，人們用"敏捷”一詞指代的往往不止一件事情。首當其沖就是軟件開發的敏捷

方法1；快速行動，擁抱變化，持續交付，接收反饋，不一而足。與敏捷思維模式相關

的第二個意思是，人們如何在敏捷環境中一起工作，通常包括了團隊動態、系統思維、心

理學以及其他可能會跟創建高效團隊聯系在一起的事情。

1http:〃

先把后面提到的這些“膚淺的東西”放到一邊，在我看來，給軟件架構打上“敏捷"的標簽就

意味著它能夠應對所處環境中的變化，適應人們提出的不斷變化的需求。這跟敏捷團隊創

建的軟件架構不盡相同。以敏捷方式交付軟件并不能保證得到的軟件架構是敏捷的。事實

上，以我的經驗，發生相反的事情通常是因為團隊更關注交付功能，而非架構。

理解“敏捷”

要理解你的軟件架構需要多敏捷，就應該看看敏捷究竟是什么。美國空軍戰斗機飛行員約

翰?博伊德（JohnBoyd）提出了一個名為00DA循環的概念2。本質上，這個循環構成了

基本的決策過程。想象一下，你是一個正與敵人纏斗的戰斗機飛行員。為了擊敗對手，你

需要觀察情況，確定自己的方位（比如做一些分析），決定做什么，并采取行動。在激烈

的戰斗中，為避免被對手擊落，這個循環要執行得盡可能快。博伊德說，如果你能洞悉對

手的OODA循環，執行得比他更快，就能混淆視聽，誤導對手。如果你比對手更敏捷，

就能成為最后的贏家。

2/wiki/OODAloop觀察、定向、決策和行動，Observe、

Orient、Decide、Act?

在一篇題為"WhatLessonsCantheAgileCommunityLearnfromAMaverick3FighterPilot"

（敏捷社區能從特立獨行的戰斗機飛行員身上學到什么）4的論文中，不列顛哥倫比亞大

學的史蒂夫?阿道夫引用了博伊德的概念，將其應用于軟件開發，得出的結論是敏捷是相

對的，且按時間來衡量。如果你的軟件團隊交付的軟件跟不上所處環境的變化，就不算敏

捷。如果你在一個龐大而行動緩慢、鮮有改變的組織中工作，很可能交付軟件要花費數月,

卻仍被組織認為是“敏捷”的；在一個精益初創團隊中，情況多半就不一樣了。

3Maverick是電影《壯志凌云》中湯姆?克魯斯飾演的飛行員的代號。

4http:〃/xpl/articleDetails.jsp?tp=&amumber=1667567

好的架構帶來敏捷

產生這個討論的動力是好的軟件架構能帶來敏捷。盡管面向服務的架構（S0A5）因為過

于復雜、臃腫和粗糙的實現而被一些組織看作骯臟的詞匯，但軟件系統由小型微服務6

構成仍呈一種增長趨勢，每個服務只專注做好一件事。一個微服務通常可能不到100行

代碼。如果需要改變，服務可以用另一種語言重新編寫。這種架構風格以多種方式提供了

敏捷。小型、松耦合的組件和服務可以孤立地構建、修改和測試，甚至根據需求變化移除

和替換。因為能夠加入新組件、服務并在需要時擴展，這種架構風格也很適合非常靈活和

可適配的部署模型。

5Service-OrientedArchitecture,/wiki/Service.

orientedarchitecture。

6/presentations/Micro-Services

然而，天上不會掉餡餅。構建一個這樣的軟件系統需要時間、精力和準則。很多人也不需

要這種水平的適應性和敏捷性，這就是為什么你看到那么多團隊構建的軟件系統實際上整

體感強得多，各部分捆綁在一起并以單一單元部署。盡管更易于構建，然而這種架構風格

在面對變化的需求時通常要花費更多精力去適配，因為功能往往交織在代碼庫中。

二卷體架構緣于服務的架構f、

（S0/7,微服分，\

1（通常是單一部署

\單兀的一團亂麻）箸等，分別部署）

V

■

介于胡者之間

（例如,單一部署單元的組件）

不同的軟件架構提供不同層次的敏捷

在我看來，兩種架構風格各有優缺點，應該在權衡利弊之后，再決定是構架一個整體系統

還是幾個微系統。和IT行業中所有的事情一樣，在這兩者之間也有中間地帶。抱著實用

主義的想法，你總能選擇構建一個由很多定義好的小組件構成，但仍作為單一單元部署的

軟件系統。這也讓你有可能在將來輕松地遷移到微服務架構。

你需要有多敏捷

理解組織或業務變化的速度很重要，因為這能幫助你決定采用何種架構風格，可能是整體

架構、微服務架構或者介于兩者之間。要理解這種權衡并做出相應的選擇。敏捷不是白來

的。

第5章架構對上設計

如果架構是關于結構和愿景的，那設計又是什么？如果你在創建一個解決問題的方案，這

不就是設計嗎？如果確實如此，那設計和架構有什么區別？

找出區別

對于架構和設計的區別，格雷迪?布奇(GradyBooch)有一個常被引用的定義，可以很好

地回答這個問題。在OnDesignl一文中，他說道：

1原文給出的鏈接

http:〃./index.jsp?page=Blog&part=2006已失

效，可訪問

https:〃/developerworks/community/blogs/gradybooch/entry/ondesign?

lang=en閱讀文章。

作為名詞，設計是指一個系統內命名的(盡管有時無法命名)結構或行為，解決或有

助于解決該系統的一個或多個問題。因而設計代表了潛在的決策空間中的一個點。

思考任何一個需要解決的問題，可能都有101種方法。以你目前的軟件項目為例，要實

現同一目標，可能有多種不同的技術、部署平臺和設計方法可選。即使是設計軟件系統，

你的團隊也只是從潛在決策空間里的很多個點中選擇一個。

格雷迪還說：

所有架構都是設計，但并非所有設計都是架構。

這很有道理，因為創建一個解決方案本質上就是一次設計練習。然而，出于某些原因，有

一個區別使得并非所有設計都是“架構”，對此他聲明：

架構反映了使一個系統成型的重要設計決策，而重要性則通過改變的成本來衡量。

從本質上講，格雷迪認為重要決策即"架構"，其他的都是“設計”。在現實世界中，架構和

設計的區別并不明顯，但該定義確實為我們提供了一個基準，去思考在我們的軟件系統中

哪些可能是重要的（或者說“架構的。比如說，這可能包括：

?系統的形態（例如，客戶端-服務器、基于Web、原生移動客戶端、分布式、

異步，等等）；

?軟件系統的結構（例如，組件、層、交互，等等）；

?技術選擇（即編程語言、部署平臺，等等）；

?框架選擇（例如，WebMVC2框架、持久性/0RM3框架，等等）；

?設計方法/模式選擇（例如，針對性能、可伸縮性、可用性等的方法）。

2Model-View-Controller,模型-視圖-控制器。

3Object-RelationalMapping,對象關系映射。

架構決策不可能輕易反悔，那會大費周章。或者說直白點，架構決策很難在一個下午就完

成重構。

理解意義

后退一步想想哪些對你的軟件系統很重要，這往往是值得的。例如，很多團隊使用關系型

數據庫，這個選擇可能被認為很重要。為了減少在數據庫技術變化時必要的返工量，很多

團隊會使用Hibernate或EntityFramework這樣的ORM框架。引入額外的ORM層使得

數據庫操作能與代碼的其他部分解耦，而且理論上，不用花費很多精力就能獨立地切換數

據庫。

引入額外層的決策是將某個部分從軟件系統中解耦的經典技術，促進了低耦合、高內聚和

更好的關注點分離。此外，有了ORM以后，可能一個下午就完成了數據庫的切換。從這

一點來說，從架構上它不會再被看作是重要的。

然而，當數據庫的選擇可能不再被當作重要決策時，通過引入額外層實現解耦就應該是重

要決策。如果你想知道為什么，試想把你當前所用的ORM或WebMVC框架完全替換成

另一個，要花多長時間。當然，你可以在所選的ORM上再添加其他層，以隔離業務邏輯,

并提供輕松替換ORM的敏捷性。但是，你又做出了另一個重要決策：引入了額外的分層、

復雜性和成本。

盡管"重要決策"沒法徹底消失，但能通過架構分層等多種策略來改變。軟件系統架構流程

的一部分就是搞清楚哪些是重要的及為什么。

第6章軟件架構重要嗎

那么，軟件架構重要嗎？敏捷和軟件工藝運動幫助提升了我們構建的軟件系統的品質，這

非常好。它們一起幫助我們在謹慎管理時間和預算限制的同時，寫出更好、更能滿足業務

需求的軟件。但是我們能做得更多，因為即使是少量的軟件架構，也能幫助預防項目的很

多問題。成功的軟件項目不僅僅是好的代碼，有時候你要暫時跳出代碼，總覽大局。

缺乏軟件架構將引發問題

既然軟件架構是關于結構和愿景的，那你可以說它總是存在的。我同意，確實如此。說了

這么多，顯而易見，不思考軟件架構（以及“大局”）會導致團隊經常遭遇一些常見問題。

問問你自己下面這些問題：

?你的軟件系統有良好定義的結構嗎？

?團隊里每個人都以一致的方式實現特性嗎？

?代碼庫的質量水平一致嗎？

?對于如何構建軟件，團隊有共同的愿景嗎？

?團隊里每個人都得到了足夠的技術指導嗎？

?有適當的技術領導力嗎？

如果上面某些問題的答案是“不"，那就需要很好的團隊和很好的運氣才可能成功地交付一

個軟件項目。如果沒人思考軟件架構，最終結果往往看起來像一團亂麻(bigballofmud)

1o當然，會有一個結構，但不是你想要的！其他副作用還包括軟件系統太慢、不安全、

脆弱、不穩定、難以部署、難以維護、難以改變、難以擴展，等等。我敢肯定你從沒見過

或參與過這樣的軟件項目，對嗎？你沒有，我也沒有。

1:http:〃/mud/。

既然軟件架構是每個軟件系統都固有的，那我們為什么不干脆承認這一點，放一些心思在

上面？

軟件架構的好處

思考軟件架構能帶來哪些好處？總結如下:

?讓團隊跟隨一個清晰的愿景和路線圖，無論這個愿景是一人所有還是整個團隊

共有；

?技術領導力和更好的協調；

?與人交流的刺激因素，以便回答與重要決策、非功能需求、限制和其他橫切關

注點相關的問題；

?識別和減輕風險的框架；

?方法和標準的一致性，隨之而來的結構良好的代碼庫；

?正在構建的產品的堅實基礎；

?對不同的聽眾，以不同層次的抽象來交流解決方案的結構。

所有軟件項目都需要軟件架構嗎

我不會給出“看情況”這種典型的咨詢式回答，相反我會說答案毫無疑問是肯定的，并提醒

每個軟件項目都應該考慮多種因素，以評估必需多少軟件架構的思考。這些包括了項目/

產品的大小、項目/產品的復雜性、團隊的大小和團隊的經驗。對于多少是“剛剛好"，將

在本書其他部分探討。

第7章問題

1.你知道“架構”都說些什么嗎？你所在團隊的其他人知道嗎？你所在組織的其他人呢？

2.IT領域有很多不同類型的架構。它們有什么共同之處？

3.你和團隊對“軟件架構”的含義有一個標準定義嗎？你能夠輕松地向團隊的新成員解釋嗎？

這個定義在你所在組織通用嗎？

4.如果用“敏捷”來描述一個軟件的架構，是什么意思？你如何面向“敏捷”進行設計？

5.你能夠把你當前軟件項目所做的架構決策列一個清單嗎？它們被視為重要的原因明顯嗎？

6.如果從代碼后退一步，你的軟件系統的“大局”中包含了哪些事情？

7.你所在組織的技術職業發展怎么樣？企業架構會是你的出路嗎？

8.軟件架構重要嗎？為什么，好處是什么？你的軟件項目的架構足夠嗎？還是太多了？

PartII軟件架構的角色

這部分將關注軟件架構的角色，包括軟件架構的角色是什么，需要哪類技能，以及為什么

編碼、指導和合作很重要。

第8章軟件架構的角色

要成為一名軟件架構師，絕非一夜之間或一次晉升那么簡單。這是一個角色，而不是一個

級別。這是一個循序漸進的過程，你會逐漸獲得這個角色所需的經驗和信心。"軟件開發

者”這個詞很容易理解，而“軟件架構師”則不然。下面是我認為構成軟件架構角色應有的

內容。注意，我這里說的是"角色"；它可以是一個人，也可以由團隊共同扮演。

、

架構驅動力設計軟件技術風險

理解目標；抓住、提建立技術戰略、愿景發現、減輕和承擔技

煉、挑戰需求和限制和路線圖術風險，保證架構的

“運轉”

架構演化編寫代碼質量保證

貫穿整個軟件交付過參與到軟件交付的實引入并堅持標準、指

程，持續的技術領導踐部分導、原則等

和對架構的承擔

軟件架構

角色

1.架構驅動力

這個角色首先要理解業務目標和管理架構驅動力，其中包括需求（功能性需求和非功能性

需求）和環境的限制。軟件項目經常糾纏于詢問用戶需要什么功能，卻很少問他們有哪些

非功能性需求（或質量屬性）。有時候利益相關者會告訴我們“系統一定要快"，這太主觀

了。非功能性需求和限制往往對軟件架構有巨大的影響，因此明確地將其納入軟件架構的

角色，可以保證它們被考慮到。

2.設計軟件

設計軟件的過程是軟件架構角色的一部分，這一點應該在意料之中。這涉及要理解如何解

決架構驅動力帶來的問題，創建軟件系統的整體結構，并為交付設定一個愿景。不管你想

做到多敏捷，你可能都需要花一些時間去明確思考架構要如何解決利益相關者提出的問

題，因為你的軟件系統自己搞不定它們。

軟件設計的一個關鍵部分是技術選擇，這通常是一個有趣的練習，但也有一定的挑戰。例

如，有些組織有一份允許使用的技術清單，你只能從中選擇，有些組織則規定不允許使用

特定許可的開源技術。接下來是其他所有因素，比如成本、許可、供應商關系、技術戰略、

兼容性、互操作性、支持、不熟、升級策略、最終用戶環境，等等。這些因素摻雜在一起,

常常會把選擇一個富客戶端技術之類的簡單決策徹底搞成一場噩夢。需要有人負責這個技

術選擇的過程，這完全屬于軟件架構角色的職責范圍。

3.技術風險

到目前為止的內容可以幫你專注于構建好的解決方案，但并不能保證成功。把最好的設計

和最好的技術簡單地拼湊在一起，并不意味著整個架構就會成功。你選擇的技術是否真的

奏效，也是個問題。很多團隊都有“做不如買"的戰略，為了可能會節約成本而去使用一些

（商業或開源的）產品。然而，很多團隊也因為聽信供應商網站或西裝革履的銷售人員的

宣傳，結果遭了殃。似乎很少人會問技術是否真的以設想的方式工作，能證明的人更少。

技術選擇其實就是風險管理，當復雜度或不確定性高的時候降低風險，有利可圖時再冒點

險。所有的技術決策，在做出選擇時都要把全部因素考慮在內，這些技術決策也需要評審

和評估。這可能包括一個軟件系統所有的主要結構單元，下至在開發過程中引入的庫和框

架。

你要問自己的問題是，你的架構是否“管用”。對我來說，一個架構如果能滿足非功能性需

求，在給定的環境約束下有效，能為其他代碼提供必要的基礎，作為平臺能解決潛在的業

務問題，那就是管用的。軟件最大的一個問題就是，它復雜而抽象，很難通過圖表甚至代

碼本身可視化一份軟件在運行時的特征。止匕外，我并不總是相信自己第一次就能做好。當

然了，說不定你可以！

在整個軟件開發的生命周期中，為了有信心讓所構建的系統在交付時能正常工作，我們會

進行多種類型的測試。那為什么不對架構也這樣做？如果能測試架構，我們就能證明它是

管用的。如果可以做得盡可能簡單，我們就能降低項目失敗的整體風險。架構師應該像優

秀的主廚一樣，品嘗自己生產的東西。概括地說，就是主動發現、減輕和承擔高優先級

的技術風險，這樣才能保住你的項目和工作。

4.架構演化

很多時候，軟件先被設計好，然后交給開發團隊，實際上在把軟件開發當作接力運動來

處理。結果適得其反，因為這樣的軟件架構需要照顧。得有人看著它，在整個交付過程中

依據不斷變化的需求和團隊反饋來對其演化。如果架構師創建了一個架構，為什么在整個

交付過程的其他時候不自己擁有和演化這個架構？這關乎持續的技術領導，而不是僅僅參

與生命周期的開始階段，然后泰然處之、袖手旁觀。

5.編寫代碼

我認識的大多數最優秀的軟件架構師，都有軟件開發的背景，但由于種種原因，許多組織

并不認為寫代碼是軟件架構角色的一部分。做一個“實踐派軟件架構師”并不一定指涉足日

常的編碼任務，但確實意味著你要持續地參與到交付中，積極地幫助引導和塑造它。說了

這么多，為什么日常編碼工作不應該是軟件架構角色的一部分？

許多軟件架構師都是構建大師，所以經常練手是有意義的。此外，編碼為架構師提供了

一種與團隊分享軟件開發經驗的方式，從而幫助他們更好地理解如何從開發的角度看待架

構。許多公司都有阻止軟件架構師參與編碼工作的政策，因為他們的架構師“太寶貴了，

不該承擔日常編碼工作”。這顯然是錯誤的，如果你不打算讓軟件架構師為成功交付做出

自己的貢獻，為什么還要讓他們為軟件設計投入全部精力？

當然，有些情況下要參與到代碼級別并不實際。例如，一個大型項目通常意味著要照看更

大的“大局”，有可能你根本沒時間寫代碼。但是一般來說，一個寫代碼的軟件架構師會更

有成效也更快樂。你不應該因為“我是架構師”，就把自己排除在編碼之外。

6.質量保證

即使有了世界上最好的架構，糟糕的交付也能讓原本可以成功的軟件項目失敗。質量保證

應該是軟件架構角色的一部分，但它的內容不只是代碼評審。你要保證一條基線，它可以

是引入一些標準和工作實踐，如編碼標準、設計原則和工具。質量保證也包括確保團隊對

架構實現的一致。管它叫架構服從還是架構一致取決于你，但都要遵循技術愿景。

可以肯定地說，大多數項目沒有做足夠的質量保證，因此，你要弄清楚什么是重要的，并

確保它有充分的保證。對我來說，只要是架構上顯著的、業務上關鍵的、復雜的和高度可

見的，都是一個項目的重要組成部分。你要務實地認識到沒辦法保證每件事。

合作或失敗

一個軟件系統很少孤立存在，可能有不少人要為整個架構過程作貢獻。這包括了從需要

理解和認同架構的直接開發團隊，一直到那些對安全性、數據庫、運營、維護或支持感興

趣的人組成的擴展團隊。任何擔任軟件架構角色的人都需要與這些人合作，以確保架構能

與周圍環境成功整合。如果不合作，就等著失敗吧。

技術領導是一個角色而非級別

軟件架構的角色基本上就是向軟件團隊引入技術領導，有必要重申的是，我這里談論的是

一個角色，而非職務級別。通常，大型組織會作為對長期服務的獎勵，或者因為想給某人

加薪，而搬出“架構師”的頭銜。如果接受這個頭銜的人具備承擔這個角色的能力，那就沒

問題，但情況并不總是如此。如果你訂閱過Linkedln或StackOverflow的軟件架構討論

組，可能見過類似的問題：

嘿，我剛晉升為軟件架構師，但我不知道該干些什么。救救我！我要看什么書？

盡管無法阻擋一些組織讓人晉升到超出其能力的角色，我還是可以描述自己對軟件架構角

色的看法。設計軟件可能是這個角色樂趣的一部分，但一個成功的軟件項目遠不止如此。

提出你自己對這個角色的定義

根據我的經驗，盡管很多軟件團隊都明白自己需要軟件架構這個角色，卻往往沒有一個參

考定義。少了這個定義，很可能就無法履行這個角色的部分或全部職責。

大多數跟軟件開發團隊有關的角色都比較容易理解一一開發人員、測試人員、流程經理、

產品所有者、業務分析師、項目經理，等等。軟件架構角色？不清楚。我經常問軟件團隊

對軟件架構角色有沒有參考定義，常見的回答不外乎"沒有"或"有，但我們不用"。同一個

團隊的人往往會給出不同答案。

軟件架構的必要性通常是公認的，但這個角色的責任往往并不明確。根據我的經驗，這可

能導致沒有人承擔這個角色，或者有人被安排了這個角色，卻不真正了解應該怎么做。如

果沒有理解角色，就不會發揮相應的作用，更遑論培養未來的軟件架構師。

不管你怎么稱呼它（比如架構師、技術主管、首席設計師等），我的建議都很簡單。如果

你沒有什么東西可以用來表達"這就是我們對軟件架構師的期望”，花些時間想想這回事。

首先，對于對軟件架構角色的期望，要跟你的團隊達成共識；然后，如果看到益處，就在

你的組織里對其標準化。

第9章軟件架構師應該編碼嗎

既然我創建了一個叫作編碼架構的網站1,我猜這個問題的答案就不出人意料了。在我

理想的世界觀中，軟件架構師應該編碼。曾經有人告訴我，優秀架構師的重要特征是抽象

思維能力，也可以理解成不把所有時間都耗在細節里的能力。這沒錯，但你畫的那些框框

線線終歸要形成代碼。

1http:〃

編寫代碼

我的建議是讓編碼成為你作為軟件架構師角色的一部分，只要把自己當作軟件開發團隊的

一份子就行了。換句話說，你有一頂軟件架構的帽子和一頂編寫代碼的帽子。你不見得要

成為團隊里寫代碼最厲害的，但參與到實踐和交付流程的好處非常大。畢竟，"知"和"行”

還是不同的。

團隊欣聞你要貢獻代碼，通常會受到鼓勵，確保你的設計能落到實處。如果沒有，那么一

旦你站在開發者的角度明白了這個問題，很快就能體會到那種痛苦。

創建能實際實現的軟件架構，這樣做的好處顯而易見，除此之外，貢獻代碼還能幫助你和

團隊建立起融洽的關系，有助于縮短存在于很多軟件團隊的架構師和開發者之間的距離。

引用瑞秋?戴維斯(RachelDavies)和麗茲?賽德利(LizSedley)在《敏捷教練：如何打造

優秀的敏捷團隊》2一書中說的話：

2http:〃/book/sdcoach/agile-coaching

如果你了解如何編程，往往會忍不住對開發者該如何編寫代碼提出建議。小心，因為

你可能在浪費時間：如果你沒有參與項目的編程，開發者多半會無視你的編碼經驗。

他們還會認為你越權，影響了他們的工作，所以盡量別在這方面指指點點。

構建原型、框架和基礎

當你被看作開發團隊的一員時，軟件架構的角色可能會輕松得多，然而有時這卻不太可能。

晉升或被指定為軟件架構師帶來的一個問題在于，你可能會發現自己不能像期望的那樣寫

很多代碼。這可能因為時間壓力，因為你有很多"架構”工作要做，或者只是公司政策不允

許你寫代碼，我見過這樣的情況。如果是這樣的話，對軟件系統中有疑問的概念構建原型

和證明是一個很好的參與方式。這讓你可以和團隊建立起融洽的關系，也是評估你的架構

是否管用的好辦法。

作為替代，你可以幫助建立團隊可用的框架和基礎。試著抵擋住構建好這些東西再交給團

隊的誘惑，因為這樣可能會適得其反。軟件開發非常容易趕潮流，所以小心別構建出一個

東西卻被團隊當作毫無價值的過時破爛！

進行代碼評審

顯然沒有什么能代替給真正的項目編碼，我也不推薦把代碼評審作為一個長期的戰略，但

參與（或做）代碼評審至少能讓你了解新技術及其應用。對于你沒有經驗的技術，挑剔或

參與討論可能會損害你的名聲。我記得自己曾不得不向一個從未寫過一行Java代碼的架

構師解釋自己的java代碼。那很無聊。

實驗并與時俱進

你需要保持一定水平的技術知識，才能稱職地用它來進行方案設計。但是，如果無法對交

付做出貢獻，作為架構師的你要如何維持編碼技能？

在工作之外你往往有更多的空間來維持編碼技能，從貢獻開源項目，到不斷嘗試你感興趣

的最新語言、框架、API。書、博客、播客、會議和聚會都能達到這個目的。但有時候你

必須跳出代碼。這些事我當然都做過，乘坐公共交通工具長途通勤的一個好處是你有時間

去玩技術。當然了，前提是你經過一天的辛勤工作還不犯困的話！

軟件架構師和雇主之間的矛盾

我很幸運，我的軟件架構角色中有相當部分的實踐元素，大多數我參與的項目都有我的代

碼。我堅定地認為，機會是自己創造的。我仍然動手實踐的原因可以這樣表述：它是這個

角色的重要組成部分。對我來說這很簡單。設計軟件時，編碼是必不可少的，因為我需要

熟悉最新的技術，搞清楚我設計的哪些東西能工作。另外，我得承認編碼很有趣。

可惜，許多組織似乎認為編碼是軟件開發過程中最容易的部分，因此他們通常讓另一個國

家的其他人來做這件事，以為這樣能省錢。好的代碼在這樣的組織看來也是"低價值”的。

組織中軟件架構師的資歷和編碼工作的價值就脫節了，矛盾由此產生。

以我的經驗，小組織不會發生這種事，因為需要人手時每個人都要參與進來。是的，那些

大型組織里的矛盾最嚴重。我曾在一個中等規模的咨詢公司工作過一段時間，我的職位等

級把我歸入管理團隊，但我仍會寫代碼。在某些方面，頂著“行政經理”的頭銜，又能每天

寫代碼，真是了不起的成績！但有時這也讓人很不舒服，因為其他經理經常會試圖在其組

織架構圖里加上我的名字。

陷入這種情況是很麻煩的，只有你自己能擺脫它。無論你是在一個正在發生這種事的組織,

還是想要離開是非之地，都要搞清楚你對軟件架構師這個角色的看法，并準備好堅守自

己的立場。

你不必放棄編碼

說到這一點，我會經常被問及“如果軟件架構師打算在公司的職業道路上有所作為，是否

還能繼續編碼”，也就不奇怪了。這真是羞恥，尤其是如果這些人真的很喜歡他們所做的

技術。

對此我的態度絕對是肯定的，你可以繼續寫代碼。對我來說，聽到人們說“好吧，為了成

為架構師或在職業道路上更進一步，我明白自己不得不放棄編碼了"，是相當令人沮喪的。

有很多組織是這樣的，肯定有很多人被告知組織中的高級職位不需要寫代碼。

軟件架構師在滿足非功能性需求、進行技術質量保證、確保軟件符合其用途等方面，要承

擔很大的責任。這是一個領導的角色，編碼（以身作則）是保證項目成功最好的方式之一。

此外，如果軟件架構師不保持技術能力，誰來培養更多未來的軟件架構師？

不要把全部時間都用于編碼

重申一下我的建議，軟件架構師不必放棄編碼。無論你怎么做，在不斷變化的世界中，編

碼是一個保持技術能力的好辦法。很多人認為軟件架構是一種“后技術”的職業選擇，但除

了豐富的經驗和更寬的知識面，它還需深厚的技術能力，需要能夠回答設計是否真的管用

這類問題的T形人才。把這歸為“實現細節”是不可接受的。只是別把時間都花在編碼上。

如果你花全部時間寫代碼，那軟件架構角色的其他部分由誰來扮演？

第10章軟件架構師應該是建造大師

把建筑的隱喻應用到軟件不見得合適，盡管在中世紀，設計建筑的人只是極少數，卻組成

了建造大師的高端社團。之所以做這樣的隱喻，是因為建造大師名副其實是他們這門學問

的大師，一旦達到了這種高度，建造大師是繼續建造還是讓其他名氣不大的人來做？幾百

年后，我們似乎又在對軟件行業問同樣的問題。

聯盟的狀態

在過去的十年間，由于“大型預先設計"和"分析麻痹"等問題，軟件架構已經失寵。這多半

源于為了更有效地交付軟件系統，敏捷方法作為主要的催化劑，減少了很多團隊都要做的

預先思考的工作量，結果現在“架構師”在軟件團隊里往往被看作是多余的。很多團隊都向

著扁平化和自組織努力，從表面上看這不需要再專設技術領導。

另一個因素是，許多人認為架構師都在做高層次的抽象思維。我相信你已經見過“象牙塔

架構師"或"PPT架構師”等說法，用來指代那些設計解決方案時從不考慮細節的人。如果

我們回顧一下過去，這可不是架構師的角色。

回顧過去

如果你追溯"架構師"(architect)一詞在拉丁語(architectus)和希臘語(arkhitekton)

的源頭，直譯就是“首席建筑師”，從字面上看，這些人是他們這行中的佼佼者。在中世紀,

“建筑師"一詞指"石匠大師"，因為石頭是當時的主要建筑材料。下面這句話對這個角色做

了很好的總結1:

1http:〃www.moonshadow.co.uk/?p=66

石匠大師，就是石頭的操作者、藝術家和設計師。

這句話同樣適用于我們軟件開發者。

建造大師真的會建造嗎

關鍵問題是，建造大師是否真的建造了什么？如果你研究一下人們如何實現“石匠大師”的

角色，就會發現一些類似的東西2：

2http:〃/article/the-medieval-stonemason-and-the-master-mason-a65816

盡管石匠大師受人尊敬、通常也很富有，然而在達到行業頂峰之前，他必須經歷石匠、

監督的歷練來證明自己的價值。

架構師的維基百科頁面說了相同的話3:

3http:〃/wiki/Architect

在古代和中世紀的歷史中，大多數建筑設計和建設都是工匠完成的：下至石匠和木匠,

上至建造大師。

有趣的是，對于這些石匠大師參與過多少建筑，并沒有一個統一觀點。比如4：

4http:〃www.moonshadow.co.uk/?p=66

他實際上做了多少，其實是有爭議的。這個術語可能會有所不同，但是，以我的理解,

中世紀石匠大師基本的組織和角色跟今天的首席建筑師是類似的：這也許反映了建筑

建造不變的基本。

真正有意義的是看看這個角色承擔了什么。引用另一段話5：

5http:〃www.historylearningsite.co.uk/medievalmasons.htm

頂尖的石匠就是一個石匠大師。然而，建筑大師這個頭銜，指的是全面負責建筑工地、

讓石匠大師們為他工作的那個人。建筑大師也負責木匠、玻璃工匠等。實際上，每個

建筑工地上的人都在建筑大師的監督下工作。

再加一些額外的細節6：

6http:〃www.moonshadow.co.uk/?p=66

然后，石匠大師為將要建造的東西設計結構、美學和象征等方面的特性，組織后勤，

還要評定工作的優先級并決定它們的順序。

象牙塔

如果這聽起來很熟悉，等一等，看看團隊過去是如何工作的7：

7http:〃www.moonshadow.co.uk/?p=66

每一個小石匠都遵循大師設定的方向和對主要結構或美學的所有決定，解決那些問題

都是大師的工作。

顯然，容易看出很多軟件團隊的傳統運作方式與此相似，敏捷軟件開發團隊希望采用一種

不同的方法也就不奇怪了。很多現代的軟件開發團隊試圖讓一群人分擔技術領導者的角色,

而不是安排一個遠離細節的專門角色。當然，很多架構師遠離細節的主要原因之一是他們

沒有時間。這通常導致架構師在現實的團隊日常工作中被移除，慢慢變得脫離實際。過去

的石匠大師也被這個問題困擾8：

8http:〃www.moonshadow.co.uk/?p=66

看起來同時進行多個任務是很平常的事情，石匠大師很少參與體力工作(即使身體條

件允許)也就不足為奇。1261年，尼古拉斯?德?比亞德(NicholasdeBiard)在布道

中斥責“只靠言語就做判斷，的石匠大師的明顯懶惰，給出了這一假設的證詞。

下面這段話來自瑞秋?戴維斯和麗茲?賽德利所著的《敏捷教練：如何打造優秀的敏捷團隊》

9,突出了這種現象在軟件行業中造成的一個常見后果：

9http:〃/book/sdcoach/agile-coaching

如果你了解如何編程，往往會忍不住對開發者該如何編寫代碼提出建議。小心，因為

你可能在浪費時間：如果你沒有參與項目的編程，開發者多半會無視你的編碼經驗。

他們還會認為你越權，影響了他們的工作，所以盡量別在這方面指指點點。

為了掩蓋這種局面，很多人會把軟件架構的角色看作其組織內的一個高級職位或級別，從

而加劇了開發者和架構師之間的脫節。看來，石匠大師也有相同的境遇10：

10http:〃www.moonshadow.co.uk/?p=66

為了避免這種爭斗，文藝復興后期的藝術家們不再被視為只是普通的工匠，而石匠大

師似乎被神話(在我看來)為貴族后裔。此外，由于對所掌握知識秘而不宣，他們制

造了一種神秘感，讓自己有別于其他不那么"神秘"或"高尚"的職業。

建造大師角色的差異

多數看法都一樣：建造大師并沒有太多時間去建造，盡管他們具備這樣的技能。回到軟件

行業，軟件架構師應該寫代碼嗎？我直截了當地回答："理論上，是的。"更完整的答案可

以在這本書里面找到。為什么？因為技術不是一個實現細節，你需要理解為自己的決定

所做的取舍。

那么現代建筑師為什么不為實際的建造過程出力呢？為了回答這個問題，我們要看看這個

角色這些年是如何演化的11：

11http:〃/wiki/Architect

在古代和中世紀的歷史中，大多數建筑設計和建設都是工匠完成的：下至石匠和木匠,

上至建造大師。直到現代，建筑師和工程師之間也沒有明顯的區別。在歐洲，建筑師

和工程師的頭銜主要因地域不同而經常交替使用，但指的都是同一個人。

結構工程的維基百科頁面12提供了更多信息：

12http:〃/wiki/Structuralengineering

自從人類開始修筑屬于自己的結構，結構工程就出現了。在19世紀末的工業革命期

間，建筑專業體現出了與工程專業的不同，成為一個更正式的專業。直到那時:建筑

師和結構工程師通常還是同一個人：建造大師。19世紀和20世紀初，隨著結構理

論專業知識的發展，專門的結構工程師才開始出現。

本質上，傳統建筑師的角色已經分化為兩種。一種是結構工程師，確保建筑物不倒塌；另

一種是建筑師，負責與客戶交流，收集他們的需求，從美學的視角進行建筑設計。馬

丁?福勒(MartinFowler)的blikil3有一個頁面談到了兩種角色差異的意義：

軟件架構師被看作是首席設計師，是把項目的每件事凝聚在一起的人。但建筑師可不

會干這些。建筑師關注的是與想要建筑的客戶交流。他的精力集中在客戶覺得重要的

事情上，比如建筑的布局和外觀。但建筑也不僅限于此。

因其背后蘊含的包括物理定律在內的豐富知識，建筑現在被看作是一門工程學科，這些知

識能夠建模和預測建材的行為。相比之下，軟件開發行業還比較年輕，正以驚人的速度發

展。今天的建筑大多還是使用和幾百年前相同的材料，但似乎我們每20分鐘就會發明一

種新技術。我們生活在“互聯網時代”。除非我們這個行業發展到軟件的構建方式和預測工

程項目相同，否則團隊中有人一直跟隨技術的發展，有能力做出如何設計軟件的正確決策,

還是很重要的。換句話說，軟件架構師還需要扮演結構工程師和建筑師的角色。

實現角色

最后，簡要地說一下，人們如何實現石匠大師的角色。下面這段話來自維基百科的“石匠

工藝”頁面14：

14http:〃/wiki/Stonemasonry

中世紀對石匠技能的需求很大，行業協會的成員按水平被劃分為三個等級：學徒、幫

工和石匠大師。學徒要和師傅簽訂契約，以此換取師傅的培訓；幫工的技能要高一些,

可以到外面去協助別的師傅；石匠大師被看作自由人，可以按自己的意愿選擇主顧的

項目。

這反映了我自己擔任軟件架構角色的經驗。它是一個漸進的過程。像很多人一樣，我的職

業生涯始于在別人的監督下寫代碼，漸漸地，當我獲得更多的經驗，就開始承擔更大的設

計任務。不同于中世紀的建筑行業，對于如何從初級開發者到軟件架構師，軟件開發行業

缺乏明確的路線。我們沒有普遍的學徒模式。

架構師要和團隊一起工作

對很多組織來說，這里有個大問題：找不到足夠的架構師。雖然石匠大師可能沒有太多時

間自己去跟石頭打交道，但還是和團隊一起工作。我常常遇到一些架構師，他們要協助多

個不同團隊。很明顯，如果和多個不同團隊一起工作，要向軟件交付的實踐部分做出貢獻

是不現實的，你沒有時間寫任何代碼。

在多個團隊中扮演軟件架構角色，并不是一個有效的工作方式。通常這種情況發生時，都

有一個由被視為共享資源的架構師組成的中心組（比如“企業架構組"）。根據我所讀到的,

石匠大師任何時候都會只關注一個建筑工地，這也正是我們的軟件開發團隊應該采用的方

法。如果你認為這不可能，就看看中世紀建筑行業是怎么解決這個問題的15：

15http:〃www.historylearningsite.co.uk/medievalmasons.htm

每個石匠都會帶一個為他工作的學徒。當石匠接下一份新工作，學徒也會跟著他。如

果石匠覺得自己的學徒已經對行當足夠了解，就會讓他在石匠行