提及來,所謂Evolutionary Design已是老生常談了。早在2004年,Martin Fowler在文章Is Design Dead中就深入地比較了計劃式設計與演進式設計,至今閱讀這篇文章,對於理解敏捷和演進式設計依舊振聾發聵。我在博客設計恰如其分的架構中,也算得上是旁徵博引地闡述了諸多與演進式設計相關的理念,例如Neal Ford提出的Emergent Design,George Fairbanks提出的Risk Driven Design,以及Minimal planned design。html
然而,有多少人在遵循着Evolutionary Design的理念進行着架構的規劃與設計呢?若是說,架構過程肯定無疑地須要不斷地演進,但該如何演進,如何更好地演進,依舊是一個巨大的謎題。Neal Ford提出的諸如發現模式、重構、測試驅動開發等方法,更多地仍是停留在微觀架構的層面。而在多數的架構設計過程當中,更多地是基於質量屬性,前瞻地去選擇架構風格(抑或架構模式),並參照一些最佳實踐結合本身的場景去驅動出物理架構與邏輯架構。若徹底寄情於Last Responsible Time,期待着經過對架構重構讓已有軟件系統面目一新,畢竟代價太大,對架構師的能力也要求過高。算法
正如Martin Fowler對架構的定義:數據庫
架構是重要的事物,不管它是什麼。架構是之後很難更改的內容。架構
既然很難更改,咱們爲什麼不能一蹴而就?然而,Neal Ford又告訴咱們:將來是不可預測的。因而之,咱們並不能以無知的將來妝點當下,不然會致使設計過分,甚至南轅北轍。雖然一路向北,終究能返歸南方,惋惜路漫漫其修遠兮,沒有人願意等待,也不值得等待。框架
在Agile China 2013年,我在ThoughtWorks的同事Scott Shaw與賈陽聯袂演出了一臺戲,戲名喚做Evolving Architecture For Change,以一個真實案例闡釋咱們如何演進客戶系統的架構。演講從Evolving Path、Technical Enables與Culture Enables三個方面全面細緻地介紹了架構的演進之路。概而言之,用到的方法與理念包括:分佈式
演進以前的架構是一個簡單分割的分佈式架構,Front End面向客戶的用戶,而Office End則面向業務人員和系統管理者。整個系統的模塊邊界很是模糊,集成複雜,代碼庫龐大而混亂,存在大量重複代碼。微服務
採用上述方法對系統架構進行演進,最終造成了以下圖所示的基於RESTful的圍繞Domain Service爲中心的類微服務架構:post
然而,嚴格意義上講,這個案例的架構演進屬於針對已有系統(或遺留系統)架構進行重構的範疇,而非從頭開始搭建架構的演進式設計。測試
最近讀到Joshua Kerievsky的文章Evolutionary Design,他提倡架構設計從Primitive Whole開始,勿求功能作到最深最全,而是以「廣度優先」的算法思想在最初的設計中覆蓋整個系統的所有組成部分。以下圖所示的吉他設計:架構設計
迭代1設計的吉他根本不可用,但基本的組成元素已經初具模型,雖然它不能工做,但任何人看到這個模型,也不會認爲它是小提琴或者二胡。
如此設計的好處在於能夠提早發現團隊協做與組件集成的風險。由於前期迭代的功能鋪得極廣,就像八爪魚通常延伸到了系統的每一枝節(這些枝節卻沒有一片樹葉),雖然極度粗糙簡陋,但團隊已經能夠開始協做開發,系統的集成點也被提早發現了。
協做問題是管理風險,集成問題是技術風險,兩者都是致使軟件開發延期的主要魁首。雖然只是邁出了第一步,但這一步邁得紮實,邁得妥當,以後就能夠以更加穩健步伐前進,庶幾實現「較少修改」的架構。
我發現這個階段是引入Alistair Cockburn六邊形架構(Hexagonal Architecture)的最佳時期。
運用六邊形架構能夠有效地識別系統關注點,從架構層面(全局視角)設計,暫時能夠不考慮實現細節。六邊形架構這種內外分離的方式,能夠有效地把系統的核心領域與邊界外的基礎設施隔離開,從而造成一種獨立於框架,易於測試,與外部代理、UI以及數據庫無關的應用架構(符合Robert Martin提出的Clean Architecture)。與演進式設計結合起來,能夠很好地幫助咱們識別集成點,以更廣而非更深地視角俯瞰系統架構。
演進式設計是一種理念,它曾經顛覆過傳統笨拙的計劃式設計,現在,它依舊煥發着生命力,但咱們不能以靜止的眼光去看待它,而應該嘗試着引入一些新的方法、框架乃至技術——因而,演進式設計這舊瓶就能裝着新酒,既散發出釅釅的酒香又不至於濃洌得燻人欲醉!