3. 交易数据模型：交易生命周期、核心数据实体与字段定义

数据模型这东西，说白了就是系统的骨架。我见过太多合规系统上线后跑不动，回头一查，根子都在数据模型上——字段定义不清、生命周期混乱、实体关系没理透。今天咱们就把这块掰开揉碎了讲。

3.1 交易生命周期：从下单到结算的全过程

一个交易从诞生到消亡，会经历好几个阶段。我个人习惯把它分成五个核心阶段：

1. 订单生成——交易员敲下键盘的那一刻
2. 订单校验——系统检查资金、持仓、风控
3. 订单执行——撮合引擎干活，生成成交
4. 清算结算——算账、划拨资产
5. 生命周期结束——归档或废弃

嗯，这里要注意：合规审查主要盯的是第2和第3阶段。我在项目中遇到过，有些团队把合规检查点只放在订单生成后，结果漏掉了成交后的实时监控，差点出事。

3.2 核心数据实体：订单、成交、账户、产品

这四个实体，是交易合规系统的命根子。你想想看，所有合规规则最终都要落到这些实体上。

3.2.1 订单（Order）

订单是交易的起点。我建议订单模型至少要包含以下字段：

字段名	类型	说明
order_id	string	全局唯一订单号
account_id	string	下单账户
product_id	string	交易产品
direction	enum	BUY/SELL
order_type	enum	LIMIT/MARKET/STOP
quantity	decimal	委托数量
price	decimal	委托价格（限价单必填）
status	enum	NEW/PARTIAL/FILLED/CANCELED/REJECTED
created_at	datetime	下单时间

3.2.2 成交（Trade）

成交是订单执行后的产物。一个订单可能对应多笔成交，这个一对多的关系要理清楚。

// 成交数据模型示例（伪代码）
{
  "trade_id": "T202403210001",
  "order_id": "O202403210001",
  "account_id": "A10086",
  "product_id": "BTCUSDT",
  "trade_price": 67500.00,
  "trade_quantity": 0.5,
  "trade_amount": 33750.00,
  "trade_time": "2024-03-21T10:30:00Z",
  "fee": 33.75,
  "fee_currency": "USDT"
}

为什么成交要单独建模？因为合规审查经常需要查「谁在什么价格成交了多少」。如果只靠订单数据，你根本算不出真实的成交明细。

3.2.3 账户（Account）

账户实体承载的是资金和持仓信息。合规系统最关心的是：

• 账户余额是否足够
• 持仓是否超限
• 账户状态是否正常（冻结、禁用等）

我建议账户模型至少包含：account_id、balance、frozen_balance、available_balance、status、kyc_level。其中 kyc_level 是合规审查的关键字段——不同级别的账户，交易权限不一样。

3.2.4 产品（Product）

产品就是交易标的。现货、期货、期权，每种产品的合规规则天差地别。

字段名	类型	说明
product_id	string	产品代码
product_type	enum	SPOT/FUTURES/OPTION
base_currency	string	基础币种
quote_currency	string	计价币种
min_order_qty	decimal	最小下单量
max_order_qty	decimal	最大下单量
price_precision	int	价格精度
status	enum	ACTIVE/SUSPENDED/DELISTED

3.3 数据标准化与字段定义

数据标准化，说白了就是让不同系统之间能「说同一种语言」。你想想看，如果订单系统用「buy」表示买入，合规系统用「B」表示买入，那对接起来得多痛苦？

我建议遵循以下标准化原则：

• 枚举值统一：所有状态、类型都用大写英文，比如 BUY、SELL、LIMIT、MARKET
• 时间格式统一：全部用 UTC 时间，ISO 8601 格式
• 金额精度统一：所有金额字段用 decimal(18,8)，避免浮点数误差
• ID 生成规则统一：建议用「业务前缀 + 时间戳 + 序列号」

// 标准化示例：订单状态枚举
enum OrderStatus {
  NEW,        // 新订单
  PARTIAL,    // 部分成交
  FILLED,     // 全部成交
  CANCELED,   // 已撤销
  REJECTED,   // 已拒绝
  EXPIRED     // 已过期
}

嗯，这里还要提一句：字段命名最好用下划线风格（snake_case），别用驼峰。为什么？因为大多数金融系统后端是 Python 或 Java，下划线风格兼容性更好。我在对接一个老系统时，对方用驼峰命名，结果每次数据映射都要写一堆转换代码，烦得很。

---