ch14-02 Spot 交易终端信息架构
先定义产品场景
产品小节先看上线闭环:交易、数据、风控、钱包和运维必须一起设计,不能只列功能按钮。
源码入口
- packages/deepbook/sources/pool.move:DeepBook Spot、BalanceManager、订单簿或闪电贷逻辑。
- packages/deepbook/sources/balance_manager.move:DeepBook Spot、BalanceManager、订单簿或闪电贷逻辑。
- crates/server/src/reader.rs:REST API、数据库查询、健康检查或指标实现。
- crates/indexer/src/handlers/order_fill_handler.rs:事件解析、字段映射或业务流水落库入口。
把系统拼起来
Spot 终端至少包含:交易对选择、订单簿、最近成交、K 线、余额、下单区、当前委托、历史成交。对专业用户,订单簿和下单区优先级高于装饰性内容。
Spot 终端的信息架构应围绕池子选择、订单簿、下单、订单状态和成交历史组织。链上 PTB 负责真实下单,Server 提供行情和历史,钱包余额与 BalanceManager 可用余额要分开展示。
产品落地判断
- 从用户动作出发写清 PTB 输入、type arguments、权限对象、签名者和预期 digest。
- 前端状态要区分钱包签名、链上确认、Indexer 可见和 Server API 缓存刷新。
- 机器人和后端服务必须有库存、价格、checkpoint lag、错误率和人工暂停阈值。
- 上线前为费用、滑点、oracle、清算、数据延迟和失败重试准备明确披露。
动手检查
- 用户完成本节场景时,最小 PTB、API 查询和 UI 状态分别是什么?
- 失败时应展示权限、余额、价格、oracle、清算、RPC 还是 Indexer 延迟中的哪一类原因?
- 这个应用 MVP 上线前还缺哪项测试、监控、暂停开关或风险披露?