Mit Version 5.0.0 baut La Suite Docs vor allem seine Dokument-API um. Der größte Einschnitt: Inhalt und Metadaten eines Dokuments sind nun getrennt. Laut den offiziellen Release Notes und der Upgrade-Anleitung heißt der bisherige Content-Pfad jetzt formatted-content, das Feld content fällt aus der regulären Dokumentantwort weg und für Lesen sowie Schreiben kommen eigene Endpunkte hinzu. Für bestehende API-Clients ist das ein Breaking Change.

La Suite Docs ist ein quelloffener Editor für die Zusammenarbeit von Teams und versteht sich als souveräne Alternative zu Notion oder Google Docs. Zielgruppen sind öffentliche Einrichtungen ebenso wie Unternehmen. Hinter dem Projekt stehen das deutsche Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS) und die französische Interministerielle Behörde für Digitales (DINUM).

Inhalt und Metadaten getrennt

Den Grund für den harten Schnitt nennen die Entwickler im Commit d7a186a. Bisher liefen Inhaltsänderungen über denselben Update-Endpunkt wie andere Dokumenteigenschaften. Selbst beim simplen Umbenennen lieferte der Server den kompletten Inhalt mit aus – und griff dafür unnötig auf den im S3-Speicher abgelegten Dokumentzustand zu. Dafür gibt es jetzt einen eigenen Endpunkt: PATCH /api/v1.0/documents/{document_id}/content/. Die Upgrade-Anleitung zeigt als erwartete Payload ein Base64-codiertes Feld content. Ist der übergebene Dokumentzustand ungültig, antwortet der Server mit 400 Bad Request und der Fehlermeldung invalid yjs document. Wer nur Metadaten wie Titel oder Sichtbarkeit ändert, muss damit nicht mehr den eigentlichen Dokumentinhalt mitschleppen.

Auch zum Lesen gibt es einen eigenen Endpunkt. GET /api/v1.0/documents/{document_id}/content/ streamt den Inhalt laut Upgrade-Anleitung als text/plain. Der Commit 6b3d197 zeigt, dass dafür StreamingHttpResponse und 8192 Byte große Chunks zum Einsatz kommen. Fehlt die Datei im Storage, liefert der Endpunkt trotzdem HTTP 200 mit leerem Body. Die Tests im selben Commit dokumentieren auch die Zugriffsmatrix: Anonyme Nutzer dürfen öffentliche Dokumente abrufen; für nicht öffentliche Dokumente erhalten sie 401. Authentifizierte Nutzer ohne Berechtigung bekommen bei restricted ein 403. Im Code spricht das Projekt von „raw Yjs content“. Yjs ist eine Bibliothek für Echtzeit-Kollaboration, die gemeinsame Datentypen automatisch synchronisiert. Der Endpunkt liefert also eher den kollaborativen Rohzustand eines Dokuments als ein fertig gerendertes Austauschformat.

Konverter und KI-Anbindung umgebaut

Für Selfhoster dürfte die zweite große Nachricht das Upgrade des Konvertierungsdiensts auf DocSpec 3.0.x sein. Pull Request #2220 hält ausdrücklich fest, dass das Docker-Image ghcr.io/docspecio/api:3.0.0 gemeinsam mit dem Anwendungscode aktualisiert werden muss. Das neue Request-Format ist nicht abwärtskompatibel; wer nur eine Seite aktualisiert, riskiert Ausfälle bei der Dokumentkonvertierung. Derselbe Pull Request beschreibt ferner die technische Umstellung: Statt eines Multipart-Uploads schickt der Client den Dokumentinhalt jetzt direkt im Request-Body und setzt Content-Type und Accept explizit. Wer eigene Compose-, Helm- oder Kubernetes-Setups pflegt, muss den Konverter also fest in den Major-Upgrade-Plan einplanen.

Neu ist außerdem eine Mistral-Anbindung für die neue KI-Pipeline. Der Commit b6efac3 führt eine Provider-Auswahl ein, die je nach Konfiguration entweder OpenAIChatModel oder MistralModel verwendet. In der Dokumentation der Umgebungsvariablen tauchen dafür OPENAI_SDK_API_KEY, OPENAI_SDK_BASE_URL, MISTRAL_SDK_API_KEY und MISTRAL_SDK_BASE_URL auf. Die Upgrade-Anleitung benennt zugleich die früheren Variablen AI_API_KEY und AI_BASE_URL in OPENAI_SDK_* um. Wichtig für Betreiber eigener KI-Infrastruktur: Der Mistral-Pfad funktioniert nur im Async-Betrieb mit uvicorn. Für Endanwender ändert sich damit zunächst wenig; die Neuerung zielt auf Installationen, die nicht ausschließlich OpenAI-kompatible Gegenstellen nutzen.

Kleinere Verbesserungen für Betrieb und Frontend

Daneben gibt es in Version 5.0.0 mehrere praxisnahe Updates für Betrieb und UI. Pull Request #2241 begründet den jetzt konfigurierbaren Forward-Auth-Header damit, dass Traefik andere Header-Namen verwendet; per Konfiguration lässt sich der auszulesende Header etwa auf HTTP_X_FORWARDED_URI setzen. Im Frontend wandert die Crisp-Hilfefunktion laut PR #2222 ins Hilfemenü – der bisherige Button habe Teile der App überlagert.

Hinzu kommen kleinere, aber nützliche Korrekturen: Angeheftete Dokumente sortiert das Backend laut PR #2028 nun nach updated_at absteigend und ungültige Verschiebeoperationen im Dokumentbaum quittiert der Server laut PR #2208 mit 400 Bad Request statt mit 500 Internal Server Error. Die Release Notes listen zudem mehrere Verbesserungen bei der Barrierefreiheit und kleinere Frontend-Fixes auf.

Unterm Strich ist Version 5.0.0 kein großes Feature-Release, sondern ein Backend- und Infrastruktur-Umbau mit spürbaren Folgen für API-Clients, Selfhoster und Betreiber eigener Zusatzdienste. Endanwender bekommen vor allem kleinere UI-Verbesserungen zu sehen. Für Integratoren bringt die neue Trennung zwischen Metadaten, formatiertem Inhalt und rohem Inhaltsstream dagegen einige Anpassungen mit sich.

(fo)

AWS hat seinen MCP-Server allgemein verfügbar gemacht. Der Dienst soll KI-Agenten und Coding-Assistenten kontrollierten Zugriff auf AWS-Ressourcen geben, ohne ihnen pauschal weitreichende Rechte einzuräumen. Über den verwalteten Remote-Server können Agenten AWS-APIs aufrufen und aktuelle AWS-Dokumentation zur Laufzeit abfragen. Der MCP-Server ist Teil des Agent Toolkit for AWS.

Das Model Context Protocol (MCP) ist ein offener Standard, über den KI-Anwendungen externe Werkzeuge, Datenquellen und Dienste anbinden können. Mit der Schnittstelle können KI-Modelle nicht nur auf ihre Trainingsdaten zurückgreifen, sondern bei Bedarf auch aktuelle Informationen abrufen und Funktionen nutzen.

Kompakter Werkzeugkasten gegen veraltetes Modellwissen

AWS will mit dem Dienst ein praktisches Problem vieler Coding-Agenten angehen: Bei AWS-Aufgaben verlassen sie sich oft auf veraltetes Modellwissen, kennen neuere Dienste nicht oder erzeugen zwar lauffähige, aber nicht produktionsreife Infrastruktur. Als Beispiele nennt AWS zu weit gefasste IAM-Policies oder die Tendenz, eher zur AWS CLI als zu CDK oder CloudFormation zu greifen.

Im Kern bietet der MCP-Server eine kleine, feste Zahl von Werkzeugen. Das Tool call_aws deckt mehr als 15.000 AWS-API-Operationen ab und nutzt dafür die vorhandenen IAM-Anmeldedaten. Über search_documentation und read_documentation können Agenten zudem aktuelle AWS-Dokumentation und Best Practices nachladen. Damit will AWS Halluzinationen reduzieren und Antworten näher an den aktuellen Stand der Plattform bringen.

Neue Funktionen: Sandbox für Python-Skripte

Mit der allgemeinen Verfügbarkeit kommen mehrere neue Funktionen hinzu. Der Server unterstützt jetzt IAM Context Keys, sodass sich Zugriffe feiner über reguläre IAM-Policies steuern lassen. Das Nachschlagen von Dokumentation funktioniert künftig ohne Authentifizierung. Auch der Token-Bedarf pro Interaktion sinkt nach AWS-Angaben – ein Punkt, der vor allem bei längeren, mehrstufigen Workflows ins Gewicht fällt.

Technisch am interessantesten ist das neue Tool run_script. Damit kann ein Agent kurze Python-Skripte serverseitig in einer Sandbox ausführen. Die Laufzeitumgebung übernimmt zwar die IAM-Berechtigungen des Nutzers, hat aber weder Netzwerkzugriff noch Zugriff auf das lokale Dateisystem oder eine Shell. So lassen sich mehrere API-Aufrufe in einem Schritt verketten, Ergebnisse filtern und auswerten, statt jeden Schritt einzeln über Tool-Aufrufe abzubilden. Praktisch wird das etwa, wenn ein Agent Konfigurations-, Inventar- und Tagging-Daten aus mehreren AWS-Diensten zusammenführen soll.

Skills ersetzen Agent SOPs

Aus Sicht von AWS ist der Wechsel von Agent SOPs zu Skills die wichtigste konzeptionelle Änderung. Skills sind kuratierte Handlungsanleitungen und Best Practices für typische Aufgaben, bei denen Agenten häufig Fehler machen. Die jeweiligen AWS-Service-Teams pflegen sie. Damit will AWS Agenten schneller zu korrekten Ergebnissen führen, die Liste verfügbarer Werkzeuge schlank halten und so Fehler, Halluzinationen und Token-Verbrauch senken.

Für Unternehmen rückt AWS Governance- und Compliance-Aspekte in den Vordergrund. Der Dienst trennt menschliche Nutzerberechtigungen klar von Agentenrechten. Über IAM-Policies oder Service Control Policies lässt sich etwa festlegen, dass ein Nutzer Ressourcen ändern darf, während derselbe Zugang über den MCP-Server auf Leseoperationen beschränkt bleibt. Für die Überwachung liefert AWS eigene CloudWatch-Metriken im Namespace AWS-MCP; CloudTrail protokolliert die API-Aufrufe zusätzlich.

Demo mit S3 Vectors zeigt den Unterschied

Wie der Dienst in der Praxis funktioniert, zeigt AWS in einer Herstellerdemo mit Claude Code. Ein Modell mit Wissensstand Mai 2025 beantwortet darin die Frage, wie sich Embeddings auf S3 speichern lassen, zunächst ohne Bezug auf Amazon S3 Vectors – ein Dienst, der erst im Juli 2025 als Preview startete und im Dezember 2025 allgemein verfügbar wurde. Mit angebundenem MCP-Server ruft der Agent laut AWS aktuelle Dokumentation ab und verweist dann auf S3 Vectors. Die Demo illustriert vor allem den Unterschied zwischen statischem Modellwissen und Laufzeitzugriff auf aktuelle Produktdokumentation.

Der MCP-Server steht zunächst in den Regionen US East (N. Virginia) und Europa (Frankfurt) bereit, kann API-Aufrufe aber in beliebige AWS-Regionen absetzen. Für den Dienst selbst fallen keine zusätzlichen Gebühren an; abgerechnet werden nur die genutzten AWS-Ressourcen und gegebenenfalls Datenübertragung. Als kompatible Clients nennt AWS in der Ankündigung unter anderem Claude Code, Kiro und Cursor; grundsätzlich funktioniert jeder MCP-fähige Client.

(fo)

Domain-driven Design (DDD) und Event Sourcing leben von einem präzisen Vokabular. Aggregates, Bounded Contexts, Process Managers, Read Models, Context Mappings: Wer in diesen Begriffen denkt, hat ein gemeinsames Werkzeug, um über fachliche Systeme zu sprechen. Solange das Gespräch während eines Workshops live stattfindet, funktioniert das verlässlich. Das Modell ist konsistent, weil alle Beteiligten es gleichzeitig im Kopf tragen.

Sobald der Workshop jedoch endet, beginnt das Problem. Das Modell verlässt den Raum nicht als gemeinsames Artefakt, sondern als Sammlung von Bruchstücken: ein paar Folien aus dem letzten Review, ein Whiteboard-Foto, eine README.md, verstreute Code-Kommentare, vielleicht ein Diagramm im Wiki. Jede dieser Quellen ist plausibel, aber keine ist autoritativ. In diesem Beitrag stelle ich die von meiner Firma the native web entwickelte Sprache ESDM (Event-Sourced Domain Modeling) vor und beschreibe, warum sie aus meiner Sicht die richtige Antwort auf dieses Problem ist.

Wohin Modelle verschwinden, sobald der Workshop endet

Das eigentliche Drama spielt sich in den Wochen nach dem Workshop ab. Ein Entwickler reicht eine Refactoring-Änderung ein, die einen Aggregatnamen umbenennt. Das Code Review winkt sie durch. Niemand denkt an die Folien, niemand öffnet das Wiki, niemand sucht das Whiteboard-Foto wieder heraus. Das Modell auf der Platte verändert sich, das Modell im Kopf der anderen bleibt unverändert, und der Drift beginnt.

Sechs Monate später kommt eine neue Kollegin ins Projekt. Sie liest die Folien aus dem Onboarding, weil das die einzige zusammenhängende Beschreibung ist, die sie findet. Was sie liest, stimmt nicht mehr mit der Realität überein. Ein Bounded Context heißt anders, ein Event existiert nicht mehr, ein ehemals Aggregat ist in zwei zerlegt worden. Die Folien sind kein Modell, sie sind ein Foto eines Modells aus einem bestimmten Monat.

In dieser Lage gibt es eigentlich nur drei mögliche Quellen der Wahrheit, und keine davon ist eine gute: Die Folien sind veraltet, das Wiki ist veraltet, und der Code beschreibt das Modell nicht, sondern führt es aus. Wer die fachliche Wahrheit wissen will, muss aus dem Code rückwärts rekonstruieren, was die ursprüngliche Idee einmal war. Das ist anstrengend, fehleranfällig und nicht skalierbar.

Der Kern des Problems ist, dass das Modell kein erstklassiges Artefakt ist. Es hat keinen festen Ort, kein verbindliches Format, keine prüfbaren Eigenschaften. Es ist nirgendwo zu Hause, also lebt es überall ein bisschen, und überall ein bisschen heißt im Zweifel nirgendwo richtig.

Was eine Modellierungssprache eigentlich leisten muss

Aus diesem Befund ergibt sich eine ziemlich genaue Anforderungsliste an eine Lösung. Das Modell muss versionierbar sein, also als Text vorliegen, den eine Versionsverwaltung sinnvoll diffen kann. Es muss neben dem Code im Repository leben, damit derselbe Pull-Request, der den Code ändert, auch das Modell einbezieht.

Es muss prüfbar sein, in dem Sinne, dass eine Maschine bestimmte strukturelle Aussagen über das Modell automatisch validieren kann. Ob jedes Aggregat seine Events benennt, ob jedes Event einen Erzeuger hat, ob jeder Context-Mapping-Verweis auf einen tatsächlich existierenden Bounded Context zeigt: Solche Fragen darf nicht der Lesende beantworten müssen, sondern die Werkzeugkette.

Es muss von Werkzeugen lesbar sein, also einer eindeutigen Grammatik folgen. Sobald das Format steht, lassen sich Validatoren, Generatoren, IDE-Integrationen und KI-gestützte Modellierungswerkzeuge dagegen bauen. Dieser Punkt klingt wie ein Nebensatz, ist aber der Hebel, der eine Sprache von einer Konvention unterscheidet.

Und es muss frei von Dialekten sein. Ein Format, das sich pro Team konfigurieren lässt, beschreibt am Ende keine gemeinsame Sprache, sondern eine Familie verwandter Privatsprachen. Der Wert eines geteilten Modells kollabiert, sobald jedes Projekt seine eigenen Regeln zuschneidet. Wer sich auf die Sprache verlassen können will, braucht eine Sprache, die nicht jede Stelle einzeln aushandelbar ist.

ESDM legt das Modell neben den Code

ESDM, kurz für Event-Sourced Domain Modeling, ist genau die Sprache, die diesen Anforderungen entspricht. Die YAML-basierte Sprache mit eingebauter Werkzeugkette ist auch für den kommerziellen Einsatz kostenfrei. Modelle bestehen aus Dateien mit der Endung .esdm.yaml, jede Datei enthält ein oder mehrere Dokumente, jedes Dokument deklariert eine apiVersion und einen kind-Eintrag und beschreibt damit genau ein Element der Domäne.

Die Werkzeugkette ist ein einziges Binary, das auf macOS, Linux und Windows läuft. Das Schema, gegen das die Werkzeuge validieren, ist im Binary eingebettet, nicht aus dem Netz nachgeladen. Das macht ESDM vollständig offline-fähig: Es funktioniert in abgeschotteten Build-Umgebungen, in CI-Runnern ohne ausgehende Netzverbindung und auf dem Laptop im Zug.

Der Effekt dieses Aufbaus ist greifbar. Das Modell liegt nicht mehr in einem entfernten System, sondern direkt im Repository, in einem Verzeichnis neben dem Code. Wer den Code bearbeitet, sieht das Modell. Wer das Modell bearbeitet, sieht es im Diff des Pull Request. Niemand muss sich daran erinnern, dass es das Modell gibt; es liegt sichtbar im Verzeichnisbaum.

Genauso wichtig ist, was sich dadurch im Review-Verhalten verändert. Sobald das Modell Teil des Repositorys ist, wird es Teil des Code-Reviews. Eine Refactoring-Änderung, die einen Aggregatnamen umbenennt, muss die entsprechende .esdm.yaml-Datei in derselben Änderung mitbewegen, sonst meldet der Linter den Bruch. Der Drift wird nicht durch Disziplin verhindert, sondern durch die Werkzeugkette.

Vokabular und Erweiterungen

Inhaltlich deckt ESDM das Vokabular ab, mit dem Domain-driven Design und Event Sourcing operieren. Domains und Subdomains beschreiben den fachlichen Rahmen. Bounded Contexts grenzen Vokabularien voneinander ab. Aggregates, Dynamic Consistency Boundaries (DCBs) und Process Manager tragen die Konsistenzregeln. Events und Commands tragen die Fakten und die Absichten. Read Models und Queries beschreiben die Leseseite. Context Mappings beschreiben, wie Bounded Contexts sich aufeinander beziehen. Actors, Domain Services, Event Handler, Policies und External Systems schließen die Lücken, die in realen Systemen sonst implizit bleiben.

Damit deckt der Kern den Schreib- und Leseweg eines Event-getriebenen Systems ab, von der Absicht über das Faktum bis zur projizierten Sicht. Das Modell ist nicht ausführbar; es beschreibt das Was, nicht das Wie. Diese Trennung ist die Voraussetzung dafür, dass dasselbe Modell für unterschiedliche Implementierungen tragen kann, ohne sich an eine Laufzeit zu binden.

Über den Kern hinaus gibt es Erweiterungen, die Artefakte rund um das eigentliche Modellieren beschreiben. Die Domain-Storytelling-Erweiterung hält Entdeckungsgeschichten als eigene Dokumentenart fest, mit Akteurinnen und Akteuren, Arbeitsobjekten und den Aktivitäten, die sie verbinden. Die Given-When-Then-Erweiterung erfasst Verhaltensbeispiele, also vorausgehende Events, eine auslösende Handlung und die erwarteten Ausgänge.

Beide Erweiterungen folgen denselben Konventionen wie der Kern und werden von derselben Werkzeugkette validiert. Sie injizieren aber keine neuen Bausteine in den Kern, und ein Kerndokument validiert nie gegen ein Erweiterungsschema. Diese Asymmetrie ist bewusst: Sie hält den Kern schmal und erlaubt es trotzdem, die Oberfläche der Sprache mit der Zeit wachsen zu lassen, ohne den Bestand zu gefährden.

Die Versionierung des Schemas folgt derselben Disziplin, die Sie aus Kubernetes-API-Gruppen kennen. Jedes Dokument deklariert eine apiVersion, und diese Version bindet das Dokument an eine konkrete Schema-Generation. Non-breaking Changes erhöhen die Schema-Revision, ohne die apiVersion anzufassen; Breaking Changes wandern in eine neue Hauptversion, und alte Dokumente validieren weiter gegen das alte Schema. Stabilität ist die Voreinstellung, Wechsel sind eine bewusste Entscheidung.

Der Linter hält das Modell sauber

Im Zentrum der Werkzeugkette steht der Linter. Er liest die .esdm.yaml-Dateien unter einem Verzeichnis, parst sie gegen das eingebettete Schema, prüft eine feste Liste struktureller und modellierender Regeln und meldet jede Verletzung als Diagnose mit Datei, Zeile und Spalte. Eine saubere Modellierung erzeugt keine Ausgabe und verlässt das Werkzeug mit Statuscode 0.

Der feste Regelkatalog ist eine bewusste Entscheidung. Es gibt keine Projektkonfigurationsdatei, keine Severity-Schalter, kein Abschalten einzelner Regeln. Eine Regel gilt oder sie gilt nicht; diese Entscheidung trifft die Werkzeugkette, nicht das Repository. Der Preis dafür ist, dass eine Regel gelegentlich strenger wirkt, als die konkrete Situation zu verlangen scheint. Der Gewinn ist, dass jedes ESDM-Modell, egal von welchem Team, dieselben Eigenschaften garantiert. Eine Sprache mit Schaltern beschreibt am Ende viele Sprachen mit demselben Namen, und der Wert des gemeinsamen Modells geht verloren.

Diagnosen sind Orte, keine Stack Traces. Jede Meldung verweist auf eine Datei, eine Zeile und eine Spalte und beschreibt das Problem in einem kurzen Satz, der das Vokabular der Modellierenden spricht, nicht das der Werkzeugkette. Es gibt keine Fehlernummern, die in einer Tabelle nachgeschlagen werden müssten, und keine internen Aufrufketten, die nach außen sichtbar wären.

Die volle Wirkung entfaltet der Linter, sobald er in der Continuous-Integration-Pipeline läuft. Ein Pull Request, der ein Aggregat umbenennt, ohne das Modell mitzuziehen, scheitert am CI-Schritt und wird nicht gemergt. Ein neues Event ohne Erzeuger oder ohne Konsumenten scheitert genauso. Der Drift, der vorher durch Disziplin verhindert werden musste, wird durch eine kurze, präzise Diagnose verhindert.

Konsistent mit ESDM

Konkret zahlt sich diese Architektur in mehreren Szenarien aus. Im Event-Storming-Workshop oder in der Domain-Storytelling-Sitzung gibt ESDM den Entdeckungen einen Ort, an dem sie überleben. Statt nach dem Workshop Fotos zu archivieren, schreibt man die Events, Commands, Akteurinnen und Akteure und Bounded Contexts in .esdm.yaml-Dateien und bekommt sofort Rückmeldung, ob das Modell intern konsistent ist. Ein Aggregat, das keine Events besitzt, ein Command, das niemand publiziert, ein Process Manager ohne Auslöser: Solche Lücken zeigt der Linter, bevor sie sich als unausgesprochene Annahmen verfestigen.

Bei einem bestehenden System, dessen Modell nur in den Köpfen der Beteiligten existiert, lässt sich ESDM als nachträgliches Beschreibungswerkzeug einsetzen. Beginnen Sie mit den Konsistenzeinheiten: jedes Aggregat, jeden Process Manager, jede Dynamic Consistency Boundary (DCB), jedes Read Model. Listen Sie die Events auf, die jeweils publiziert werden, und die Commands, die akzeptiert werden. Die Übung selbst legt Lücken frei, und am Ende steht ein Modell, das mit dem Code mitwachsen kann, statt ihm hinterherzulaufen.

Sobald das Modell vorliegt, wird es zum natürlichen Gesprächsformat mit fachlichen Stakeholderinnen und Stakeholdern. Der view-Befehl rendert das Modell als hierarchische Übersicht, von der Domäne über die Subdomains und Bounded Contexts bis hinunter zu den Konsistenzeinheiten und ihren Events und Commands. Diese Übersicht ist auf Knopfdruck verfügbar und entspricht garantiert dem Quellzustand. Domänenexpertinnen und Domänenexperten lesen darin dieselben Begriffe, die sie selbst verwenden, und können ohne Umweg über Implementierungsdetails Rückmeldung geben.

In Systemen mit mehreren Teams und gemeinsamen Bounded Contexts macht ESDM die Verträge zwischen den Teams explizit. Ein Context Mapping beschreibt die Beziehung zwischen zwei Bounded Contexts, ein teamübergreifender Event-Verweis ist eine geprüfte Tatsache und keine Vermutung. Was zwischen zwei Teams einmal vereinbart und im Modell festgehalten ist, prüft die Werkzeugkette danach automatisch. Die fachliche Annahme ist nicht mehr nur eine geteilte Erinnerung, sondern eine prüfbare Aussage.

Schließlich passt ESDM erstaunlich gut zu Workflows mit KI-Unterstützung. Das YAML ist schlicht genug, dass große Sprachmodelle es direkt lesen und schreiben, und das fixierte Schema und das benannte Vokabular geben dem Modell genau die Leitplanken, die es braucht, um etwas Kohärentes zu produzieren. Ein Modell aus einem Domänengespräch zu skizzieren oder aus einem Code-Bestand Kandidaten für Aggregates und Events zu extrahieren, sind Aufgaben, die sich mit dem ESDM-Vokabular zuverlässiger und überprüfbarer lösen lassen, als wenn das Modell in Prosa beschrieben wird.

Was ESDM bewusst nicht ist

Genauso wichtig wie die Beschreibung dessen, was ESDM ist, ist auch die Abgrenzung zu dem, was es nicht ist. ESDM ist kein Eventstore. Es speichert und liest keine Ereignisse, es legt nichts in eine Datenbank ab. ESDM beschreibt lediglich, welche Events es überhaupt geben soll.

ESDM ist auch kein Framework. Es schreibt keinen Programmierstil vor, keine Klassenhierarchie, keine Annotationen, keinen bestimmten Aufbau eines Service. Welche Sprache, welches Framework, welche Bibliothek Sie für die tatsächliche Implementierung verwenden, bleibt vollständig Ihnen überlassen. ESDM mischt sich in diese Entscheidungen nicht ein.

ESDM ist kein Codegenerator und keine Laufzeitumgebung. Es erzeugt aus dem Modell keine Klassen, keine Migrationen, keine API-Endpunkte. Es führt nichts aus. Diese Entscheidung ist keine Lücke, sondern Programm: Eine Modellierungssprache, die zugleich generieren oder ausführen will, zwingt mich zu Laufzeitentscheidungen, und eine Laufzeit, die zugleich modelliert, vergräbt das Modell unter Implementierungsdetails.

ESDM hält die beiden Seiten getrennt. Es ist eine deskriptive Schicht, die neben dem Code lebt und das Modell ehrlich hält, und es ist genau das, nichts darüber hinaus. Diese Sparsamkeit ist die Voraussetzung dafür, dass ESDM sich frei mit dem kombinieren lässt, was Sie tatsächlich in Produktion betreiben.

(rme)