**：
在敏捷開發中採用演進式架構設計
在敏捷開發過程中，我們還需要對系統架構進行設計嗎?事實上，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充分理解需求，對模組的細節進行設計與實現。這是敏捷架構設計的核心操作原理，它與敏捷開發原則是一脈相承的。
在敏捷開發中採用演進式架構設計
在敏捷開發過程中，我們還需要對系統架構進行設計嗎？事實上，martin fowler在 is design dead?一文中已經給出了答案，那就是我們同樣不能忽略對系統架構的設計。與計畫性的設計 planned design 不同，我們需要演進式的設計 evolutionary design 在敏捷...
演進式架構設計在敏捷開發中的使用
在敏捷開發過程中，我們還需要對系統架構進行設計嗎?事實上，martin fowler 在 is design dead?一文中已經給出了答案，那就是我們同樣不能忽略對系統架構的設計。與計畫性的設計 planned design 不同，我們需要演進式的設計 evolutionary design ib...
敏捷開發智慧型敏捷系列之三 做不做架構設計？
這是敏捷開發智慧型敏捷的第三篇。之一，之二，之三，之四，之五，之六 甲 敏捷不應該寫架構設計，應該每個迭代都是相同的，才能達到自相似性 這是ken shweber說的 乙 如果不寫架構設計，很容易返工，早晚還得重來。甲 大不了重構，這是敏捷開發重要的實踐。乙 重構？重構的成本很高的，做幾個迭代，後面...