遠在2023年，martin fowler與rebecca parsons在qcon sf做了一次題為agilists and architects: allies not adversaries presentation的演講。演講主要討論了在敏捷方法中的架構活動。相似的話題，neal ford則提出了緊急設計的概念，並發表了名為evelutionary architecture and emergent design(演進架構與緊急設計)的系列文章。這是很棒的乙個講解演進架構的系列文章，談到了tdd、**復用、連貫介面、dsl、重構、慣用法模式、指標等與演進架構和緊急設計有關的內容。
neal ford對軟體架構的主要觀點基於如下事實：
未來是不可**的；於是，我們應該選擇在最後責任時刻（last responsible moment)去應對系統的複雜度。所謂「最後責任時刻」，即我們如果未及時採取措施，可能導致複雜度線性增加的時刻，如下圖所示：軟體設計的最終目標是獲得完整的源**；
系統的複雜度分為偶發複雜度（accidental complexity）與本質複雜度(essential complexity);
ford提出的方法就是在開發中善於發現抽象與模式，並借助測試驅動開發，利用重構去導向設計。同時，我們還可以嘗試使用一些考量**質量的工具，獲得質量指標，通過這些指標去發現問題（這些問題其實就是技術債），然後去及時解決問題。針對較難做出的架構決策，則可以利用spike方式快速得出結論，甚至是原型方案。
事實上，演進式架構這個話題已經是老調重彈。讓我們再回到2023年，martin fowler當然發表了文章is design dead。文中談到了計畫式設計與演進式設計之間的區別。這篇文章算得上是溯本清源。在2023年我自己的書《軟體設計精要與模式》中，也簡單闡述了我對二者的理解。我給出了乙個建築學的隱喻：拙政園與周莊。拙政園是計畫式設計的典範，沒有詳盡的計畫，也許就不會有疏朗典雅的拙政園。周莊卻並非某人在某一時刻靈感捕捉後的設計成果，而是經歷了數百年的歷史滄桑，漸進地增添與更替各種建築，最後形成現在這般靈秀的水鄉風貌。我在書中寫道：
演進的設計，同樣需要遵循架構設計的基本準則，它與計畫的設計唯一的區別是設計的目標。演進的設計提倡滿足客戶現有的需求；而計畫的設計則需要考慮未來的功能擴充套件。演進的設計推崇盡快地實現，追求快速確定解決方案，快速編碼以及快速實現；而計畫的設計則需要考慮計畫的周密性，架構的完整性並保證開發過程的有條不紊。2023年，我翻譯了george fairbanks的著作just enough software architecture。
書中除了計畫式設計和演進式設計之外，還提到了第三種設計：minimal planned design（最小計畫設計），這算是一種中庸之道的選擇。書中認為，演進式設計需要與一些敏捷實踐配合，包括重構、測試驅動設計與持續整合。george認為計畫式設計背後隱藏的思想是在構造開始之前，制訂的計畫可以設計出很好的細節。他還提到：
當架構為並行的多個團隊所共享時，計畫式架構設計就具有實踐意義，在子團隊開始工作之前，這種計畫式設計頗為有效。書中還寫道：（對於多團隊開發而言）計畫式架構定義了高層的元件與聯結器，並與區域性的設計相匹配，而子團隊則設計這些元件與聯結器的內部模型。架構常常會保證整體的不變數與設計決策，例如建立併發策略、聯結器的標準集、分配高層職責或定義某些區域性的質量屬性場景。
最小計畫設計，則介乎於演進式設計與計畫式設計之間。支援這種設計的人認為：如果完全採取演進式設計，可能會使得設計走向死胡同；而計畫式設計又非常難，因為事先對系統並沒有全面的了解，可能導致設計錯誤。在2023年bill venners對martin fowler的採訪中，martin fowler認為，最合理的分配是20%的計畫式設計，80%的演進式設計。在george的書中，作者認為需要權衡計畫式與演進式設計。一種做法是在專案初期進行計畫式設計，確保架構能夠處理最大的風險。之後，就可以通過區域性的設計來應對需求的變化，或者採用演進式設計，通過推行重構、測試驅動設計與持續整合對架構進行演化。
部落格coding the architecture上的一篇文章just enough architecture，從方法學的角度分析如何獲得恰如其分的架構。
文章以及上圖所表達出來的含義是：傳統的瀑布式採取事先設計的做法，可以認為是計畫式設計；敏捷方法學傾向於演進式設計；處於其中的rup則更像是前面提到的最小計畫設計。文中主要還是****在架構過程中如何做到架構的「just enough」。事實上，這一觀點在george fairbanks的著作just enough software architecture中被反覆提到，要做到這一點，就需要採用風險驅動模型（risk-driven model）。rdm的架構步驟分為三步：
其實風險驅動模型的三個步驟很容易理解，關鍵是我們應該如何識別風險，如何排列優先順序，又該如何確定解決或控制風險的技術，並進行合理地評估，這是風險驅動模型的難點。我認為rdm帶來的益處在於它給出了乙個非常具有實踐意義的驅動原則與方法，它告訴架構師，當我們在對系統進行架構時，需要從一開始就要重視風險，例如系統的安全性、可伸縮性、安全等諸多與質量屬性有關的技術風險。
整體而言，這三種方式的設計各有優劣，我們應根據具體的場景，具體的專案，具體的團隊進行針對性地分析。應該把握「因地制宜」的原則，認識到不同的專案需要不同的設計方式。對於不同的開發團隊，做出的選擇也會不同。例如，如果開發團隊精於重構、測試驅動設計，並能很好地實施持續整合，就可以考慮採用演進式設計或最小計畫設計。
我個人較傾向於minimal planned design，至於它在演進式設計與計畫式設計之前的權衡，不必完全照搬martin fowler給出的比例。參考ddd的分類，我將計畫式設計的部分規劃到戰略式設計中，此時，我可以從用例出發，引入bounded context來尋找系統的核心領域與子領域。
通過context map並結合六邊形架構，可以幫助我們識別context或者說領域之間的通訊方式與整合方式，從而獲得整個系統的分布式架構模型。運用分層架構以及六邊形架構驅動得出的port與adapter，可以幫助我們獲得整個系統的應用邏輯架構。而context自身，則可以作為業務邏輯架構的基礎。
軟體系統的質量屬性算是特殊的一部分，可以借鑑質量驅動設計或風險驅動設計，來確定滿足質量屬性的架構方案。在這個過程中，我們可以參考常用的架構風格與架構模式。例如針對大資料處理、併發處理、資源管理、分布式架構，都有許多相應的模式與風格可供我們選擇。架構風格與架構模式的選擇，會直接影響到我們的系統架構。
無論選擇何種方式，我們的設計都應該把握「恰如其分」這個原則，不做不必要的「過度工程」。這或者可以看做敏捷架構的中心原則。
讀書筆記（一）《恰如其分的軟體架構》
恰如其分的軟體架構 這本書和其他英文翻譯書一樣，並沒有太多手把手教你如何設計乙個軟體架構。但是！對於乙個工作多年的嵌入式軟體工程師，書中很多概念還是給人留下了深刻的印象！有一種 哦！我在做xx專案時，感覺就是這樣！哦！這不是就是我當時寫的那個 的樣子嗎！just enough 我看的是翻譯版的書，中...
架構的設計
為了討論和分析軟體構架，必須首先定義構架表示方式，即描述構架重要方面的方式。在 rational unified process 中，軟體構架文件記錄有這種描述。架構描述語言 adl 用於描述軟體的體系架構。已有多種架構描述語言，如 wright 由卡內基梅隆大學開發 acme 由卡內基梅隆大學開發...
Power Gating的設計 架構
switching network的層次 一般選擇flatted的形式，hierarchy的結構對voltage drop和performance delay有影響。power network的結構 external的power rail switch，可以最大限度的減少leakage的消耗，而且對...