# Projektplan: Meilenstein Daten-Infrastruktur *Datum: 13. Juni 2025* ## Status: Design-Phase abgeschlossen, Basis-Implementierung erfolgt --- ## Stufe 1: Asynchrone Datenstrom-Schnittstelle (`IDataStream`) - **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`-Schnittstelle wurde überarbeitet. Die `HasData`-Eigenschaft liefert nun ein `TSignal`, das Konsumenten aktiv über potenziell neue Daten informiert. * Die Referenzimplementierung `TAuraFileStream` 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` 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. # TODO-Einträge: Dateninfrastruktur ## Stufe 2: `IDataSeriesProvider` - [ ] **Interface und Basis-Implementierung erstellen** * Definiere das `IDataSeriesProvider`-Interface. * Definiere die `TProviderStatus`-Enumeration (`psInitializing`, `psReadyContinuous`, `psReadyWithGap`, `psFaulted`). * Implementiere eine abstrakte Basisklasse `TDataSeriesProvider`, die die grundlegenden Felder (z.B. für die interne `TDataSeries`) und Methoden bereitstellt. - [ ] **Simulations-Modus implementieren** * Erstelle eine konkrete Implementierung (z.B. `TSimulationSeriesProvider`). * Implementiere die Start-Logik: * Laden des gesamten relevanten Datenkontexts via `TAuraDataServer.LoadDataSeries`. * Positionierung auf einen wählbaren Startzeitpunkt via `TDataSeries.IndexOf`. * Extrahieren des initialen Lookback-Puffers. * Implementiere das "Playback" der nachfolgenden Datenpunkte aus der im Speicher gehaltenen Serie. * Setze den `Status` korrekt auf `psReadyContinuous`, da im Simulationsmodus per Definition keine Lücke zur "Gegenwart" existiert. - [ ] **Live-Handel Modus implementieren** * **Voraussetzung**: Definiere eine Schnittstelle für Live-Datenquellen (z.B. `ILiveDataSource`), die eine Methode zur Abfrage rezenter historischer Daten (`GetCatchUpData`) enthält. * **Start-Logik (Drei-Phasen-Synchronisation)**: * Implementiere den parallelen Start der asynchronen Operationen: 1. Laden der lokalen Historie. 2. Herstellen der Broker-Verbindung und Abrufen der "Catch-up"-Daten. * Implementiere die "Splicing"-Logik, die beide Datenquellen zu einem nahtlosen Lookback-Puffer verbindet. * Implementiere die Prüfung auf ein "Markt-Gap" beim Übergang, um den initialen Status korrekt auf `psReadyContinuous` oder `psReadyWithGap` zu setzen. * **Laufzeit-Logik**: * Implementiere das kontinuierliche Verarbeiten des Live-Streams. * Implementiere die Fehlerbehandlung für Laufzeit-Unterbrechungen (Verbindungsverlust), inklusive des Wechsels in den `psFaulted`-Status und des sicheren "Re-Priming". - [ ] **Session-Kalender entwerfen und implementieren** * **Motivation**: Notwendig für die Unterscheidung zwischen "Markt-Gaps" (natürlich) und "Daten-Lücken" (Fehler) im Live-Betrieb. * **Anforderung**: Muss pro Asset konfigurierbar sein (Handelszeiten, Feiertage). * **Implementierung**: Erstelle eine Klasse, die für ein gegebenes Zeitintervall prüfen kann, ob der Markt geöffnet oder geschlossen war. Integriere diese Prüfung in die Laufzeit-Logik des `TDataSeriesProvider` im Live-Modus.