Financial-View
Self-hosted Personal-Finance- und Vermögens-Management-System mit Banking-, Krypto- und Depot-Anbindung
Überblick
Financial-View begann 2017 als CSV-Auswertung für Bankumsätze. 2026 habe ich es von Grund auf neu gebaut: aus dem Haushaltsbuch wurde ein vollständiges Personal-Finance- und Vermögens-Management-System, das ich selbst hoste und täglich nutze. Es führt Girokonten, Umsätze, Kategorien und Budgets zusammen und ergänzt sie um eine Gesamtvermögens-Sicht über Bargeld, Krypto (Binance, externe Wallets) und Wertpapierdepots (Trade Republic, weitere Broker). Technisch ist es ein nach Domain-Driven Design geschnittenes Spring-Boot-4-Backend (Java 25), ein Next.js-16-Frontend mit striktem BFF-Pattern (kein Token landet je im Browser) und ein read-only Python-Sidecar, der die fragile Trade-Republic-Schnittstelle kapselt. Geldbeträge sind durchgängig als BigDecimal modelliert, der Datenzugriff dreifach gegen Fremdzugriff abgesichert, die Oberfläche zweisprachig und dark-first.
Der Anspruch war nicht, das alte Tool zu portieren, sondern es richtig zu machen: Architektur-Tests sichern die Schichtgrenzen ab Tag eins, die FinTS-Banking-Anbindung liest ausschließlich (ein Quellcode-Test erzwingt das), und ein Integrations-Audit protokolliert jeden Aufruf an externe Börsen- und Bank-APIs. Gewachsen ist das System über acht aufeinander aufbauende Entwicklungswellen, von Konten und Kategorien bis zur stündlichen Vermögens-Momentaufnahme.
Tech Stack
Architektur-Highlights
- BFF-Pattern: Tokens leben ausschließlich serverseitig im verschlüsselten httpOnly-Cookie, der Browser sieht nie ein Token. Jeder Zugriff läuft über einen Next.js-Route-Handler, der serverseitig refresht und genau einmal nachsetzt.
- Backend nach Domain-Driven Design mit hexagonalen Schichten je Bounded Context, ab Tag eins durch eine ArchUnit-Test-Suite (Layering, Repository-Pattern, User-Scoping) erzwungen.
- Geld konsequent als BigDecimal-Value-Objekt: Float-Beträge sind per Architektur-Test verboten, Summen entstehen ausschließlich über SQL, an den API-Grenzen wird als String übergeben.
- Dreischichtiges User-Scoping in einer einzigen Datenbank: ThreadLocal-Kontext aus dem JWT, explizites user_id-Prädikat in jedem Repository und ein Hibernate-Filter als Sicherheitsnetz.
- Trade Republic in einen read-only Python-Sidecar ausgelagert, der WAF-Token, WebSocket und 2FA vom Java-Backend entkoppelt und externe Aufrufe fail-soft behandelt.
- Eigene OKLCH-Design-Token-Pipeline und Tailwind v4 im CSS-First-Ansatz erzeugen ein konsistentes, dark-first Theme samt sRGB-Fallbacks für die Charts.
Kernfunktionen
- Haushaltsbuch mit Konten, Umsätzen (manuell, Import, Split), rekursivem Kategoriebaum und Buchungspartnern
- Regelbasierte Auto-Kategorisierung mit Bedingungsgruppen, Vorschau und Anwenden auf den Bestand
- Budgets und ein Dashboard mit Cashflow-Trend, Top-Kategorien und konkreten Handlungsbedarfen
- Gesamtvermögen über Bargeld, Krypto (Binance, externe Wallets) und Wertpapierdepots mit stündlichen Snapshots
- Trade-Republic-Anbindung über einen separaten Python-Sidecar inklusive 2FA-Login
- FinTS/HBCI-Banking und CSV-Import, beide strikt lesend, mit Duplikat-Erkennung
- Verläufe und Charts (Kontostand, Kategorien, Monatsgradient) mit editierbaren Notizen
- Zweisprachig (Deutsch/Englisch) mit lokalisierten URLs, dark-first, plus app-weiter Datenschutz-Schalter für alle Beträge
Herausforderungen & Lösungen
- Die inoffizielle Trade-Republic-Schnittstelle hält einen Session-Token nur rund 290 Sekunden und kappt den Refresh-Pfad etwa zwei Stunden nach dem Login: gelöst durch einen Sidecar mit proaktivem Refresh und WebSocket-Reconnect.
- Geldbeträge müssen über drei Sprachen (Java, TypeScript, Python) konsistent bleiben: durchgängige String-Repräsentation an den Grenzen, die BigDecimal-Interpretation passiert nur im Backend.
- Mandantentrennung in einer einzigen Datenbank, nachdem der Hibernate-Filter nicht überall zuverlässig griff: abgesichert als Defense-in-Depth mit explizitem user_id-Prädikat plus Filter als Sicherheitsnetz.
- OKLCH-Farben rendern in headless Chromium fehlerhaft in SVG-Charts: separate sRGB-Fallback-Tokens lösen das Darstellungsproblem.
- Banking soll nie Geld bewegen: die FinTS-Anbindung ist hart auf Lese-Operationen beschränkt, ein Quellcode-Test verhindert jeden schreibenden HBCI-Aufruf.