Thoughtworks 的 Sam Newman 在 Mythoughtworks 的 Software Development 小組中給出了 Evolutionary Architecture 的一些資源。其中一個是 Martin Fowler 與 Rebecca Parsons 在 QCon SF 2009 的一次演講，題目為 Agilists and Architects: Allies not Adversaries Presentation 。演講主要談到了在敏捷方法中的架構活動（在Martin Fowler的演講中，播放了《黑客帝國》中的一個片段，很有意思）。另一個資源則是同樣作為 thoughtworker 的 Neal Ford 在 IBM developerWorks 發表的 Evelutionary Architecture and Emergent Design(演進架構與緊急設計)系列。這是很棒的一個講解演進架構的系列文章，談到了TDD、代碼復用、連貫接口、DSL、重構、慣用法模式、指標等與演進架構和緊急設計有關的內容。

　　事實上，關于演進式架構已經是老調重彈。Martin Fowler 在2004年發表的文章 Is Design Dead 中談到了計劃式設計與演進式設計之間的區別。在我的書《軟件設計精要與模式》第一章中，也簡單闡述了我對二者的理解。書中給出了一個建筑學的隱喻：拙政園與周莊。拙政園是計劃式設計的典范，沒有詳盡的計劃，也許就不會有疏朗典雅的拙政園。周莊卻并非某人在某一時刻靈感捕捉后的設計成果，而是經歷了數百年的歷史滄桑，漸進地增添與更替各種建筑，最后形成現在這般靈秀的水鄉風貌。在書中，我寫道：

演進的設計，同樣需要遵循架構設計的基本準則，它與計劃的設計唯一的區別是設計的目標。演進的設計提倡滿足客戶現有的需求；而計劃的設計則需要考慮未來的功能擴展。演進的設計推崇盡快地實現，追求快速確定解決方案，快速編碼以及快速實現；而計劃的設計則需要考慮計劃的周密性，架構的完整性并保證開發過程的有條不紊。

　　最近正在閱讀 George Fairbanks 的著作 Just Enough Software Architecture ，書中除了計劃式設計和演進式設計之外，還提到了第三種設計：Minimal planned design（最小計劃設計），這算是一種中庸之道的選擇。書中認為，演進式設計需要與一些敏捷實踐配合，包括重構、測試驅動設計與持續集成（evolutionary design must be paired with supporting practices like refactoring, test-driven design, and continuous integration.）George 認為計劃式設計背后隱藏的思想是在構造開始之前，制訂的計劃可以設計出很好的細節（The general idea behind planned design is that plans are worked out in great detail before construction begins）。他還提到：

當架構為并行的多個團隊所共享時，計劃式架構設計就具有實踐意義，在子團隊開始工作之前，這種計劃式設計頗有效用（Planned architecture design is also practical when an architecture is shared by many teams working in parallel, and therefore useful to know before the sub-teams start working）。

　　書中還寫道：（對于多團隊開發而言）計劃式架構定義了高層的組件與連接器，并與局部的設計相匹配，而子團隊則設計這些組件與連接器的內部模型。架構常常會保證整體的不變量與設計決策，例如建立并發策略、連接器的標準集、分配高層職責或定義某些局部的質量屬性場景（a planned architecture that define the top-level components and connectors can be paired with local designs, where sub-teams design the internal models of the components and connectors. The architecture usually insists on some overall invariants and design decisions, such as setting up a concurrency policy, a standard set of connectors, allocating high-level responsibilities, or defining some localized quality attribute scenarios）。

　　至于最小計劃設計，則介乎于演進式設計與計劃式設計之間。支持這種設計的人認為：如果完全采取演進式設計，可能會使得設計走向死胡同；而計劃式設計又非常難，因為事先對系統并沒有全面的了解，可能導致設計錯誤。在2002年 Bill Venners 對 Martin Fowler 的采訪中，Martin Fowler 認為，最合理的分配是20%的計劃式設計，80%的演進式設計（I think 80 percent of the time evolutionary design works for me as well. ）。在 George 的書中，作者認為需要權衡計劃式與演進式設計。一種做法是在項目初期進行計劃式設計，確保架構能夠處理最大的風險。之后，就可以通過局部的設計來應對需求的變化，或者采用演進式設計，通過推行重構、測試驅動設計與持續集成對架構進行演化。

　　整體而言，這三種方式的設計各有優劣，我們應根據具體的場景，具體的項目，具體的團隊進行針對性地分析。應該把握“因地制宜”的原則，認識到不同的項目需要不同的設計方式。對于不同的開發團隊，做出的選擇也會不同。例如，如果開發團隊精于重構、測試驅動設計，并能很好地實施持續集成，就可以考慮采用演進式設計或最小計劃設計。當然，就我個人的意見，比較傾向于 Minimal planned design 。至于它在演進式設計與計劃式設計之前的權衡，不必完全照搬 Martin Fowler 給出的比例。

　　在Sam Newman給出的演進式架構資源中，還有一篇 coding the architecture 的文章 Just enough architecture 。這篇文章則從方法學的角度分析來如何獲得恰如其分的架構。這是文章中非常漂亮的一幅圖：

　　文章以及上圖所表達出來的含義是：傳統的瀑布式采取事先設計的做法，可以認為是計劃式設計；敏捷方法學傾向于演進式設計；處于其中的RUP則更像是前面提到的最小計劃設計。文中主要還是關注我們在架構過程中如何做到架構的“just enough”。事實上，這一觀點在 George Fairbank s的著作 Just enough software architecture 中被反復提到，要做到這一點，就需要采用風險驅動模型（Risk-Driven Model）。RDM的架構步驟分為三步：

1. 識別風險并進行優先級排列
2. 選擇并應用相關技術
3. 評估風險是否降低

　　其實風險驅動模型的三個步驟很容易理解，關鍵是我們應該如何識別風險，如何排列優先級，又該如何確定解決或控制風險的技術，并進行合理地評估，這是風險驅動模型的難點。我認為RDM帶來的益處在于它給出了一個非常具有實踐意義的驅動原則與方法，它告訴架構師，當我們在對系統進行架構時，需要從一開始就要重視風險，例如系統的安全性、可伸縮性、安全等諸多與質量屬性有關的技術風險。個人認為：風險驅動加上場景驅動，以及技術約束，就等于敏捷架構。大體如下圖所示：

　　風險驅動主要用于處理質量屬性相關的架構內容，而場景驅動則用于處理與功能需求相關的架構內容，而技術約束則是架構層面，可能是產品線、環境等能夠對系統架構產生直接影響的約束因素。至于敏捷架構的目標，就是設計恰如其分的架構。

it知識庫：設計恰如其分的架構，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。