此模式屬於 "取代舊系統的模式"
萃取產品線
依產品線識別並分離系統。
2021 年 7 月 21 日
許多應用程式建置於同一實體系統，用於提供多種邏輯產品。這通常是由於需要重複利用所致。「嗯，個人貸款看起來很像企業貸款」或「服飾是一種產品，客製化窗簾也是，它們能有多大的不同？」我們遇到的主要問題是，產品在表面上看起來很相似，但深入探討後卻有很大的不同。
隨著時間推移，服務於多種產品的單一系統可能會變得過於通用，而程式碼也會演變成處理所有可能產品的所有可能組合。例如，對於一個設計用於處理 n 個產品，每個產品有 n 個變更的通用系統，必須執行的測試數量才能檢查所有可能的組合是 n 的階乘。這個數字會快速變大。這也說明了為什麼作者遇到的此類應用程式中，許多應用程式在自動化測試涵蓋率方面幾乎沒有作為，而是依賴於龐大且通常是手動的回歸套件。測試如此多的不同程式碼路徑根本不可行。
因此，問題通常是經濟問題。難以接受針對每個產品開發和維護系統可能比開發和維護單一系統更具經濟效益。透過按產品區分，我們利用了可以同時變更多種產品的事實，並透過避免可能在不需要的地方引入缺陷的變更組合爆炸來降低風險。
當然，這是一個權衡取捨——我們不想要紅色長褲和黑色長褲的獨立應用程式，但我們可能想要一個成衣和訂製服的應用程式，或房屋保險和寵物保險的應用程式。
不同的產品線也通常有非常不同的價值串流，如 萃取價值串流 中所述。
運作方式
識別系統中的產品或產品線。這將形成要建置/移轉的薄片。試著識別現有系統提供的全部功能，並將它們對應到新產品。我們在識別功能、資料、流程、使用者等時傾向於透過不同的觀點來看。
識別共用功能。識別不同的產品線是否有共用的 BusinessCapabilities。有數種方法可以處理這件事，我們在 UnderstandingYourBusinessCapabilities 中會涵蓋這些方法。我們一如既往的建議是重視使用勝於重複使用，因此如有疑問，請儘可能嘗試限制共用功能的數量。
選擇誰先開始。你要先移轉哪些產品線？我們喜歡的一種方法是從風險的角度思考。在了解移轉對業務的風險後，我們通常喜歡採用 *風險第二高的產品線*。這可能會讓人覺得違反直覺，認為我們應該先採用風險最低的選項，但實際上我們喜歡識別一個足夠重要的產品，以保持業務的注意力並讓他們優先考慮資金，但風險不要高到如果出現問題，業務就會失敗。
識別你的目標軟體架構。我們建議進行大爆炸式替換的情況非常罕見，在這種情況下，這表示要一次建置所有產品的所有軟體。相反地，請試著識別步驟 1 中識別的薄片的適當架構。
識別你的技術移轉策略。正如我們在技術移轉模式區段中所討論的，有許多不同的選項可以根據目前的限制來部署。如果是一個簡單的網路應用程式，則可以使用 ForkByUrl。在其他適合 ForkingOnIngress 的情況下，選擇 MessageRouter 模式可能會更好。請記住，過渡架構可能是必要的。
使用時機
您有一個具有易於識別產品線的系統，它會受益於
- 獨立作業。將系統分解成個別產品表示可以針對個別產品組成團隊，讓進度得以在沒有合併地獄和漫長回歸週期等變更協調的典型問題下進行。
- 具有不同的非功能特性。您希望能夠為每個產品提供不同的 SLO。例如，給定延遲的不同負載需求。
- 不同的變更率。有些產品線很穩定，而其他產品則正在積極開發中。分解系統表示您不會冒著對穩定產品進行變更的風險。
保險範例
在保險領域，不同的產品類型有非常不同的特性。例如，車輛保險通常是高量但低利潤，而房屋保險則相反。它也高度競爭，因此快速進行變更的能力非常重要。我們合作的一家保險公司已開發出一個 3 層架構，作為保險公司提供的各種不同產品（包括車輛、人壽、房屋和寵物線）的報價引擎，如圖 1 所示。
了解您想要達到的成果
業務的產品負責人對變更的交貨時間感到越來越沮喪，因為交貨時間很長而且越來越長。他們決定讓 Thoughtworks 檢視他們的架構和開發流程，看看我們是否能找出問題所在。開發流程的價值串流圖找出許多導致交貨時間爆炸的限制。雖然每個技術領域都與其他領域脫鉤，但不同的業務領域卻緊密結合在一起。這表示為 Vehicle 產品新增一個新需求通常會影響 Home、Life 等產品。這些變更在通常充滿問題的部署之前，都需要仔細思考和廣泛的回歸測試。多產品架構也限制了能夠安全處理程式碼庫的人數，進一步減緩進度。
最後，由於 Vehicle 產品線的容量需求和業務的成長，基礎資料儲存必須經常擴充，這需要系統中所主機的所有其他產品停機。
決定如何將問題分解成較小的部分
因此，保險公司決定從以技術能力為主的 n 層架構轉移到以產品線為主的架構。產品已確定為：Vehicle、Home、Life 和 Pet 保險。了解這些產品之後，找出他們各自需要的不同能力，例如個別問題集、報價和客戶帳戶，以及更技術性的能力，例如驗證和授權。客戶帳戶被確定為所有產品線都會使用的主要共用能力，這是採用 EA 魔力象限中的協調方法的一個好範例。
接下來需要做的事情是找出從哪裡開始。根據對公司的營收，產品線的評分為 Vehicle、Home、Life 和 Pet。但就客戶數量而言，順序則相反。因此，決定先個別實作 Home 保險產品線。這平衡了業務風險，也就是出問題的可能性，以及足夠的營收來讓這個選擇變得重要。
成功交付零件
上圖顯示團隊開始建置的事件驅動架構。與報價引擎和客戶管理功能的通訊是透過 RabbitMQ 訊息總線傳遞的事件。這些事件也會傳播到現有的企業資料倉儲，以供報告之用。
當團隊在現有系統旁建置新系統時，已做好準備將流量從舊系統切換到新系統。將產品線全部移轉的一個缺點是，在客戶可以切換之前，必須完整實作問題集。由於這個限制，新系統進入測試階段，某些客戶可以選擇使用測試版本。選擇加入的客戶也有機會提供關於新外觀和感覺的回饋。隨著新系統逐漸增強，並加入最終的視覺功能，已做出是否繼續的決策，並在數週內逐漸將客戶重新導向到新系統。先是 1%，然後是 5%，再是 10% 等。這讓團隊和企業越來越有信心，新系統在功能和非功能觀點上都能如預期執行。最後，新系統為房屋保險提供 100% 的流量。然後團隊轉向持續的產品開發。
變更組織，讓這件事能持續發生
在第一次遷移成功後，注意力轉向下一項挑戰，使用相同方法遷移車輛保險，並重複這個模式，直到遷移完成並關閉舊系統。
同時，整個技術組織逐漸從以專案為基礎的開發方式轉移到以產品為中心的開發方式。這當然會產生一些問題。產品擁有權是一項需要隨著時間培養的技能，因此轉型是一個漸進的過程。他們也採用相同的方式來處理傳統的 IT 作業，在 CTO 和首席架構師的指導下，轉向平台產品工程方法，用於隨選基礎架構，然後是資料和分析。
重大修訂
2021 年 7 月 21 日