本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 將商業邏輯從資料庫遷移至應用程式層
<a name="logic"></a>

從資料庫存放的程序、觸發條件和函數遷移商業邏輯到應用程式層服務，是分解單體資料庫的關鍵步驟。此轉換可改善服務自主權、簡化維護，並增強可擴展性。本節提供分析資料庫邏輯、規劃遷移策略，然後在維持業務連續性的同時實作轉換的指引。它還討論了建立有效的轉返計劃。

**Topics**
+ [階段 1：分析商業邏輯](#logic-analysis)
+ [階段 2：分類商業邏輯](#logic-classification)
+ [階段 3：遷移商業邏輯](#logic-migration)
+ [商業邏輯的轉返策略](#logic-rollback)

## 階段 1：分析商業邏輯
<a name="logic-analysis"></a>

現代化單體資料庫時，您必須先對現有的資料庫邏輯進行全面的分析。此階段著重於三個主要類別：
+ *存放程序*通常包含重要的業務操作，包括資料處理邏輯、業務規則、驗證檢查和計算。作為應用程式商業邏輯的核心元件，它們需要仔細分解。例如，金融組織的預存程序可能會處理興趣計算、帳戶對帳和合規檢查。
+ *觸發*是處理稽核追蹤、資料驗證、計算和跨資料表一致性的關鍵資料庫元件。例如，零售組織可能會使用觸發來管理整個訂單處理系統的庫存更新，這示範了自動化資料庫操作的複雜性。
+ 資料庫*中的函數*主要管理資料轉換、計算和查詢操作。它們通常嵌入到多個程序和應用程式中。例如，醫療保健組織可能會使用 函數來標準化患者資料或查詢醫療代碼。

每個類別代表內嵌在資料庫層中的業務邏輯的不同層面。您需要仔細評估和規劃每個項目，以便將它們遷移到應用程式層。

在此分析階段，客戶通常會面臨三個重大挑戰。首先，透過巢狀程序呼叫、跨結構描述參考和隱含資料相依性來產生複雜的相依性。其次，交易管理變得至關重要，特別是在處理多步驟交易和維護分散式系統之間的資料一致性時。第三，必須仔細評估效能考量，特別是目前受益於接近資料的批次處理操作、大量資料更新和即時計算。

若要有效地解決這些挑戰，您可以使用 [AWS Schema Conversion Tool (AWS SCT)](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html) 進行初始分析，然後使用詳細的相依性映射工具。此方法可協助您了解資料庫邏輯的完整範圍，並建立全面的遷移策略，以在分解期間維持業務連續性。

透過徹底了解這些元件和挑戰，您可以更好地規劃現代化旅程，並針對遷移至微服務型架構期間要優先考慮哪些元素做出明智的決策。

分析資料庫程式碼元件時，請為每個預存程序、觸發條件和函數建立完整的文件。首先清楚地描述其目的和核心功能，包括其實作的業務規則。詳細說明所有輸入和輸出參數，並記下其資料類型和有效範圍。映射其他資料庫物件、外部系統和下游程序的相依性。明確定義交易界限和隔離要求，以維護資料完整性。記錄任何效能期望，包括回應時間需求和資源使用率模式。最後，分析用量模式，以了解尖峰負載、執行頻率和關鍵業務期間。

## 階段 2：分類商業邏輯
<a name="logic-classification"></a>

有效的資料庫分解需要跨關鍵維度對資料庫邏輯進行系統性分類：複雜性、業務影響、相依性、使用模式和遷移困難。此分類可協助您識別高風險元件、判斷測試需求，以及建立遷移優先順序。例如，具有高業務影響和頻繁使用的複雜預存程序需要仔細規劃和廣泛的測試。不過，具有最少相依性的簡單、很少使用函數可能適用於早期遷移階段。

這種結構化方法會建立平衡的遷移藍圖，將業務中斷降至最低，同時維持系統穩定性。透過了解這些相互關聯性，您可以改善分解工作的順序，並適當地配置資源。

## 階段 3：遷移商業邏輯
<a name="logic-migration"></a>

在您分析並分類商業邏輯之後，是時候遷移它了。從單體資料庫遷移商業邏輯時有兩種方法：將資料庫邏輯移至應用程式層，或將商業邏輯移至屬於微服務一部分的另一個資料庫。

如果您將商業邏輯遷移至應用程式，則資料庫資料表只會存放資料，而且資料庫不包含任何商業邏輯。這是建議的方法。您可以使用 [Isquarer](https://aws.amazon.com/marketplace/seller-profile?id=seller-6w64f4cwyhmiw)** **或生成式 AI 工具，例如 [Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html) 或 [https://kiro.dev/](https://kiro.dev/)，來轉換應用程式層的資料庫商業邏輯，例如轉換為 Java。如需詳細資訊，請參閱[將商業邏輯從資料庫遷移到應用程式，以加快創新速度和靈活性 ](https://aws.amazon.com/blogs/mt/migrate-business-logic-from-database-to-application-for-faster-innovation-and-flexibility/)(AWS 部落格文章）。

如果您將商業邏輯遷移至另一個資料庫，您可以使用 [AWS Schema Conversion Tool (AWS SCT)](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html) 將現有的資料庫結構描述和程式碼物件轉換為目標資料庫。它支援專用 AWS 資料庫服務，例如 [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html)、[Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html) 和 [Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/welcome.html)。透過提供全面的評估報告和自動化轉換功能， AWS SCT 有助於簡化轉換程序，讓您專注於最佳化新的資料庫結構，以提高效能和可擴展性。隨著現代化專案的進行， AWS SCT 可以處理增量轉換以支援分階段方法，讓您能夠驗證和微調資料庫轉換的每個步驟。

## 商業邏輯的轉返策略
<a name="logic-rollback"></a>

任何分解策略的兩個關鍵層面是維持回溯相容性並實作全面的轉返程序。這些元素共同運作，以協助在轉換期間保護操作。本節說明如何在分解過程中管理相容性，並建立有效的緊急復原功能，以防止潛在問題。

### 維持回溯相容性
<a name="logic-rollback-backward-compatibility"></a>

在資料庫分解期間，維持回溯相容性對於順暢轉換至關重要。暫時保留現有的資料庫程序，同時逐步實作新功能。使用版本控制來追蹤所有變更，並同時管理多個資料庫版本。規劃較長的共存期間，其中來源和目標系統都必須可靠地運作。這提供了在淘汰舊版元件之前測試和驗證新系統的時間。此方法可將業務中斷降至最低，並視需要提供復原的安全網路。

### 緊急復原計劃
<a name="logic-rollback-plan"></a>

全方位的復原策略對於安全資料庫分解至關重要。在程式碼中實作功能旗標，以控制哪個商業邏輯版本處於作用中狀態。這可讓您在新實作和原始實作之間立即切換，而無需變更部署。此方法提供對轉換的精細控制，並在發生問題時協助您快速復原。將原始邏輯保留為已驗證的備份，並維護詳細的轉返程序，以指定觸發、責任和復原步驟。

在各種條件下定期測試這些復原案例，以驗證其有效性，並確保團隊熟悉緊急程序。功能旗標也會針對特定使用者群組或交易選擇性地啟用新功能，以啟用逐步推展。這在轉換期間提供額外的風險緩解層。