12. Live Trading S1.3 Filosofía de diseño y arquitectura

Este artículo explica, desde una perspectiva de diseño, el enfoque de refactorización de operaciones en vivo para S1.3: por qué las capas se realizan de esta manera, cómo se mantiene la compatibilidad y cómo estos diseños ayudan con futuras extensiones.

12.1. 0. 文档定位

Este documento es una especificación de diseño, no un tutorial para el usuario.
Se centra en responder “por qué lo hacemos de esta manera”, en lugar de “cómo operar paso a paso”.
Si necesita una ruta práctica, vaya a live_trading/2-configuration-and-run.md y tutorials/8-live-trade-risk-and-broker-walkthrough.md

12.2. 1. 设计目标

Sin interrumpir los flujos de usuarios existentes, mejore la verificabilidad y auditabilidad de la ruta en vivo
Avanzar el control de riesgos a «antes de realizar pedidos y escribir en la base de datos»
Resuma la capa del adaptador de corredor para reservar un límite estable para la integración futura con interfaces de corredor reales.

12.3. 2. 分层结构

Las responsabilidades relacionadas con la vida de S1.3 se pueden resumir como:

Operator: programación de ejecución de estrategia y fuente de señal
Trader: materializar la intención de la orden, la detección de riesgos y la coordinación de la ejecución
RiskManager: evaluación de reglas lógicas puras, sin dependencias de IO
Broker: enviar, cancelar, informar y semántica de conexión
trade_io: validación de contrato para datos de pedido/comercio

12.4. 3. 关键设计原则

3.1 Contrato primero

Valide el dictado de orden y complete el dictado en el límite para evitar errores silenciosos causados por «todavía se ejecuta incluso cuando la estructura es incorrecta».

3.2 Desplazar los controles de riesgo hacia la izquierda

La evaluación de riesgos se completa antes de escribir en la base de datos y ponerla en cola, por lo que las órdenes rechazadas no contaminan los datos de ejecución.

3.3 Desacoplamiento del adaptador

Realice integraciones futuras a través de la API del adaptador de intermediario para reducir el acoplamiento entre Trader y sistemas de intermediario específicos.

3.4 Auditable

Los motivos de rechazo son visibles externamente a través de rule_id y un reason en inglés, lo que respalda la búsqueda de operaciones y la revisión posterior al incidente.

12.5. 4. 典型疑难点与取舍

4.1 Semántica de compatibilidad de orden de rechazo

Mantenga la compatibilidad con versiones anteriores (los rechazos pueden aparecer como resultados vacíos) mientras mejora la visibilidad (resumen CLI/TUI + registros).

4.2 Coexistencia de flujos nuevos y heredados

Mantenga la ruta de compatibilidad de la cola heredada para evitar el riesgo de regresión debido a una migración única.

4.3 Consistencia del estado

En escenarios de llenado parcial, el estado debe basarse en el volumen llenado acumulado para reducir las discrepancias semánticas observadas por los usuarios.

12.6. 5. 与 S2.1 的关系

S1.3 no es el punto final de la integración de los brokers, sino la base fundamental:

Estabilice los límites de la interfaz primero
Luego, conéctese gradualmente a sistemas de corredores reales.
Por último, amplíe las capacidades sin interrumpir el uso ascendente.

12.7. 6. 对用户行为的影响

Los errores de configuración se exponen anteriormente.
Los motivos del rechazo son más fáciles de identificar.
Los cambios de estado durante la operación en vivo son más fáciles de explicar.
El costo de ampliar los corredores externos es más controlable.

12.8. 7. 相关阅读

Descripción general del módulo: live_trading/1-overview.md
Operación y configuración: live_trading/2-configuration-and-run.md
Control y estado de riesgos: live_trading/3-risk-and-order-lifecycle.md
Integración del corredor: live_trading/4-broker-adapter-and-integration.md