2019年8月，國內(nèi)出版了[美] 尼爾 · 福特 / [美] 麗貝卡 · 帕森斯 / [澳] 帕特里克 · 柯撰寫的《演進(jìn)式架構(gòu)》一書，英文版在2017年10月出版。
對(duì)演進(jìn)式架構(gòu)有如下這樣的關(guān)鍵說法：An evolutionary architecture supports incremental, guided change as a first principle across multiple dimensions.
大體翻譯為“演進(jìn)式架構(gòu)支持增量式并且引導(dǎo)式的變更，把它作為跨多維度的第一原則。“
此書識(shí)別了如下3個(gè)要素：
Incremental change -主要包含兩大部分，一個(gè)是軟件是如何增量構(gòu)建，一個(gè)是它們是如何部署
Guided change with fitness functions - 用來指導(dǎo)如何進(jìn)行tradeoff來滿足選中的capability
Appropriate coupling - 需要根據(jù)不同的場景來進(jìn)行取舍耦合度，以最小的代價(jià)提供最好的收益而允許適度耦合。
本文第1版雖然寫在《演進(jìn)式架構(gòu)》一書之前，但正好與此書契合，本文描述重點(diǎn)在于演進(jìn)，通過以下方面來說明“演進(jìn)”的架構(gòu)。
1， 架構(gòu)的范圍
2， 初次架構(gòu)
3， 架構(gòu)文檔
4， 迭代中的架構(gòu)
5， 推遲決策的架構(gòu)
架構(gòu)這詞起源于建筑領(lǐng)域，被延伸使用到了包括軟件領(lǐng)域的其它諸多領(lǐng)域?，F(xiàn)在只看軟件領(lǐng)域，就存在了許多種架構(gòu)。我們常常會(huì)遇到不同形式的架構(gòu)說法，比如企業(yè)架構(gòu)、系統(tǒng)架構(gòu)、信息架構(gòu)、應(yīng)用架構(gòu)、實(shí)現(xiàn)架構(gòu)、基礎(chǔ)設(shè)施架構(gòu)等。幾乎每種類型的架構(gòu)都圈了所覆蓋的架構(gòu)范圍，而且都有擴(kuò)大“地盤”的沖動(dòng)。眼下，軟件業(yè)界并沒有相互形式間的協(xié)定，導(dǎo)致對(duì)軟件架構(gòu)同一詞語的不同理解。軟件架構(gòu)考慮的范圍隨著不同項(xiàng)目、不同團(tuán)隊(duì)、不同系統(tǒng)，甚至于不同的時(shí)間段而不同。
對(duì)比原來常用的基本設(shè)計(jì)和詳細(xì)設(shè)計(jì)，架構(gòu)一般不包含傳統(tǒng)的“詳細(xì)設(shè)計(jì)”，也不完全包含“基本設(shè)計(jì)”，而更加接近于“High Level Design”。一般而言。架構(gòu)范圍不包括需求細(xì)節(jié)、用戶交互細(xì)節(jié)、類的細(xì)節(jié)。
因此，對(duì)于特定團(tuán)隊(duì)考慮進(jìn)行架構(gòu)時(shí)，值得首先就架構(gòu)的范圍進(jìn)行討論，并達(dá)成初步的共識(shí)。當(dāng)然架構(gòu)范圍并不是從第一次達(dá)成共識(shí)后就不再變化，在架構(gòu)演進(jìn)時(shí)，團(tuán)隊(duì)能夠就架構(gòu)范圍進(jìn)行調(diào)整。
架構(gòu)的范圍并沒有標(biāo)準(zhǔn)答案，以下是對(duì)于架構(gòu)考慮范圍的推薦，最推薦的給5顆星，其次4、3、2。
· 支持的操作系統(tǒng)，比方 win7, Redhat9 ☆☆☆☆☆
· 支持的數(shù)據(jù)庫 比方Oracle, DB2, Mysql ☆☆☆☆☆
· 支持的瀏覽器（假設(shè)是有Brower訪問的）☆☆☆☆☆
· 依賴的運(yùn)行時(shí)環(huán)境 --比方Java, Silverlight ☆☆☆☆☆
· 依賴的中間件--- 比方Java容器，tomcat, websphere ☆☆☆☆☆
· 依賴的核心構(gòu)件或者Frame, 比方springboot，struts, hibernate, 自己定義的構(gòu)件 ☆☆☆☆☆
· 層次劃分，比方典型三層架構(gòu)、多層架構(gòu)，前后端分離 ☆☆☆☆
· 識(shí)別進(jìn)程，畫部署圖 ☆☆☆☆☆
· 劃分組件，畫組件圖 ☆☆☆☆☆
· 開發(fā)語言 比方c#, java, c++ ☆☆☆☆☆
· 開發(fā)所用的工具 比方IDE，報(bào)表設(shè)計(jì)器 ☆☆☆☆
· 重要組件間的接口 ☆☆☆☆
· 核心類的設(shè)計(jì) ☆☆☆
· 數(shù)據(jù)庫設(shè)計(jì) ☆☆☆
· 核心流程的說明 ☆☆
· 部分核心類的類圖 ☆☆
· 特別的性能要求帶來的考慮 ☆☆☆☆
· 特別的可恢復(fù)性要求帶來的考慮 ☆☆☆
· 特別的信息安全要求帶來的考慮 ☆☆☆
在系統(tǒng)早期，比方某系統(tǒng)的第0次迭代，或者重大升級(jí)，新接手某系統(tǒng)，需要進(jìn)行初次架構(gòu)，需要理解系統(tǒng)的現(xiàn)狀、范圍、特征。
在架構(gòu)關(guān)注的范圍內(nèi)，哪些因素是硬性限制條件？哪些因素是可變限制條件？哪些因素是需要考慮解決的問題？
一般地，全新開發(fā)系統(tǒng)的限制條件比較少，需要考慮解決的問題比較多，往往面臨“艱難的選擇”，當(dāng)然這也是體現(xiàn)架構(gòu)價(jià)值的地方。
所開發(fā)的系統(tǒng)將或者已經(jīng)存在于環(huán)境中，那么其環(huán)境必定影響架構(gòu)，所以需要考慮 “環(huán)境中的架構(gòu)”?；旧?，環(huán)境決定了系統(tǒng)執(zhí)行的范圍，這些又約定和限制了架構(gòu)。影響架構(gòu)的環(huán)境因素包括架構(gòu)所支持的商務(wù)環(huán)境，系統(tǒng)涉眾群，內(nèi)部技術(shù)限制（比如須要符合組織標(biāo)準(zhǔn)）。和外部技術(shù)限制（比如對(duì)外部系統(tǒng)的接口或遵守外部規(guī)則的標(biāo)準(zhǔn)）。
在此期間，鼓勵(lì)召開架構(gòu)的頭腦風(fēng)暴會(huì)議，討論系統(tǒng)的功能、性能等等特征，并思考實(shí)現(xiàn)這些特征的高層設(shè)計(jì)策略，甄別可行地技術(shù)策略。
依據(jù)這些了解、討論和思考，形成初始的架構(gòu)文檔。
特別再次值得反復(fù)說明的是：多數(shù)的架構(gòu)是在已有軟件或系統(tǒng)上進(jìn)行的。原有軟件或系統(tǒng)將帶來原有的架構(gòu)，這并不意味著新項(xiàng)目能夠不再考慮架構(gòu)。原有的架構(gòu)可能不再適應(yīng)當(dāng)前的情況，而恰恰是須要改進(jìn)的地方。原有的架構(gòu)或許非常好，不必改動(dòng)，新開發(fā)僅僅須要在其指定的架構(gòu)下按部進(jìn)行就可以。原有的架構(gòu)總體可行，局部需要調(diào)整，這樣的判斷本身就是架構(gòu)。
在起草初始的架構(gòu)文檔時(shí)，值得充分理解并復(fù)用原有架構(gòu)方面的文檔。
不管利用原有文檔，還是新寫，應(yīng)當(dāng)形成一套架構(gòu)文檔，說明團(tuán)隊(duì)架構(gòu)范圍內(nèi)所關(guān)注的內(nèi)容。這一套架構(gòu)文檔要得到配置管理。
這套架構(gòu)文檔的典型組成
1， 核心架構(gòu)文檔（必需）
2， 接口文檔（對(duì)外接口，必需）
3。 模塊或子系統(tǒng)架構(gòu)（可選）
4， 其他補(bǔ)充說明（可選）
在迭代進(jìn)行中，架構(gòu)文檔應(yīng)當(dāng)始終保持是一套文件，這套文件隨著種種新情況、變更而得到演進(jìn)。但始終保持其全局性和及時(shí)性。
最值得注意的地方是要避免出現(xiàn)把新增改動(dòng)的內(nèi)容寫入特定版本號(hào)的架構(gòu)文檔，這樣會(huì)導(dǎo)致組合多個(gè)文件才干反映架構(gòu)總體情況。詳細(xì)而言，避免以下情況：
假設(shè)在第2個(gè)迭代結(jié)束后已經(jīng) 形成了 ABC架構(gòu)文檔，在第3個(gè)迭代時(shí)，當(dāng)中某部分有重要改動(dòng)。 團(tuán)隊(duì)為了明白這些是第3迭代的任務(wù)。也為方便的閱讀第3迭代的架構(gòu)，把這部分改動(dòng)另寫為ABC第3迭代架構(gòu)文件。在第4個(gè)迭代時(shí)。又有某部分須要新增改動(dòng)，然后有出現(xiàn)了ABC第4迭代架構(gòu)文件，依此類推。到第10個(gè)迭代時(shí)，須要閱讀全部前面的架構(gòu)文件才干了解全局，而不再有一份核心架構(gòu)文檔就能反映全局。短期迭代的方便處理將損害長期的架構(gòu)演進(jìn)。
因此。演進(jìn)的架構(gòu)必須利用版本控制工具，以前推薦了諸如CVS，SVN，ClearCase等來管理架構(gòu)文檔，最新推薦帶有自動(dòng)版本記錄的線上化工具，比如Confluence，騰訊文檔等等。線上化工具支持多人線上協(xié)同，使用效率遠(yuǎn)遠(yuǎn)超過了把word文件存放到Git。
通過這類工具的幫助，在不論什么時(shí)間點(diǎn)，都能及時(shí)地展現(xiàn)的一套架構(gòu)文檔，也能追隨到老版本，還能比對(duì)前后差異。為增量式演進(jìn)提供了巨大便利，或者說這是增量式演進(jìn)所必需的。
在迭代開發(fā)當(dāng)中，在每一個(gè)迭代的前期甚至提前一個(gè)迭代，結(jié)合最新業(yè)務(wù)需要來考慮對(duì)于架構(gòu)的影響。
如果對(duì)于原有架構(gòu)文檔有變化，就應(yīng)當(dāng)修訂架構(gòu)文檔。在演進(jìn)中，對(duì)于架構(gòu)最常見的兩大影響是
1，模塊的改動(dòng)和新增，包括外接新系統(tǒng)；
2，因?yàn)闀r(shí)間推移所帶來的容量方面的問題，一般最突出的是性能問題。值得密切注意模塊之間的交互。
推薦提問：
1， 這個(gè)迭代是否要新增模塊？
2， 是否對(duì)已經(jīng)存在的模塊有改動(dòng)，模塊之間的交互是否有變化？
3。 與其他系統(tǒng)的交互是否有變化？是否須要與新系統(tǒng)通訊？
4。 能否夠支持容量方面的情況？比如訪問量？比方硬盤容量？帶寬？CPU？
另外可能的變化是團(tuán)隊(duì)對(duì)于架構(gòu)范圍的理解可能變化，依據(jù)變化后的架構(gòu)范圍理解，增補(bǔ)架構(gòu)文檔的內(nèi)容。
值得再強(qiáng)調(diào)的是迭代中不僅僅可以對(duì)架構(gòu)范圍進(jìn)行調(diào)整，也可以對(duì)之前的架構(gòu)決策進(jìn)行調(diào)整，這就是演進(jìn)，而不是如同建筑的架構(gòu)不可調(diào)整。
還有一個(gè)因素值得強(qiáng)調(diào)-迭代的顆粒度，哪怕采用長達(dá)4周的迭代，對(duì)比原來基本設(shè)計(jì)+詳細(xì)設(shè)計(jì)做法對(duì)應(yīng)的時(shí)間顆粒度，也是有幾倍的差距。原來講究基本設(shè)計(jì)+詳細(xì)設(shè)計(jì)的情況下，對(duì)應(yīng)交付版本間隔長達(dá)4個(gè)月以上，甚至更久。
當(dāng)下常見的迭代長度是2到3周，領(lǐng)先企業(yè)有采用1周迭代周期，也有無迭代做法，交付版本間隔常見也在2到3周，領(lǐng)先企業(yè)更加快。 在這樣情況下，有一個(gè)形象的比喻是給行駛中的汽車換個(gè)輪子，不會(huì)再有安排一個(gè)長達(dá)3周的設(shè)計(jì)階段來做設(shè)計(jì)。
因此原來基本設(shè)計(jì)+詳細(xì)設(shè)計(jì)的做法不能簡單放入短迭代開發(fā)，需要經(jīng)過裁剪后才能很好的指導(dǎo)迭代開發(fā)。
在演進(jìn)的架構(gòu)中值得推遲決策，推遲決策并非指到最后才決定做什么，而是要盡量推遲決策，以更靈活的應(yīng)對(duì)不確定性。
當(dāng)出現(xiàn)架構(gòu)決策時(shí)，考慮例如以下提問：
· 當(dāng)前必須制定這個(gè)決策嗎？
· 能夠安全地推遲這一決策嗎？
· 能做些什么使決策可逆？
· 能否夠先進(jìn)行些嘗試，以幫助決策？
在演進(jìn)的架構(gòu)下，也為決策的推遲提供了便利。當(dāng)前迭代涉及的架構(gòu)問題是須要立即給出方案的，對(duì)于興許的架構(gòu)問題是有機(jī)會(huì)推遲決策的。當(dāng)然這里是有長期考慮和短期考慮的權(quán)衡，并非說演進(jìn)的架構(gòu)下僅僅須要考慮本迭代的架構(gòu)問題。但也不是說須要考慮全部興許迭代的架構(gòu)問題。
對(duì)比傳統(tǒng)架構(gòu)設(shè)計(jì)，往往假設(shè)架構(gòu)有長時(shí)間指導(dǎo)意義，比較穩(wěn)定，因此需要慎重，花費(fèi)專門大段時(shí)間來進(jìn)行架構(gòu)設(shè)計(jì)。
在延遲決策的架構(gòu)策略下，恰恰得到相反的論斷：在剛剛開始時(shí)，沒有必要安排超過迭代周期的、專門的架構(gòu)設(shè)計(jì)階段或迭代。在演進(jìn)的背景下，預(yù)先花費(fèi)大量時(shí)間的所謂設(shè)計(jì)階段是多余的。
因?yàn)檫@個(gè)世界變化太快，提早的架構(gòu)往往想得太美，不如采用演進(jìn)的做法，在迭代增量當(dāng)中逐漸追求并且逼近完美。
另外值得說明的一點(diǎn)是推遲決策不是等到代碼寫得差不多了，再來補(bǔ)架構(gòu)設(shè)計(jì)文檔！如果是代碼寫得差不多了，那只能是為了文檔合規(guī)要求而寫文檔，喪失了架構(gòu)設(shè)計(jì)的意義。架構(gòu)應(yīng)當(dāng)在前面指導(dǎo)代碼編寫，也敢于留出空白讓一線程序員發(fā)揮。
---全文玩---
聯(lián)系客服
