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

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

演進(jìn)的設(shè)計(jì)，同樣需要遵循架構(gòu)設(shè)計(jì)的基本準(zhǔn)則，它與計(jì)劃的設(shè)計(jì)唯一的區(qū)別是設(shè)計(jì)的目標(biāo)。演進(jìn)的設(shè)計(jì)提倡滿足客戶現(xiàn)有的需求；而計(jì)劃的設(shè)計(jì)則需要考慮未來(lái)的功能擴(kuò)展。演進(jìn)的設(shè)計(jì)推崇盡快地實(shí)現(xiàn)，追求快速確定解決方案，快速編碼以及快速實(shí)現(xiàn)；而計(jì)劃的設(shè)計(jì)則需要考慮計(jì)劃的周密性，架構(gòu)的完整性并保證開(kāi)發(fā)過(guò)程的有條不紊。

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

當(dāng)架構(gòu)為并行的多個(gè)團(tuán)隊(duì)所共享時(shí)，計(jì)劃式架構(gòu)設(shè)計(jì)就具有實(shí)踐意義，在子團(tuán)隊(duì)開(kāi)始工作之前，這種計(jì)劃式設(shè)計(jì)頗有效用（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）。

　　書中還寫道：（對(duì)于多團(tuán)隊(duì)開(kāi)發(fā)而言）計(jì)劃式架構(gòu)定義了高層的組件與連接器，并與局部的設(shè)計(jì)相匹配，而子團(tuán)隊(duì)則設(shè)計(jì)這些組件與連接器的內(nèi)部模型。架構(gòu)常常會(huì)保證整體的不變量與設(shè)計(jì)決策，例如建立并發(fā)策略、連接器的標(biāo)準(zhǔn)集、分配高層職責(zé)或定義某些局部的質(zhì)量屬性場(chǎng)景（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）。

　　至于最小計(jì)劃設(shè)計(jì)，則介乎于演進(jìn)式設(shè)計(jì)與計(jì)劃式設(shè)計(jì)之間。支持這種設(shè)計(jì)的人認(rèn)為：如果完全采取演進(jìn)式設(shè)計(jì)，可能會(huì)使得設(shè)計(jì)走向死胡同；而計(jì)劃式設(shè)計(jì)又非常難，因?yàn)槭孪葘?duì)系統(tǒng)并沒(méi)有全面的了解，可能導(dǎo)致設(shè)計(jì)錯(cuò)誤。在2002年 Bill Venners 對(duì) Martin Fowler 的采訪中，Martin Fowler 認(rèn)為，最合理的分配是20%的計(jì)劃式設(shè)計(jì)，80%的演進(jìn)式設(shè)計(jì)（I think 80 percent of the time evolutionary design works for me as well. ）。在 George 的書中，作者認(rèn)為需要權(quán)衡計(jì)劃式與演進(jìn)式設(shè)計(jì)。一種做法是在項(xiàng)目初期進(jìn)行計(jì)劃式設(shè)計(jì)，確保架構(gòu)能夠處理最大的風(fēng)險(xiǎn)。之后，就可以通過(guò)局部的設(shè)計(jì)來(lái)應(yīng)對(duì)需求的變化，或者采用演進(jìn)式設(shè)計(jì)，通過(guò)推行重構(gòu)、測(cè)試驅(qū)動(dòng)設(shè)計(jì)與持續(xù)集成對(duì)架構(gòu)進(jìn)行演化。

　　整體而言，這三種方式的設(shè)計(jì)各有優(yōu)劣，我們應(yīng)根據(jù)具體的場(chǎng)景，具體的項(xiàng)目，具體的團(tuán)隊(duì)進(jìn)行針對(duì)性地分析。應(yīng)該把握“因地制宜”的原則，認(rèn)識(shí)到不同的項(xiàng)目需要不同的設(shè)計(jì)方式。對(duì)于不同的開(kāi)發(fā)團(tuán)隊(duì)，做出的選擇也會(huì)不同。例如，如果開(kāi)發(fā)團(tuán)隊(duì)精于重構(gòu)、測(cè)試驅(qū)動(dòng)設(shè)計(jì)，并能很好地實(shí)施持續(xù)集成，就可以考慮采用演進(jìn)式設(shè)計(jì)或最小計(jì)劃設(shè)計(jì)。當(dāng)然，就我個(gè)人的意見(jiàn)，比較傾向于 Minimal planned design 。至于它在演進(jìn)式設(shè)計(jì)與計(jì)劃式設(shè)計(jì)之前的權(quán)衡，不必完全照搬 Martin Fowler 給出的比例。

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

　　文章以及上圖所表達(dá)出來(lái)的含義是：傳統(tǒng)的瀑布式采取事先設(shè)計(jì)的做法，可以認(rèn)為是計(jì)劃式設(shè)計(jì)；敏捷方法學(xué)傾向于演進(jìn)式設(shè)計(jì)；處于其中的RUP則更像是前面提到的最小計(jì)劃設(shè)計(jì)。文中主要還是關(guān)注我們?cè)诩軜?gòu)過(guò)程中如何做到架構(gòu)的“just enough”。事實(shí)上，這一觀點(diǎn)在 George Fairbank s的著作 Just enough software architecture 中被反復(fù)提到，要做到這一點(diǎn)，就需要采用風(fēng)險(xiǎn)驅(qū)動(dòng)模型（Risk-Driven Model）。RDM的架構(gòu)步驟分為三步：

1. 識(shí)別風(fēng)險(xiǎn)并進(jìn)行優(yōu)先級(jí)排列
2. 選擇并應(yīng)用相關(guān)技術(shù)
3. 評(píng)估風(fēng)險(xiǎn)是否降低

　　其實(shí)風(fēng)險(xiǎn)驅(qū)動(dòng)模型的三個(gè)步驟很容易理解，關(guān)鍵是我們應(yīng)該如何識(shí)別風(fēng)險(xiǎn)，如何排列優(yōu)先級(jí)，又該如何確定解決或控制風(fēng)險(xiǎn)的技術(shù)，并進(jìn)行合理地評(píng)估，這是風(fēng)險(xiǎn)驅(qū)動(dòng)模型的難點(diǎn)。我認(rèn)為RDM帶來(lái)的益處在于它給出了一個(gè)非常具有實(shí)踐意義的驅(qū)動(dòng)原則與方法，它告訴架構(gòu)師，當(dāng)我們?cè)趯?duì)系統(tǒng)進(jìn)行架構(gòu)時(shí)，需要從一開(kāi)始就要重視風(fēng)險(xiǎn)，例如系統(tǒng)的安全性、可伸縮性、安全等諸多與質(zhì)量屬性有關(guān)的技術(shù)風(fēng)險(xiǎn)。個(gè)人認(rèn)為：風(fēng)險(xiǎn)驅(qū)動(dòng)加上場(chǎng)景驅(qū)動(dòng)，以及技術(shù)約束，就等于敏捷架構(gòu)。大體如下圖所示：

　　風(fēng)險(xiǎn)驅(qū)動(dòng)主要用于處理質(zhì)量屬性相關(guān)的架構(gòu)內(nèi)容，而場(chǎng)景驅(qū)動(dòng)則用于處理與功能需求相關(guān)的架構(gòu)內(nèi)容，而技術(shù)約束則是架構(gòu)層面，可能是產(chǎn)品線、環(huán)境等能夠?qū)ο到y(tǒng)架構(gòu)產(chǎn)生直接影響的約束因素。至于敏捷架構(gòu)的目標(biāo)，就是設(shè)計(jì)恰如其分的架構(gòu)。

it知識(shí)庫(kù)：設(shè)計(jì)恰如其分的架構(gòu)，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。