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

Labels Milestones

  • Daten-Infrastruktur

    100%
    0 Open
    0 Closed
    Updated 2025-06-13 11:00:07 +02:00
    Closed 2025-06-13 11:00:07 +02:00

    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.