在敏捷開發(fā)中使用演進式架構設計

申請免費試用、咨詢電話：400-8352-114

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

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

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

敏捷模型驅(qū)動開發(fā)的生命周期如下圖所示：

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 提高生產(chǎn)力

2. 降低技術風險

3. 減少開發(fā)時間

4. 增強溝通

5. 可伸縮的敏捷軟件開發(fā)。

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