Ein Ladevorgang wurde auf 7 kW gedrosselt
Eine Tatsache, in der Vergangenheit und in Ihren Worten. Nichts wird je überschrieben: Die ganze Geschichte bleibt, und jede spätere Frage lässt sich daraus beantworten.
Architektur
Software, die mit Ihrem Geschäft Schritt hält
Reventless hilft Ihnen, Geschäftssoftware schneller zu bauen, über Jahre wartbar zu halten, jede Entscheidung lückenlos nachvollziehbar zu machen — und kostengünstig zu betreiben. So funktioniert das.
Das Problem
Software, die echte Geschäftsabläufe steuert — Geld-, Vertrags-, Waren- oder Genehmigungsprozesse — wird mit der Zeit schwerfällig. Änderungen dauern immer länger und werden riskant. Niemand kann mehr lückenlos nachweisen, wer wann was geändert hat — ein echtes Problem für Prüfung, Revision und Compliance. Ein großer Teil der Entwicklungszeit fließt in technisches Drumherum statt in das Produkt. Und die Kosten für Entwicklung und Betrieb steigen.
Die übliche Antwort: mehr Prozesse, mehr Infrastruktur, mehr Spezialisten. Reventless geht den umgekehrten Weg: weniger Technik, die im Weg steht.
Die Idee: Ihre Domänenbeschreibung ist die Spezifikation
Mit Reventless beschreibt Ihr Team, was die Software fachlich können soll — die Commands, die Menschen auslösen, die Events, die passieren, die Sichten, die gebraucht werden. Diese Beschreibung entsteht in ReScript, einer Sprache, deren Typsystem wie geschaffen für Domänenmodellierung ist — und sie wird vom Compiler geprüft, nicht von einer Wiki-Seite.
Alles Weitere wird daraus abgeleitet: Datenbankschemata, GraphQL-APIs, MCP-Server-Schemata, AWS-Infrastruktur. Eine Quelle der Wahrheit, kein Glue-Code, keine Abweichungen zwischen den Schichten. Spezifikation ändern, System neu generieren.
Die Spezifikation ist das System
Commands, Events und Ansichten werden in einer typsicheren Spezifikation definiert. Reventless leitet den Rest daraus ab — Datenbankschemata, GraphQL-APIs, MCP-Server, Cloud-Infrastruktur. Spezifikation ändern, System neu generieren.
// Customer.res — the spec
@@reventless.spec
@schema
type command =
| Register({email: string, address: string})
| UpdateEmail({email: string})
| Deactivate
@schema
type event =
| Registered({email: string, address: string})
| EmailUpdated({email: string})
| Deactivated
@schema
type state = {
email: string,
address: string,
active: bool,
}# Generated GraphQL API — one of four surfaces
type Mutation {
register(email: String!, address: String!): CommandResult!
updateEmail(id: ID!, email: String!): CommandResult!
deactivate(id: ID!): CommandResult!
}
type Customer {
email: String!
address: String!
active: Boolean!
}
type Query {
customer(id: ID!): Customer
customers: [Customer!]!
}- Event Store
- GraphQL-API
- MCP-Server
- Cloud-Infrastruktur
Jede Entscheidung dokumentiert
Reventless speichert nicht nur den aktuellen Stand Ihrer Daten — es hält jede einzelne Änderung als unveränderbares Ereignis fest. Nichts wird überschrieben, nur ergänzt: wie in einem Kassenbuch. Daraus ergibt sich von selbst eine vollständige, jederzeit nachvollziehbare Historie Ihres Geschäfts — für Prüfung, Streitfälle, Compliance, und für die Fehlersuche, weil sich exakt nachspielen lässt, was passiert ist.
Dieses Muster heißt Event Sourcing. Es ist seit Langem die richtige Architektur für ernsthafte Geschäftssoftware — und ebenso lange ein Luxus für Spezialisten. Reventless existiert, um es zum Standard zu machen: zugänglich, produktionsreif und bewusst meinungsstark, damit Ihr Team keinen Experten für verteilte Systeme einstellen muss.
Aus unabhängigen Slices gebaut
Systeme bestehen aus Slices — in sich geschlossenen vertikalen Features, die ihre Commands, Events und Ansichten selbst besitzen, nach dem Event Modeling-Ansatz. Slices kommunizieren über Events, nicht über direkte Abhängigkeiten: Teams können sie unabhängig entwickeln, testen und deployen, neue hinzufügen, ohne bestehende anzufassen — und einzelne ändern, ohne Wellen durch die Codebasis zu schlagen.
Kein Betriebsaufwand
Reventless-Anwendungen laufen konstruktionsbedingt serverless — heute auf AWS Lambda, DynamoDB und AppSync, weitere Ziele sind geplant. Keine Cluster dimensionieren, keine Server, die nachts leerlaufen, kein Patch-Dienstag. Sie zahlen nach tatsächlicher Nutzung — wie Strom nach Zähler statt Pauschale. Und Infrastruktur ist kein nachträglich gepflegtes Skript: Deployments werden mit dem Code generiert.
Bereit für KI
Jede Reventless-Anwendung liefert automatisch einen MCP-Server mit: Ihre Geschäftsprozesse werden zu Werkzeugen, die ein KI-Assistent sicher bedienen kann. Die strengen Typverträge machen die Plattform außerdem zu einer besonders verlässlichen Basis für KI-gestützte Entwicklung — generierter Code wird sofort vom Compiler validiert. Und ein event-basiertes System erzeugt genau die vollständigen, geordneten, strukturierten Daten, die KI- und Analyse-Workloads brauchen.
Erprobt, offen, Ihres
- Über sechs Jahre in Produktion. Die Entwicklung des Reventless-Frameworks begann 2019, und es hat über sechs Jahre lang Anwendungen in Produktion in der Finanzbranche betrieben. Seit 2026 ist dasselbe Framework Open Source, und seine Entwicklung geht offen weiter.
- Open Source, kein Lock-in. Reventless ist Open Source und läuft im eigenen Cloud-Konto. Kein Abo-Zwang, keine Daten in fremder Hand. Das Framework lebt auf reventless.dev.
- Resilient im Kern. Die Plattform baut auf Effect: typisierte Fehlerbehandlung, automatische Retries mit Backoff und Streaming-Datenflüsse, um große Event-Historien effizient zu verarbeiten.
Passt Reventless zu Ihnen?
Gut geeignet, wenn Sie:
- ein Unternehmen mit eigener, individueller Software und komplexen Geschäftsabläufen sind,
- in einer regulierten Branche arbeiten (Versicherung, Gesundheit, Logistik), in der Nachvollziehbarkeit zählt,
- ein wachsendes Tech-Unternehmen sind, das schnell liefern und in fünf Jahren noch beherrschbar bauen will.
Weniger geeignet für reine Marketing-Websites, Standard-Webshops oder Anwendungen ohne nennenswerte Geschäftslogik.
Für die technische Tiefe — Konzepte, Tutorials, API-Referenz — geht es zu reventless.dev. Um herauszufinden, was Reventless für Ihr System bedeuten würde: arbeiten Sie mit uns, oder beginnen Sie mit dem Überblick über das Open-Source-Framework.
Die Bausteine
Jede Beschreibung, so groß das Geschäft auch ist, besteht aus drei Arten von Zeilen. In Ihren eigenen Worten geschrieben, wird jede zu einem Teil der Software.
Nur ein flexibler Ladevorgang darf gedrosselt werden
Eine Regel, die aus dem bisher Geschehenen sagt, ob etwas getan werden darf und was dann geschieht. Ihre Beispiele legen sie fest und laufen als Tests.
Der Betrieb sieht alle Ladevorgänge im Netzgebiet; ein Fahrer nur seine eigenen
Was eine Person auf dem Bildschirm braucht, von selbst aktuell gehalten, während etwas geschieht, und nur denen gezeigt, die es sehen dürfen.
Größere Bausteine für größere Systeme
Dieselben drei Arten von Zeilen, gruppiert, wenn das Geschäft wächst. Jeder Baustein bleibt klein genug, um ihn für sich zu verstehen und zu prüfen.
Eine Zeile, als Software
Jede Zeile der Beschreibung wird zu einem Teil: einer Entscheidung mit dem, was sie festhält, oder einer Ansicht. Amperias „Ladevorgang drosseln“ ist ein Teil.
Ein Stück eines Prozesses, beisammen gehalten
Teile, die zusammengehören: alles rund um Netzanfragen, vom Anfragen über das Beantworten bis zum Abrechnen.
Eine Aufgabe des Geschäfts
Mehrere Kapitel mit einem Zweck, die ein Team besitzen kann und die eigenständig laufen. Amperia hat zwei: Laden und Flexibilität.
Was zwischen Systemen hin und her geht
Systeme sprechen nur über einen Vertrag miteinander. Laden meldet, wann Ladevorgänge beginnen und enden; Flexibilität bittet es, einen Ladevorgang zu drosseln. Laden erfährt nie von einer Netzanfrage.
Die Systeme zusammen
Amperia sind zwei Systeme und der Vertrag zwischen ihnen, aus einer Beschreibung. Eine neue Aufgabe des Geschäfts wird ein neues System neben den anderen.
Weil jeder Baustein klein ist und für sich geprüft wird, bleibt eine Änderung dort, wo sie hingehört, Teams können nebeneinander arbeiten, und fertige Bausteine jeder Größe lassen sich vom Marktplatz übernehmen oder dort anbieten.
In den Begriffen des Frameworks
- Was geschieht
- ein Event
- Was entschieden wird
- ein Command und seine Entscheidung, mit den Events, die sie erzeugt
- Was jemand sehen muss
- eine Ansicht (View), aus den Events gebaut
- Teil
- ein Slice: ein Command mit seiner Entscheidung oder eine Ansicht
- Kapitel
- ein Ordner von Slices innerhalb eines Plugins
- System
- ein Plugin, ein eigenständig deployter Bounded Context
- Vertrag
- die Events und Anfragen, die ein Plugin für ein anderes veröffentlicht, mit einer Übersetzung auf jeder Seite
- Die Anwendung
- die Plattform, auf die die Plugins deployt werden
Finden Sie heraus, ob Reventless passt
Ein kurzes Gespräch genügt, um zu sehen, ob Ihr Geschäftsprozess und Reventless zusammenpassen — unverbindlich.
Kostenloses 30-Minuten-Erstgespräch — unverbindlich.