Architektur_&_Entscheidungen

Architektur & Entscheidungen

Seitenregeln

• Single Source of Truth für Struktur, Kontext und Architekturentscheidungen (Warum). Keine Betriebs‑, Security‑ oder Deploy‑Details.
• Nur high‑level Diagramme/Flüsse, keine Implementierungsdetails.
• Entscheidungen (ADRs) werden hier festgehalten und versioniert; technische Umsetzung wird nur verlinkt.
• Keine Geheimnisse oder konkrete Zugangsdaten.
• Aktualisieren bei: neuer Komponente, geänderter Datenfluss, neuer/angepasster ADR.
• Verweise auf: „Plattform, Netzwerk & Edge“ (Umsetzung an der Kante), „Build, Deployment & Laufzeit“ (Umsetzung in der App).
• Benenne betroffene Dateien inkl. Pfad als Unterpunkte, wenn diese für zukünftige Änderungen relevant.

Zweck und Abgrenzung

• Zweck: Regelbasiertes Aktien‑Research und Kaufsignale mit frei verfügbaren Datenquellen; zentrale Datenhaltung; reproduzierbare Regeln (Magic Formula + Preis‑Trigger + Marktfilter).
• Abgrenzung:
  • Keine Intraday‑/Realtime‑Signale, kein Auto‑Trading.
  • Kernmodell ohne Finanzwerte/Versorger/REITs (separate Sektormodule später).
  • KI‑Analyse nur manuell per Button (keine Dauerüberwachung).
  • EU‑Fundamentals „best effort“, mit Confidence‑Flags.

Kontextdiagramm (Akteure, Drittsysteme)

• Akteur: Nutzer Stefan (ISIN eingeben, Alerts empfangen, KI‑Analyse auslösen).
• Drittsysteme (read‑only):
  • OpenFIGI (Mapping ISIN → Listing/Ticker/MIC).
  • Stooq (Historische Preise, VIX).
  • Alpha Vantage (Tagespreise, kompakt).
  • EZB (FX) – vorgesehen.
  • SEC EDGAR, SimFin, FMP (Fundamentals) – vorgesehen/teilweise.
  • Webex (Alerts 1:1).
  • Metabase (Visualisierung, liest nur DB).
• Interne Systeme:
  • n8n (ETL/Workflows, Alerts).
  • PostgreSQL (Single Source of Truth, Schema: core).

Komponentenübersicht

• Orchestrierung: n8n Community (Workflows, Triggers, HTTP/DB‑Knoten).
• Datenbank: PostgreSQL (DB mf_app, Schema core).
• Dashboard: Metabase (separat; direkt auf Postgres).
• Datenquellen:
  • Kurse: Stooq (primär), Alpha Vantage (Fallback).
  • Listings: OpenFIGI (primär).
  • Marktfilter‑Proxy: VIX (Stooq, Symbol vi.c).
  • Fundamentals: SEC/SimFin/FMP (Workflows geplant, Architektur berücksichtigt).
• Benachrichtigung: Webex Bot (1:1).
• KI‑Modul: Manuell startbar, nutzt gespeicherte Daten + On‑Demand‑News (RSS/Web).

Datenflüsse (high level)

• Aufnahmefluss: ISIN (Form) → OpenFIGI Mapping (XETR bevorzugt) → Persistenz securities/listings.
• Kursfluss: Stooq/AV → Parsing → prices_daily (EUR für XETR direkt) → Indikatoren (SMA200, 52W‑High, 3‑Tage‑Hoch, Drawdown).
• Marktfluss: VIX→F&G‑Proxy (täglich) → market_state.
• Signalfluss: Preis‑Regeln (+ später MF + Marktfilter) → signals → Alerts (nur „Nein → Ja“) via Webex → Logging (alerts_log).
• Reportingfluss: Metabase liest Postgres → Dashboard „Jetzt kaufen?“ + „Alle Werte“.
• Governance/Qualität: jobruns, dataquality protokollieren.

Technologiestack (Kurzliste)

• n8n CE (Workflows, HTTP, Postgres‑Nodes, Form).
• PostgreSQL 16 (core‑Schema, Indizes, Window‑Funktionen).
• Metabase (BI/Dashboards).
• Datenquellen: OpenFIGI, Stooq, Alpha Vantage, (SEC/SimFin/FMP vorbereitet).
• Protokolle/Formate: HTTPS/JSON/CSV, ISO‑Datum, EUR‑Basis.
• Benachrichtigung: Webex Bot API.

Architekturentscheidungen (ADR‑Index)

• ADR‑001: Zentrale DB = PostgreSQL (statt n8n Data Tables)
  • Warum: SQL/Indizes/Window‑Funktionen, BI‑Zugriff, Historien/Backups, Trennung von Workflow‑State und Daten.
  • Betroffene Artefakte: db mf_app; Schema core/*.
• ADR‑002: Listings über OpenFIGI, Primärlisting automatisch XETR (falls DE‑ISIN) bzw. MIC‑basiert
  • Warum: Eindeutige Mappings, minimiert Ticker‑Ambiguitäten; konsistente Preisquelle.
  • Artefakte: n8n Workflow „mf_workflow – Add Security…“; Node „OpenFIGI: ISIN → XETR mapping“.
• ADR‑003: Preise primär Stooq, Fallback Alpha Vantage (compact)
  • Warum: Free, stabil; AV mit Quoten, deshalb nur kompakt.
  • Artefakte: Nodes „Stooq: Daily CSV (full)“, „AlphaVantage: Daily (compact, JSON)“.
• ADR‑004: Indikator‑Set v1 = SMA200 (mit 1% Puffer), 52W‑High, 3‑Tage‑Hoch, Drawdown
  • Warum: Robust, interpretierbar, wenig Rauschen.
  • Artefakte: SQL „PG: Update indicators (SMA200/52W/3D)“.
• ADR‑005: Preis‑Trigger v1 (ohne MF) + Hysterese/Cool‑down‑Design
  • Warum: Rauschreduzierung, klare Einstiege; später MF/Marktfilter ergänzbar.
  • Artefakte: „PG: Compute signal (price‑only test)“, Tabelle core.signals.
• ADR‑006: Marktfilter als Hybrid über F&G; Proxy via VIX (vi.c) mit linearem Mapping
  • Warum: CNN‑Original unsicher/flexibel; Proxy stabil; Hybrid möglich.
  • Artefakte: Workflow „Market State Update“, Nodes „VIX Fetch“, „VIX Parse“, „Market State Upsert“; Tabelle core.market_state.
• ADR‑007: KI‑Analyse nur manuell (Button), keine Auto‑Läufe
  • Warum: Datensparsamkeit, Kontrolle, Vermeidung von Fehlinformationen.
  • Artefakte: Tabelle core.aievaluations, newscache (für Headlines).
• ADR‑008: Magic‑Formula monatlich, regionale Ränge (USA voll; DE/UK best‑effort mit Confidence)
  • Warum: Datenverfügbarkeit; klare Periodizität; Kennzeichnung Datenqualität.
  • Artefakte: Tabellen core.fundamentals, core.mf_rank (Confidence‑Feld).

Annahmen und Nicht‑Ziele

• Annahmen:
  • Tägliche EOD‑Preise ausreichend (kein Intraday‑Need).
  • XETR‑Preise in EUR decken Anwendungsfälle ab (Basiswährung EUR).
  • VIX‑Proxy repräsentiert grob den F&G‑Zyklus für Filterzwecke.
  • SEC/SimFin/FMP liefern genügend Fundamentals für v1‑Regionen (USA voll, DE/UK best effort).
• Nicht‑Ziele:
  • Kein Auto‑Trading; keine Portfolio‑Optimierung/Positionsgrößen im Systemkern.
  • Keine proprietären Premium‑Datenquellen.
  • Kein komplexes Event‑Processing (News Echtzeit, NLP‑Streams) im Dauerbetrieb.
  • Kein umfassendes Backtesting‑Framework innerhalb n8n (später optional extern).