此模式屬於 "舊有系統取代模式"
過渡架構
安裝軟體元素以簡化舊有系統的取代，我們打算在取代完成後移除這些元素。
2022 年 3 月 28 日
成功取代舊有系統的核心在於逐步以新軟體取代舊有軟體，因為這能讓好處提早實現，並規避大爆炸的風險。在取代過程中，舊有系統和新系統必須同時運作，讓行為能在舊有系統和新系統之間分割。此外，兩者之間的勞動分工會隨著舊有系統逐漸萎縮而定期改變。
為了讓舊有系統和新系統之間有這樣的交互作用，我們需要建置並演進過渡架構，以支援這種隨著時間推移而改變的協作。中間的設定可能需要整合，這些整合在目標架構中沒有位置。
或者更直接地說，你必須投資在最後會被丟棄的工作上。
運作方式
想想建築物的翻新。建築師已提供完工產品的渲染圖，而建築工人也準備開始動工。但第一步是在建築工地架設鷹架。
租用鷹架本身並付費請團隊組裝是不可避免的投資。這是為了讓關鍵工作得以進行，並在翻新過程中購買風險緩解措施，以提高工人的安全性。它甚至可能開啟新的選項，讓你可以在更換屋頂時修理煙囪，或處理懸空的樹木（讓這個比喻再延伸一點）。一旦工作完成，另一組團隊會來拆除鷹架，而你會很樂意看到它消失。
在傳統的置換背景下，此腳手架包含軟體元件，可簡化或協助建置朝向目標架構的當前演化步驟。如同腳手架，這些軟體元件在達到目標架構後不再需要，且必須移除。
一次替換大型傳統巨石應用程式有風險，我們可以使用多個步驟進行置換，以提高業務安全性。我們可以使用 萃取價值串流 和 萃取產品線 等模式，依功能子集或資料子集進行置換。為執行任何一項置換，我們需要分解巨石應用程式，這需要在巨石應用程式中引入接縫，以分隔各個部分。引入巨石應用程式接縫的元件為過渡架構，因為它們在巨石應用程式被置換後勢必會消失，而且巨石應用程式也不需要它們來履行既有職責。
我們可以透過觀察巨石應用程式的不同部分如何彼此通訊，並在通訊路徑中放置元件，來引入接縫，我們修改此元件以轉移或複製流量至其他元素。事件攔截 使用事件通訊來執行此操作，抽象分支 使用 API 執行此操作。在建立這些接縫時，我們可以引入 傳統模擬，以將新元件引入傳統通訊流程。
傳統置換面臨的最大挑戰之一是處理資料，傳統系統通常會直接存取資料。如果可行，建議透過引入 API 來替換直接資料存取，例如採用 儲存庫 模式，以引入接縫。但是，如果我們無法執行此操作，則需要複製系統狀態。傳統模擬 和 事件攔截 在我們需要採取此途徑時，兩者都很有用。
| 使用 | 模式 |
|---|---|
| 建立接縫 | |
| 複製狀態：新 ➔ 舊 （「維持運作」） |
傳統模擬（服務使用模擬） |
| 複製狀態：舊 ➔ 新 |
傳統模擬（服務提供模擬） |
即使心中有明確的目標架構，也有許多途徑可以達成。團隊可以採取的每條不同途徑，都將由不同的過渡架構啟用或需要不同的過渡架構來實施。在此情況下，我們需要對每條途徑進行成本/效益分析，詳細到足以了解它是否會對選擇產生影響。
請記住，使用過渡架構的一部分是在不再需要時移除它。在建置過渡架構時，值得多投資一些，以增加讓它更容易在稍後移除的功能。同樣地，我們需要確保適當移除它，不必要的元件，即使未用，也可能會讓未來團隊維護和發展系統的工作變得複雜。
使用時機
沒有人喜歡浪費辛勤工作，當我們談論建造我們打算丟棄的東西時，這種情緒自然而然地產生。很容易得出結論，一次性的東西價值很低。但是，過渡架構以幾種方式提供價值，並且此價值應與建構它的成本進行比較。
第一個價值是，它通常可以提高向企業提供功能的速度。這裡一個方便的比喻是在粉刷牆壁時在飾條上使用油漆膠帶。如果不貼飾條，您必須在飾條附近小心且緩慢地塗漆。在之前放置膠帶和之後移除膠帶的成本，是由於避免在錯誤的地方塗漆而需要的更高的速度（和更少的技巧）所彌補的。
軟體中的這種權衡因時間價值的重要性而被放大。如果企業需要一個新的儀表板，將被取代的舊系統中的現有資料與新系統中的資料整合在一起，您可以透過在新的儀表板中建構一個閘道，來讀取和將舊系統來源的資料轉換成儀表板所需的格式，來更快地完成。一旦舊系統被移除，這個閘道就會被丟棄，但在更換發生之前，擁有整合儀表板一段時間的價值很可能超過建立它的成本。如果比較接近，我們還應該考慮舊系統更換花費的時間比預期更長的情況。
過渡架構的第二個價值在於它如何降低舊系統更換的風險。在客戶管理系統中新增事件攔截需要一些建構成本，但一旦建構完成，它就可以逐步遷移客戶（例如使用提取產品線或提取價值串流）。遷移客戶的子集可以減少遷移過程中出現嚴重問題的機率，並傾向於減少任何出錯的影響。此外，如果出現非常嚴重的問題，事件攔截可以輕鬆地還原到先前的狀態。
原則上，團隊在進行舊系統轉移時，應始終考慮過渡架構，並集思廣益找出建置一些臨時軟體可實現這些好處的不同方式。然後，團隊應評估增加價值時間和降低風險的好處，以抵銷建置此類短暫軟體的成本。我們認為，許多人會驚訝於臨時軟體的成本回收頻率。
範例：架構演進
本節探討概觀文章中介紹的 Middleware 移 除範例，並說明過渡架構如何讓系統安全地演進。
舊系統組態
如概觀中所述，現有架構包含負責定價和透過某些整合 Middleware 將產品發布到舊系統商店面的主要舊系統。該 Middleware 使用舊系統佇列中的產品發布事件，並處理產品在店面中呈現方式的長期協調。當產品售出時，舊系統商店面會呼叫 Middleware，Middleware 會在基礎共用舊系統資料庫中更新產品狀態。舊系統 Middleware 也會將其內部狀態儲存在舊系統資料庫中，並透過資料倉儲提供給關鍵報告。請參閱 關鍵彙總器
目標架構
在目標架構中，舊系統商店面仍然存在，但已將部分責任移轉到新的商店面管理員元件。當產品透過該管道銷售時，商店面管理員會使用資產處置路由器產生的商業事件，並使用新的 API 將產品發布到商店面。商店面管理員將負責產品在商店面中的顯示方式。當產品售出時，舊系統商店面會使用新的 API 呼叫商店面管理員，然後商店面管理員會發出商業事件，供下游資產銷售處理元件使用。
第一個小型啟用步驟
要新增的第一個過渡架構元件是事件路由器元件。這是 事件攔截 模式的範例。事件路由器建立一個技術接縫，可利用該接縫透過新元件路由待售產品。
店面管理員簡介
下一步是新增店面管理員。過渡架構也同時新增於此，用於兩個截然不同的目的。也就是將新元件與舊有問題（例如資料結構和訊息）隔離，並在舊有環境中維持運作。為了隔離（防腐敗層），建立了一個事件轉換器，將事件路由器路由的舊有訊息轉換成新的乾淨商業事件格式，供店面管理員使用，並在目標架構中持續使用。店面管理員和舊有店面將透過新的 API 進行協作，因此也新增了此功能，以及內部的 事件攔截，以便在產品售出時，舊有店面會「呼叫回」發佈該產品的系統。為了維持運作，需要兩個過渡架構。首先，在產品售出時，會發佈新的商業事件。這些事件會由一個暫時的舊有資料庫轉接器使用，模擬整合中介軟體，使用銷售資訊更新舊有資料庫。其次，建立了 MI 資料模擬。這是一個事件攔截器和舊有模擬器，它會攔截新 API 中的事件，並使用商業關鍵報告所需的「狀態」資訊更新舊有資料庫。
商業成果 - 停用舊有中介軟體
舊有系統仍負責判定哪些資產可以銷售，並傳送產品進行發佈，但隨著時間推移，路由到新元件的產品數量會增加（請參閱 擷取產品線），直到 100% 的流量在不依賴舊有中介軟體的情況下進行處理。此時，就可以停用舊有中介軟體，讓新的店面管理員和過渡架構元件在生產環境中運作。
資產處置路由器簡介
一段時間後，新的資產處置路由器元件上線。（請注意，這個範例經過簡化，並取材自一個規模更大的舊有系統汰換計畫。）該元件會發佈店面管理員可以使用的產品的新商業事件。由於其他元件已接手判定哪些資產要處置，因此不再需要事件路由器，也不需要事件轉換器，所以可以停用這些元件。由於舊有中介軟體已停用，因此商業關鍵報告已變更為使用新元件的資料（請參閱 回復來源），因此也可以停用 MI 資料模擬元件。
安全抵達目標架構
稍後，新的資產銷售處理元件上線，接管了舊有系統的最後一組職責（在此範例的範圍內）。在那個時候，過渡架構的最後一個元件，即舊有資料庫轉接器，就可以移除。店面管理員產生的商業事件由資產銷售處理元件使用。
重大修訂
2022 年 3 月 28 日：初次發布