Architektur
SunStack ist als integrierte Plattform gebaut, nicht als Sammlung verbundener Tools. Diese Seite erklärt die drei Konzepte, die alles andere bestimmen: das zentrale Datenmodell, die Sicherheitszonen und die Modul-Architektur.
Das zentrale Datenmodell
Alle Module arbeiten auf einer PostgreSQL-Datenbank mit einem zentral versionierten Schema (~520 Datenmodelle). Jedes Modul hat seinen eigenen Tabellen-Namensraum, teilt sich aber die Kern-Entitäten:
| Entität | Bedeutung |
|---|---|
Party | Zentrale Identität für jede Person und Firma — Kunde, Investor, Mitarbeiter, Lieferant, Verpächter. Rollen statt Duplikate: Dieselbe Person kann gleichzeitig Verpächter und Investor sein und bleibt ein Datensatz. Die Buchhaltung referenziert die Rolle, nicht die Person — so bleiben Debitoren-/Kreditoren-Beziehungen sauber. |
PowerPlant | Eine PV-Anlage mit eindeutigem Code. Der Code ist der Verbund-Schlüssel über alle Module: Ordnernamen, Kostenstellen, Tickets, Monitoring, Verträge. |
SubPlant | Teilanlage: eine Wechselrichter-Gruppe als Eigentumseinheit. Macht wechselrichtergenaue Beteiligungen verkaufbar und abrechenbar. Eine harte Invariante verhindert, dass Anteile in irgendeiner Periode 100 % überschreiten. |
Ticket | Gemeinsamer Vorgangs-Kern für Kundenservice, IT, Bau und persönliche Aufgaben — mit strikter Sichtbarkeits-Trennung (Herkunft und Sichtbarkeit sind Teil des Datenmodells, nicht der UI). |
Warum das wichtig ist
„Integriert“ heißt bei SunStack nicht „synchronisiert“. Es gibt keine Sync-Jobs zwischen Vertriebs-CRM und Buchhaltung, die auseinanderlaufen können — es ist dieselbe Zeile in derselben Datenbank. Eine Anlage, die im Vertrieb verkauft wird, ist dieselbe Entität, die im Bau errichtet und im Betrieb überwacht wird.
Sicherheitszonen & DMZ
SunStack trennt strikt zwischen internen Modulen und allem, was im Internet steht:
- Interne Module (Vertrieb, Finanzen, Bau …) sind nur aus dem internen Netz bzw. per IP-Allowlist erreichbar.
- Öffentliche Apps (Kundenportal, Investorenportal, Academy, Angebotsannahme, Landing-Pages) laufen als True-DMZ-Apps: ohne Datenbankverbindung, ohne API-Schlüssel, ohne Geheimnisse. Sie erreichen Daten ausschließlich über das API-Gateway.
- Outbound-only-Tunnel: Öffentliche Erreichbarkeit entsteht über Tunnel, die von innen nach außen aufgebaut werden — am Firmennetz ist kein Port geöffnet.
Das API-Gateway
Das Gateway ist die eine Tür zwischen öffentlicher Zone und Daten. Seine Sicherheits-Invarianten gelten in jedem Endpunkt:
- Signaturprüfung: Jede Anfrage aus der DMZ wird per HMAC verifiziert, bevor irgendetwas passiert.
- Explizites Field-Picking: Es wird nie eine Datenbankzeile ungefiltert ausgeliefert — jedes Feld einer Antwort ist bewusst gewählt.
- Kein Existenz-Orakel: Fremde oder unsichtbare IDs liefern immer „nicht gefunden“ — ein Angreifer kann nicht einmal erfahren, ob etwas existiert.
- Ownership bei jedem Zugriff: Eigentum wird beim Download erneut geprüft, nicht nur beim Auflisten.
- Fail-closed CORS: Keine konfigurierte Freigabe bedeutet: nichts ist erlaubt.
Authentifizierung & Sessions
- Mitarbeiter: SSO über Microsoft Entra ID (Single-Tenant) mit automatischer, dubletten-sicherer Provisionierung; alternativ Passwort-Login. Rollen werden pro Anfrage geprüft — Entzug wirkt sofort.
- Modulübergreifende Sitzung: Ein zentral signiertes Sitzungs-Cookie verbindet die Module; nur der Hub kann es ausstellen. Ein Frische-Check verhindert, dass ein Benutzerwechsel am selben Gerät alte Identitäten weiterträgt.
- Kunden & Investoren: eigene Konten mit gleitender Sitzungs-Gültigkeit bzw. Magic-Link-Login (kurzlebig, einmalig nutzbar, ohne Konto-Enumeration).
- Maschinen: Automationen und Services authentifizieren sich mit eigenen, eng gescopten Token — ein Token für Belegabruf kann nie überweisen.
Module & Services
Jedes Modul ist eine eigene Web-Anwendung (TypeScript/Next.js) hinter einem gemeinsamen Reverse-Proxy — ein Ausfall oder Update eines Moduls berührt die anderen nicht. Rechenintensive oder spezialisierte Aufgaben übernehmen dedizierte Services:
| Service | Aufgabe |
|---|---|
| Dokument-Extraktion | PDF-Verarbeitung mit 97 Vendor-Extraktoren, OCR, Kontoauszugs-Parsing, Seiten-Split |
| Banking (FinTS) | Kontoabruf, SEPA-Überweisungen/-Lastschriften, TAN-Verfahren, verschlüsselter PIN-Vault |
| Beleg-Workflow | Posteingangs-Pipeline: Trennen, Umbenennen, Prüfen, Zahlungsvorbereitung |
| Ertragssimulation | PV-Ertragsberechnung für Planung und Kalkulation (mit Warteschlange) |
| Behörden-Automatisierung | Browser-Automatisierung für Registerprozesse — assistierend, nie eigenmächtig einreichend |
| Grundbuch-Parser | OCR und Strukturierung von Grundbuchauszügen (Bestandsverzeichnis, Abteilungen I–III) |
| PDF-Rendering | HTML-zu-PDF für Berichte, Protokolle und Belege |
Alle Integrationen sind optional-degradierend: Fehlt eine Konfiguration, ist das jeweilige Feature deaktiviert — die Plattform läuft weiter, statt zu crashen.
Automations-Engine
- Automationen sind versionierte Code-Module mit Pflicht-Dokumentationsblock: was sie tut, was sie nicht tut, was ein leerer Lauf bedeutet.
- Ausführung mit Datenbank-Lock (genau ein Worker), Laufprotokoll und Logs je Lauf.
- Drei Ausgänge: Erfolg, Fehler — und „Prüfen“ (NEEDS_REVIEW) für Läufe, die technisch durchliefen, aber menschliche Kontrolle verdienen.
- Not-Aus je Automation plus globaler Kill-Switch; geldbewegende Automationen benötigen zwei Freigaben und starten im Shadow-Mode.
Datei- & Mail-Disziplin
- Storage-Pflicht: Sämtliche Datei-Ein-/Ausgabe läuft über eine zentrale Storage-Schicht (SharePoint/OneDrive in Produktion) — kein Modul schreibt „irgendwohin“.
- Mail-Pflicht: Versand nur über den zentralen Mailer (mit Templates und Protokoll), Empfang über die zentrale Mail-Ingestion — eine Stelle für Zustell-Nachweise und Fehlersuche.
- GoBD: Archivierte Belege sind unveränderlich (Hash-gesichert); nachträgliche Text-Layer entstehen als Sidecar-Dateien, das Original bleibt byte-identisch.