在敏捷開發過程中，我們還需要對系統架構進行設計嗎?事實上，Martin Fowler在《Is Design Dead?》一文中已經給出了答案，那就是我們同樣不能忽略對系統架構的設計。與計劃性的設計(Planned Design)不同，我們需要演進式的設計(Evolutionary Design)。在敏捷開發的生命周期中，我們通過每一次迭代來豐富與更新我們的設計方案，以使其最大限度地符合客戶對系統的需求。這里所指的需求，包括功能性需求和非功能性需求。

　　在Agile Journal四月刊中，IBM's Methods Group的敏捷專家Scott W. Ambler詳細地闡述了在敏捷語境中的架構設計方法，他提出了所謂“架構預測(Architectural Envisioning)”的方法，以應對敏捷開發中逐步演進的架構設計過程。

　　Scott指出，敏捷模型驅動開發(Agile Model Driven Development，AMDD)明確地包括了初始需求分析與架構建模，這個過程發生在敏捷項目開發的第0次迭代中。所謂第0次迭代，就相當于項目的熱身活動，是項目得以啟動的基礎。在此迭代期間，團隊需要充分地理解項目的范圍，甄別可行地技術策略。這個階段所能夠收集到的信息將有助于你對整個項目最初的粗略估計，以制定合適的項目計劃，從而獲得啟動項目的資金與足夠的支持。

　　敏捷模型驅動開發的生命周期如下圖所示：

　　根據圖中所示，在每次迭代的初期，制定的迭代計劃都應該包括建模的工作。在此期間，可以召開建模的頭腦風暴會議，討論系統的功能特征，并思考實現這些特征的高層設計策略。大多數敏捷團隊都會通過測試驅動開發(TDD)確定需求與設計的細節。

　　通過對架構的預測，可以在項目早期進行一些高層次的架構建模，以助于團隊與關鍵利益相關人商討系統采取的技術策略。這一行為的關鍵目標是識別出架構策略，而不是撰寫如山一般堆積的文檔，從而使得你能夠快速完成架構建模。其中的竅門就是盡量保持簡單。開發者不需要對大量的細節進行建模，而只需要足夠即可。如果你正在編寫用例，意味著你只需要以標注形式列出用例的要點就足夠好了。如果你正在對領域建模，可以直接在白板上繪圖，或者使用CRC卡片。你的目的在于對信息的共享與交流，而不是編寫細致的文檔。

　　如果采用架構預測的方式，你需要對哪些內容進行建模呢?Scott在文中指出有如下四部分內容需要建模：

　　技術圖表。例如UML部署圖。這些圖表有助于開發者預測主要的軟件和硬件組件，包括你需要訪問的舊系統和數據庫，系統有可能會與它們進行交互。

　　用戶交互流程圖。通過分析用戶交互的主要頁面/外觀和報告，對系統的UI進行架構設計。如果在進行架構設計的時候不考慮用戶交互界面，就可能存在潛在危機，那就是你構建的系統不是利益相關人所希望看到的。請記住，UI才是最終用戶使用的系統。

　　領域圖。在最初的架構建模中，一個重要的組成部分是對領域的高層建模。模型可以非常微小，只需要捕獲主要的業務實體，以及它們之間的關系。有的人可能認為領域模型應該屬于需求建模的一部分，而不是架構建模。但正如上圖所示，這兩者在第0次迭代中是并發進行的。

　　變更情形。就是在架構級需求中描述可能的技術或業務變更，而這些變更需要在未來能夠提供支持。變更情形要求你考慮架構的擴展能力，但并不是過度構建你的系統。因為你只是要考慮由于變更所造成的影響，以確保你構建的系統還能夠正常工作。

　　架構建模是貫穿于整個項目周期的，因此這些圖表就是在項目結束時形成的整體文檔的基礎。由于你事先明確架構是演進的，因此就不必承擔架構設計在項目早期必須“正確無誤”的壓力，而只需要在當前形勢下保證足夠好就可以了。Scott建議使用白板和草稿紙等簡便工具，勾勒出這些模型的初始版本。當然，如果團隊成員具有熟練的建模技巧，也可以使用專門的建模工具。這一建議足以體現架構設計的敏捷性，與長篇累牘的傳統架構設計方式迥然不同。

　　對于這樣一種架構設計方式，熟悉傳統架構設計方式的架構師普遍不以為然。Scott對這一看法給與了強有力的反駁。他將架構設計場景分為三種類型。第一種是架構師熟悉系統架構設計所必需的技能與經驗。既然你已經熟悉了這些內容，當然就沒有必要作出完整的設計了。你只需要在白板上體現你的架構設計，保證團隊的每個人都能夠按照相同的體系架構進行實現就可以了。

　　第二種場景是架構師對相關技巧與經驗完全不知。此時，仍然只需要作少量的初始建模即可。因為你缺乏足夠的知識來完成細致而又全面的架構設計，反而會因為了解不夠而導致錯誤，從而增加項目的風險，并且阻礙了項目的進度。

　　第三種場景則是架構師熟悉部分知識。這種情形也是團隊開發中最常見的場景。在這種情況下，可以耗費幾天時間作出一個初始的架構建模，以驗證系統可能存在的風險，并制定可能策略以減輕風險可能造成的后果。你可以實現一些可工作的代碼來驗證架構。建模在這種情況下是非常有意義的，因為它使得你可以定義一個一致的技術愿景，為團隊成員所分享，并對系統的主要問題進行思考。

　　當你的團隊成員是分散在各地時，或者當團隊非常龐大，下面分為多個小組時，這種初始的架構建模就能夠帶來無與倫比的價值。它有助于在團隊成員之間建立一個公共的愿景，更重要的是它能夠識別出分離的組件/子系統，以及這些組件的初始接口。一旦識別出這些耦合度較低的組件或子系統，就能夠合理地對團隊進行分組，并保證小組之間設計與實現的一致性。

　　Scott指出，所謂的“架構預測”能夠提供如下價值：

　　提高生產力

　　降低技術風險

　　減少開發時間

　　增強溝通

　　可伸縮的敏捷軟件開發。

　　需要明確的是，這樣的一種架構預測方式，正好符合敏捷開發迭代的需要。在項目開發早期，對系統整體進行一次高層次的概覽，并對關鍵業務需求進行甄別與分析，劃分合理的系統模塊，有助于在迭代開發中為團隊成員建立一個統一的標準與目標。而在每次迭代過程中，團隊就可以對本次迭代期間的功能進行深入的架構建模，然后通過TDD充分理解需求，對模塊的細節進行設計與實現。這是敏捷架構設計的核心操作原理，它與敏捷開發原則是一脈相承的。