演進(jìn)式設(shè)計是一種理念，它曾經(jīng)顛覆過傳統(tǒng)笨拙的計劃式設(shè)計，如今，它依舊煥發(fā)著生命力，但我們不能以靜止的眼光去看待它，而應(yīng)該嘗試著引入一些新的方法、框架乃至技術(shù)。

? ?

說起來，所謂Evolutionary Design已經(jīng)是老生常談了。早在2004年，Martin Fowler在文章Is Design Dead中就深刻地比較了計劃式設(shè)計與演進(jìn)式設(shè)計，至今閱讀這篇文章，對于理解敏捷和演進(jìn)式設(shè)計依舊振聾發(fā)聵。我在文章設(shè)計恰如其分的架構(gòu)中，也算得上是旁征博引地闡述了諸多與演進(jìn)式設(shè)計相關(guān)的理念，例如Neal Ford提出的Emergent Design，George Fairbanks提出的Risk Driven Design，以及Minimal planned design。

然而，有多少人在遵循著Evolutionary Design的理念進(jìn)行著架構(gòu)的規(guī)劃與設(shè)計呢？如果說，架構(gòu)過程確定無疑地需要不斷地演進(jìn)，但該如何演進(jìn)，如何更好地演進(jìn)，依舊是一個巨大的謎題。

Neal Ford提出的諸如發(fā)現(xiàn)模式、重構(gòu)、測試驅(qū)動開發(fā)等方法，更多地還是停留在微觀架構(gòu)的層面。而在多數(shù)的架構(gòu)設(shè)計過程中，更多地是基于質(zhì)量屬性，前瞻地去選擇架構(gòu)風(fēng)格（抑或架構(gòu)模式），并參照一些最佳實踐結(jié)合自己的場景去驅(qū)動出物理架構(gòu)與邏輯架構(gòu)。若完全寄情于Last Responsible Time，期待著通過對架構(gòu)重構(gòu)讓已有軟件系統(tǒng)煥然一新，畢竟代價太大，對架構(gòu)師的能力也要求太高。

正如Martin Fowler對架構(gòu)的定義：

架構(gòu)是重要的事物，無論它是什么。架構(gòu)是以后很難更改的內(nèi)容。

既然很難更改，我們?yōu)楹尾荒芤货矶?#xff1f;然而，Neal Ford又告訴我們：未來是不可預(yù)測的。于是之，我們并不能以無知的未來妝點(diǎn)當(dāng)下，否則會導(dǎo)致設(shè)計過度，甚至南轅北轍。雖然一路向北，終究能返歸南方，可惜路漫漫其修遠(yuǎn)兮，沒有人愿意等待，也不值得等待。

在Agile China 2013年，我在ThoughtWorks的同事Scott Shaw與賈陽聯(lián)袂演出了一臺戲，戲名喚作Evolving Architecture For Change，以一個真實案例闡釋我們?nèi)绾窝葸M(jìn)客戶系統(tǒng)的架構(gòu)。演講從Evolving Path、Technical Enables與Culture Enables三個方面全面細(xì)致地介紹了架構(gòu)的演進(jìn)之路。概而言之，用到的方法與理念包括：

• 通過Bounded Context識別Domain Service
  

• 基于RESTful的Micro Service架構(gòu)

• 自動化的Consumer Driven Contract Test

• 自動化部署與部署流水線(Deployement Pipeline)

• 組建特性團(tuán)隊(Feature Team)

• 重視交流，將架構(gòu)師視為Facilitator，通過可視化手段引導(dǎo)設(shè)計

演進(jìn)之前的架構(gòu)是一個簡單分割的分布式架構(gòu)，Front End面向客戶的用戶，而Office End則面向業(yè)務(wù)人員和系統(tǒng)管理者。整個系統(tǒng)的模塊邊界非常模糊，集成復(fù)雜，代碼庫龐大而混亂，存在大量重復(fù)代碼。

采用上述方法對系統(tǒng)架構(gòu)進(jìn)行演進(jìn)，最終形成了如下圖所示的基于RESTful的圍繞Domain Service為中心的類微服務(wù)架構(gòu)：

然而，嚴(yán)格意義上講，這個案例的架構(gòu)演進(jìn)屬于針對已有系統(tǒng)（或遺留系統(tǒng)）架構(gòu)進(jìn)行重構(gòu)的范疇，而非從頭開始搭建架構(gòu)的演進(jìn)式設(shè)計。

最近讀到Joshua Kerievsky的文章Evolutionary Design，他提倡架構(gòu)設(shè)計從Primitive Whole開始，勿求功能做到最深最全，而是以“廣度優(yōu)先”的算法思想在最初的設(shè)計中覆蓋整個系統(tǒng)的全部組成部分。如題圖所示的吉他設(shè)計。

迭代1設(shè)計的吉他根本不可用，但基本的組成元素已經(jīng)初具模型，雖然它不能工作，但任何人看到這個模型，也不會認(rèn)為它是小提琴或者二胡。

如此設(shè)計的好處在于可以提前發(fā)現(xiàn)團(tuán)隊協(xié)作與組件集成的風(fēng)險。因為前期迭代的功能鋪得極廣，就像八爪魚一般延伸到了系統(tǒng)的每一枝節(jié)（這些枝節(jié)卻沒有一片樹葉），雖然極度粗糙簡陋，但團(tuán)隊已經(jīng)可以開始協(xié)作開發(fā)，系統(tǒng)的集成點(diǎn)也被提前發(fā)現(xiàn)了。

協(xié)作問題是管理風(fēng)險，集成問題是技術(shù)風(fēng)險，二者都是導(dǎo)致軟件開發(fā)延期的主要魁首。雖然只是邁出了第一步，但這一步邁得扎實，邁得穩(wěn)當(dāng)，之后就可以以更加穩(wěn)健步伐前進(jìn)，庶幾實現(xiàn)“較少修改”的架構(gòu)。

我發(fā)現(xiàn)這個階段是引入Alistair Cockburn六邊形架構(gòu)(Hexagonal Architecture)的最佳時期。

運(yùn)用六邊形架構(gòu)可以有效地識別系統(tǒng)關(guān)注點(diǎn)，從架構(gòu)層面（全局視角）設(shè)計，暫時可以不考慮實現(xiàn)細(xì)節(jié)。六邊形架構(gòu)這種內(nèi)外分離的方式，可以有效地把系統(tǒng)的核心領(lǐng)域與邊界外的基礎(chǔ)設(shè)施隔離開，從而形成一種獨(dú)立于框架，易于測試，與外部代理、UI以及數(shù)據(jù)庫無關(guān)的應(yīng)用架構(gòu)（符合Robert Martin提出的Clean Architecture）。與演進(jìn)式設(shè)計結(jié)合起來，可以很好地幫助我們識別集成點(diǎn)，以更廣而非更深地視角俯瞰系統(tǒng)架構(gòu)。

演進(jìn)式設(shè)計是一種理念，它曾經(jīng)顛覆過傳統(tǒng)笨拙的計劃式設(shè)計，如今，它依舊煥發(fā)著生命力，但我們不能以靜止的眼光去看待它，而應(yīng)該嘗試著引入一些新的方法、框架乃至技術(shù)——于是，演進(jìn)式設(shè)計這舊瓶就能裝著新酒，既散發(fā)出釅釅的酒香又不至于濃洌得熏人欲醉！

---

題圖：Joshua Kerievsky, Evolutionary Design

文學(xué)與軟件 | ，詩意地想念

? ?

長按識別二維碼

或搜索“逸言”加關(guān)注

內(nèi)容轉(zhuǎn)載自公眾號

逸言 了解更多

總結(jié)

以上是生活随笔為你收集整理的重新审视演进式设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。