4. Entwurfsphase

4.1 Soll-Konzept

Das Soll-Konzept sieht eine dreistufige Verarbeitung der Quelldaten vor:

• Extraktion und Normalisierung im Backend.
• Persistierung in der Datenbank.
• Strukturierte Darstellung im Frontend.

Aus diesem Konzept wurde ein technisches Pflichtenheft abgeleitet, welches die genauen Implementierungsrichtlinien und Beschränkungen (z. B. maximale Zeichenlängen) definiert. Das vollständige Pflichtenheft ist in Anhang D.1 dokumentiert.

4.2 Datenbankmodellierung

Eine zentrale Architekturentscheidung betraf die persistente Speicherung der Quelldaten. Anstelle einer klassischen relationalen Modellierung (z. B. einer eigenen Tabelle MessageSource mit Fremdschlüssel) fiel die Entscheidung auf die Erweiterung der Entität Message um ein optionales JSON-Feld (sources Json? - in PostgreSQL als jsonb umgesetzt).

4.2.1 Begründung

Die AuxData-Schnittstelle liefert Quelldaten in hochgradig variablen und nicht garantierten Formaten. Ein starres relationales Schema hätte diese Flexibilität stark eingeschränkt. Das jsonb-Format in PostgreSQL ermöglicht es, unstrukturierte Daten performant zu speichern und bei Bedarf zu indexieren. Zudem sichert die Optionalität des Feldes (?) die vollständige Rückwärtskompatibilität zu bestehenden Chat-Nachrichten, ohne dass komplexe Datenmigrationen notwendig wurden. Das aktualisierte Entity-Relationship-Modell ist in Anhang D.2 visualisiert.

4.3 Schnittstellen- und Typenentwurf

Um Typ-Sicherheit über die gesamten Systemgrenzen hinweg zu gewährleisten, wurden zentrale TypeScript-Interfaces definiert (siehe Anhang D.3).

Besonders hervorzuheben ist die Modellierung der Server-Sent Events (SSE). Der Typ ChatStreamEvent wurde als Discriminated Union umgesetzt. Diese Designentscheidung zwingt den TypeScript-Compiler beim Auswerten der Events im Frontend dazu, das Exhaustiveness Checking anzuwenden. So wird auf Compiler-Ebene garantiert, dass alle möglichen Event-Fälle – insbesondere das neu eingeführte sources-Event – im Code zwingend behandelt werden.