12. Live Trading S1.3 Designphilosophie und Architektur
In diesem Artikel wird aus Designperspektive der Live-Trading-Refactor-Ansatz für S1.3 erläutert: Warum die Schichtung auf diese Weise erfolgt, wie die Kompatibilität gewahrt bleibt und wie diese Designs bei zukünftigen Erweiterungen helfen.
12.1. 0. 文档定位
Bei diesem Dokument handelt es sich um eine Designspezifikation und nicht um ein Benutzer-Tutorial.
Der Schwerpunkt liegt auf der Frage, warum wir es auf diese Weise tun, und nicht auf der Frage, wie wir Schritt für Schritt vorgehen.
Wenn Sie einen praktischen Weg benötigen, gehen Sie bitte zu „live_trading/2-configuration-and-run.md“ und „tutorials/8-live-trade-risk-and-broker-walkthrough.md“.
12.2. 1. 设计目标
Verbessern Sie die Überprüfbarkeit und Überprüfbarkeit des Live-Pfads, ohne bestehende Benutzerströme zu unterbrechen
Verschieben Sie die Risikokontrolle nach vorn auf „bevor Sie Aufträge erteilen und in die Datenbank schreiben“.
Abstrahieren Sie die Broker-Adapterschicht, um eine stabile Grenze für die zukünftige Integration mit echten Broker-Frontends zu reservieren
12.3. 2. 分层结构
Die lebensbezogenen Verantwortlichkeiten von S1.3 können wie folgt abstrahiert werden:
Operator: Planung der Strategieausführung und Signalquelle„Trader“: Auftragsabsicht, Risiko-Gating und Ausführungskoordination verwirklichen
„RiskManager“: reine logische Regelauswertung, keine IO-Abhängigkeiten
Broker: Übermittlung, Stornierung, Ausführungsmeldungen, Verbindungssemantiktrade_io: Vertragsvalidierung für Auftrags-/Handelsdaten
12.4. 3. 关键设计原则
3.1 Vertrag zuerst
Validieren Sie das Order-Diktat und füllen Sie das Diktat an der Grenze aus, um stille Fehler zu vermeiden, die durch „es läuft auch dann noch, wenn die Struktur falsch ist“ verursacht werden.
3.2 Risikokontrollen nach links verschieben
Die Risikobewertung wird vor dem Schreiben in die Datenbank und dem Einreihen in die Warteschlange abgeschlossen, sodass abgelehnte Aufträge keine Ausführungsdaten verunreinigen.
3.3 Adapterentkopplung
Führen Sie zukünftige Integrationen über die Broker-Adapter-API durch, um die Kopplung zwischen Trader und bestimmten Broker-Systemen zu reduzieren.
3.4 Überprüfbar
Ablehnungsgründe sind über „rule_id“ und einen englischen „reason“ extern sichtbar und unterstützen die operative Suche und die Überprüfung nach dem Vorfall.
12.5. 4. 典型疑难点与取舍
4.1 Kompatibilitätssemantik der Ablehnungsreihenfolge
Behalten Sie die Abwärtskompatibilität bei (Ablehnungen können als leere Ergebnisse erscheinen) und verbessern Sie gleichzeitig die Sichtbarkeit (CLI/TUI-Zusammenfassung + Protokolle).
4.2 Koexistenz von neuen und alten Strömen
Behalten Sie den Legacy-Warteschlangenkompatibilitätspfad bei, um das Regressionsrisiko einer einmaligen Migration zu vermeiden.
4.3 Zustandskonsistenz
In Teilfüllungsszenarien sollte der Status auf dem kumulativen Füllvolumen basieren, um von Benutzern beobachtete semantische Diskrepanzen zu reduzieren.
12.6. 5. 与 S2.1 的关系
S1.3 ist nicht der Endpunkt der Broker-Integration, sondern die grundlegende Grundlage:
Stabilisieren Sie zunächst die Schnittstellengrenzen
Dann binden Sie sich nach und nach an echte Brokersysteme an.
Erweitern Sie schließlich die Funktionen, ohne die Upstream-Nutzung zu unterbrechen.
12.7. 6. 对用户行为的影响
Konfigurationsfehler werden früher aufgedeckt.
Ablehnungsgründe sind leichter zu ermitteln.
Zustandsänderungen im laufenden Betrieb sind einfacher zu erklären.
Die Kosten für die Erweiterung durch Drittanbieter-Broker sind besser kontrollierbar.
12.8. 7. 相关阅读
Modulübersicht:
live_trading/1-overview.mdBedienung und Konfiguration:
live_trading/2-configuration-and-run.mdRisikokontrolle und Status: „live_trading/3-risk-and-order-lifecycle.md“.
Broker 接入：
live_trading/4-broker-adapter-and-integration.md