Brummel/MycLib
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects 1 Releases Wiki Activity

Daten-Infrastruktur

New Issue

Projektplan: Meilenstein Daten-Infrastruktur

Datum: 13. Juni 2025

Status: Design-Phase abgeschlossen, Basis-Implementierung erfolgt

Stufe 1: Asynchrone Datenstrom-Schnittstelle (IDataStream<T>) - ABGESCHLOSSEN

  • Motivation: Das ursprüngliche, zustandsbehaftete Design war für die Verarbeitung asynchron eintreffender Daten (z.B. von TFuture-Objekten) zu komplex und fehleranfällig.

  • Ziel: Die Schaffung eines robusten, ereignisgesteuerten und non-blocking Modells, das den Datenproduzenten sauber vom Konsumenten entkoppelt.

  • Ergebnis:

    • Die IDataStream<T>-Schnittstelle wurde überarbeitet. Die HasData-Eigenschaft liefert nun ein TSignal, das Konsumenten aktiv über potenziell neue Daten informiert.
    • Die Referenzimplementierung TAuraFileStream<T> wurde erfolgreich angepasst und nutzt eine saubere Ereignis-Kopplung (Subscribe) für eine robuste und wartungsarme Logik.
    • Die korrekte Funktionalität wurde durch eine angepasste DUnitX-Test-Suite verifiziert.

Stufe 2: Abstraktion für Handelssysteme (IDataSeriesProvider) - ENTWORFEN

  • Motivation: Ein Handelssystem benötigt einen stets validen und kontinuierlichen Daten-Lookback. Ein roher IDataStream<T> kann dies nicht garantieren, da Lücken in den Daten auftreten können (z.B. beim Übergang von Historie zu Live).

  • Ziel: Die Konzeption einer übergeordneten Abstraktionsschicht, die diese komplexe Anforderung kapselt, die Datenintegrität sicherstellt und dem Handelssystem eine einfache, sichere Schnittstelle bietet.

  • Ergebnis:
    Entworfen wurde der IDataSeriesProvider, der als "Black Box" für das Handelssystem fungiert und die Komplexität der Datenbeschaffung vollständig verbirgt. Er wurde mit zwei unterschiedlichen, vom Anwender wählbaren Betriebsmodi konzipiert:

    Modus 1: "Live-Handel"

    • Motivation: Um einen echten "Sofort-Start" im Live-Handel zu ermöglichen, muss die Lücke zwischen den statischen, lokalen Historiendaten und dem aktuellen Zeitpunkt geschlossen werden.
    • Ziel: Ein lückenloser, tagesaktueller Start des Handelssystems ohne manuelles Eingreifen oder lange Wartezeiten für den Nutzer.
    • Ergebnis: Das Design einer Drei-Phasen-Synchronisation: (1) Lokale History laden, (2) "Catch-up"-Daten vom Broker holen, (3) auf den Live-Stream umschalten.

    Modus 2: "Simulation & Backtest"

    • Motivation: Für Entwicklung, Test und Analyse muss die Software völlig autonom und ohne Abhängigkeit von einer externen, potenziell nicht verfügbaren Broker-API lauffähig sein.
    • Ziel: Einen "Sofort-Start" für Backtests zu jedem beliebigen Zeitpunkt in der Vergangenheit zu ermöglichen, der rein auf lokalen Dateien basiert.
    • Ergebnis: Ein Design, bei dem der relevante Datenkontext in den Speicher geladen wird, um von dort aus einen schnellen Start und ein "Playback" der Daten zu ermöglichen.
No due date
100% Completed

No results

Try adjusting your search filters.