So funktioniert „VenduSys
“ tatsächlich.
VenduSys ist weder ein Monolith noch ein Schwarm von Microservices. Es handelt sich um eine kleine Gruppe benannter Dienste mit expliziten Verträgen, die hinter einer einheitlichen API stehen und in der EU bereitgestellt werden. Diese Seite bietet einen ehrlichen Überblick.
Case-to-Core™ ist das Rückgrat des Lernprozesses, durch das ein Ökosystem sich selbst zunehmend verständlich wird – und durch das Signale, Wissenslücken, Unsicherheiten und Möglichkeiten kontinuierlich neue Fragestellungen anregen.
Vom Netzwerk zum
Ledger.
Jede Schicht ist ein kleiner, benannter Dienst mit einem expliziten Vertrag. Sie können den gesamten Stack übernehmen oder jede einzelne Schicht durch eine eigene ersetzen und den Rest beibehalten.
Vier Entitäten.
Alles andere ergibt sich daraus.
Wir haben das Modell in einem separaten Beitrag beschrieben. Die Kurzfassung finden Sie unten.
Party
Personen, Organisationen, Akteure. Käufer, Verkäufer, Betreiber, Partner – allesamt Projektionen desselben Datensatzes. Identität ist ein Graph, kein Typ.
Ding
Alles, was angeboten wird oder im Besitz ist. Produkte, Lizenzen, Dienstleistungen, Abonnements, Vermögenswerte, Zeit. Varianten und Bundles kommen noch hinzu.
Verschieben
Ereignisse, die zu einer Verschiebung von Werten oder Rechten zwischen den Parteien führen. Bestellungen, Rücksendungen, Verlängerungen, Übertragungen und Streitfälle sind allesamt Vorgänge, die über Zustandsmaschinen abgewickelt werden.
Eintrag
Zeilen im Hauptbuch. Das Modell ist so konzipiert, dass jede „Bewegung“ Buchungen erzeugt, aus denen sich Berichte und Salden ableiten lassen.
Jeder Fluss
ist beobachtbar.
Einträge, Genehmigungen, Auszahlungen, Rückgaben, Verlängerungen – als Code oder visuelle Diagramme modelliert. Verzweigen, erneut versuchen, wiederholen, prüfen. Der Status wird gespeichert; nichts wird einfach „abgeschickt und vergessen“.
- EVT Domänenereignis
- CRON Geplant
- API Direkter Aufruf
- WHK Externer Webhook
- CDC Änderung an der Datenbank
- Diagramm erstellenPARSE
- Zustand beibehaltenSTATE
- Schritte der AuftragsabwicklungRUN
- Wiederholungsversuche verarbeitenRETRY
- Prüfprotokoll ausgebenAUDIT
- DB Buchungseinträge
- PAY Zahlung / Auszahlung
- MSG Benachrichtigung
- EXT Anruf über den Connector
- EVT Nachgelagertes Ereignis
Was man zum Laufen braucht.
Die langweiligen Details – Hosting, Residency, RPO/RTO, Observability. Die Dinge, auf die es ankommt, wenn sonntags um 2 Uhr morgens etwas schiefgeht.
- Hosting
- Vercel für den API-Edge · dedizierte EU-Cluster für zustandsbehaftete Dienste (Paris)
- Lagerung
- Postgres (Supabase) mit logischer Replikation · S3-kompatibler Objektspeicher · pgvector für Embeddings
- Replikation
- Multi-AZ innerhalb einer Region · regionenübergreifende Lesereplikate · CDC-Stream zum Data Warehouse
- Ausfallsicherung
- RPO 0 · RTO 5 Minuten für Ledger und Identität · 15 Minuten für den Katalog
- Beobachtbarkeit
- OpenTelemetry standardmäßig · mandantenbezogene Traces · strukturiertes Audit-Protokoll · Workflow-Wiedergabe
- Verschlüsselung
- TLS 1.3 bei der Übertragung · AES-256 bei der Speicherung · BYOK in der Enterprise-Version · Schlüsselisolierung pro Mandant
- Wohnsitz
- EU als Standard · Festlegung der Region in Scale/Enterprise · Audit-konforme Datenausgabe