Badget项目数据库模型重构：移除Plaid专有字段实现数据源无关性

在金融科技类应用中，数据聚合是一个核心功能。Badget项目作为一个财务管理工具，近期正在进行一项重要的数据库模型重构工作，目标是移除对Plaid API的强依赖，构建一个能够支持多种数据源的通用数据模型架构。

背景与挑战

当前Badget的数据库模型中存在大量与Plaid API直接相关的字段设计，这种强耦合带来了两个主要问题：

1. 扩展性受限：当需要接入GoCardless等其他金融数据提供商时，模型无法直接复用
2. 维护成本高：任何Plaid API的变更都可能需要同步调整数据库结构

技术方案设计

模型抽象原则

我们确立了三个核心设计原则：

1. 保留最基础的金融交易数据结构
2. 提取Plaid和GoCardless等API的共性字段
3. 将特定提供商的元数据放入扩展字段

关键模型变更

以交易记录模型为例，重构前后的主要变化：

重构前：

• 包含大量Plaid特有的字段命名
• 直接存储Plaid返回的原始数据结构
• 字段验证规则与Plaid强绑定

重构后：

• 使用金融领域通用术语：如transaction_id替代plaid_transaction_id
• 核心字段保持最简集合：日期、金额、交易方等
• 增加provider_metadata字段存储原始API响应

实现细节

数据库迁移策略

采用渐进式迁移方案：

1. 首先添加新字段并保持双写
2. 逐步将业务逻辑迁移到新字段
3. 最后移除旧字段并清理代码

类型系统适配

创建了通用的金融数据类型：

interface BaseTransaction {
  id: string;
  amount: number;
  currency: string;
  date: Date;
  description: string;
  // 公共字段...
  provider_metadata: Record<string, unknown>;
}

业务价值

这项重构为项目带来了显著的长期收益：

1. 新数据源接入时间缩短70%以上
2. 核心业务代码不再需要感知数据来源
3. 为未来的多数据源聚合功能奠定基础

经验总结

在类似金融数据聚合场景中，我们建议：

1. 尽早进行数据模型抽象
2. 保留原始数据的同时建立规范化的核心模型
3. 设计可扩展的元数据存储方案

Badget项目的这次重构实践，为金融科技应用如何处理多源异构数据提供了很好的参考范例。这种架构设计不仅适用于银行数据聚合，也可扩展到其他需要集成多个第三方API的场景。