Fallstudien

Nutzer mussten Asset-Trades und Bankauszahlungen direkt in der Anwendung durchführen können. Beide Abläufe ähneln sich an der Oberfläche, haben aber völlig unterschiedliche Geschäftslogik, Validierungsregeln, Datenmodelle und Backend-Operationszustände, was eine gemeinsame Implementierung unpraktisch machte.

Ich habe sie bewusst nicht hinter einer Abstraktion vereinheitlicht. Die oberflächliche Ähnlichkeit hätte in jedem Schritt bedingte Verzweigungen erzwungen, und die beiden Abläufe haben keinen Grund, sich gemeinsam zu ändern. Stattdessen habe ich zwei unabhängige, dreistufige Abläufe gebaut: ein Trading-Modal für Kauf und Verkauf von Assets sowie ein System für Bankauszahlungen, jeweils mit eigenen Zod-Schemata, eigener State-Machine und Fehlerbehandlung. Beide reagieren auf echte Backend-Bestätigungen über WebSockets, nicht nur auf die Antwort der ersten Anfrage, denn eine Anfrage mit Status 200 bedeutet nicht, dass das Geld bewegt wurde.

Beide Abläufe behandeln Randfälle korrekt, darunter fehlgeschlagene Transaktionen, ausstehende Zwischenzustände und Netzwerkunterbrechungen. Weil sie getrennt sind, lässt sich jeder ändern, testen und nachvollziehen, ohne den anderen anzufassen, was sich bereits ausgezahlt hat, als der Trading-Ablauf fortgeschrittenere Ordertypen erhielt.