對許多接觸極限程式設計的人來說，極限程式設計似乎要求軟體設計的終結。不僅許多設計活動被嘲笑為「大規模前期設計」，UML、彈性架構，甚至模式等設計技術也遭到貶低或完全忽視。事實上，極限程式設計涉及許多設計，但與既有的軟體流程不同。極限程式設計透過允許演化成為可行的設計策略的實務，讓演化設計的概念重獲新生。隨著設計師需要學習如何進行簡單的設計、如何使用重構來保持設計的簡潔，以及如何以演化的方式使用模式，它也提供了新的挑戰和技能。

在 Java 社群中，出現了一股輕量級容器的熱潮，這些容器有助於將不同專案的元件組裝成一個有凝聚力的應用程式。這些容器的底層有一個共同的模式，說明它們如何執行配線，它們在非常通用的「控制反轉」的名稱下引用這個概念。在本文中，我將深入探討這個模式如何運作，使用更具體的「依賴性注入」名稱，並將它與服務定位器替代方案進行對比。它們之間的選擇不如將組態與使用分開的原則重要。

Ruby Rogues 是一個熱門的 podcast，由固定小組討論 Ruby 程式設計社群中的主題。他們有一個固定的讀書會，最近選了 P of EAA 作為他們的特色書籍。因此，他們邀請我擔任他們節目的來賓，討論這本書和它所描述的模式，特別是這些模式與 Rails 架構之間的有趣關係。

我接受了 Bill Venners 對其 artima.com 網站的訪談。在訪談中，我提到了重構、演化設計、彈性和測試驅動開發。Bill 甚至讓我聽起來很條理分明。

QCon London 2007 的組織者請我做一個關於架構可修改性的會議場次。我認為與其聽我說話，與會者可能更喜歡聽一些 Thoughtworks 架構師的意見，我通常會重新整理他們的意見：Dave Farley、Ian Cartwright、Fred George、Erik Doernenberg 和 Daniel Terhorst-North。InfoQ 現在已上傳該場次的影片。

GUI 架構如何演化的歷史概述，特別關注不同團體多年來如何看待模型-檢視-控制器。從歷史觀點來看，與我的簡報模式相關。

去年年底，我與 Thoughtworks 的同事參加了一個工作坊，討論「事件驅動」應用程式的性質。在過去幾年中，我們建立了很多大量使用事件的系統，它們經常受到讚揚，也經常受到譴責。我們的北美辦事處組織了一場高峰會，來自世界各地的 Thoughtworks 高級開發人員前來分享想法。

高峰會最大的成果在於認知到當人們談論「事件」時，他們實際上指的是一些截然不同的事情。因此我們花了很多時間試圖找出一些有用的模式。這份備忘錄簡要總結了我們所識別出的主要模式。