ESDM: Das Fachmodell gehört neben den Code, nicht ins Whiteboard-Foto

Jeder, der schon einmal eine Erweiterung oder Schnittstelle rund um ein ERP gebaut hat, kennt den Ablauf. Am Anfang steht ein Workshop mit der Fachabteilung. Alle stehen vor dem Whiteboard, kleben Zettel, diskutieren, was eigentlich passiert, wenn ein Kunde eine Retoure anmeldet. Am Ende wird ein Foto gemacht. Vielleicht noch eine Folie. Vielleicht ein Wiki-Eintrag.

Drei Monate später ist der Code weitergewachsen, ein Begriff wurde umbenannt, ein Prozessschritt ist dazugekommen. Das Foto zeigt immer noch den alten Stand. Niemand hat es aktualisiert, weil niemand daran gedacht hat. Wer neu ins Projekt kommt, liest den Code und versucht zu erraten, was die Fachabteilung eigentlich gemeint hat.

Genau hier setzt ESDM an. Die Abkürzung steht für Event-Sourced Domain Modeling. Dahinter steckt eine Beschreibungssprache für Fachmodelle, entwickelt von the native web, dem Team hinter EventSourcingDB. Sie ist im Mai 2026 erschienen, steht unter MIT-Lizenz und ist auch für den kommerziellen Einsatz kostenlos.

Gründer und CTO von the native web ist Golo Roden. Ein persönliches Wort an dieser Stelle: Ich schätze seine Videos auf dem YouTube-Kanal von the native web sehr. Golo erklärt Architekturthemen wie DDD, CQRS und Event-Sourcing so klar und unaufgeregt, dass man danach nicht nur mehr weiß, sondern auch anders über die eigene Software nachdenkt. Viele Ideen und Anregungen, die heute in unseren Projekten stecken, habe ich von dort mitgenommen. Dass aus diesem Gedankengut jetzt ein offenes Werkzeug wie ESDM entstanden ist, freut mich deshalb besonders.

Was ESDM ist

ESDM beschreibt ereignisgetriebene Fachdomänen als schlankes YAML. Ein Modell ist ein Ordner mit Dateien, die auf .esdm.yaml enden. Jede Datei beschreibt genau ein Element der Domäne und sagt über kind, was sie ist. Der Wortschatz kommt aus Domain-Driven Design (DDD), CQRS und Event-Sourcing:

• Struktur: Domain, Subdomain, Bounded Context
• Zustand: Aggregate, Entity, Value Object, Dynamic Consistency Boundary
• Verhalten: Command, Event, Query, Read Model
• Abläufe: Process Manager, Policy, Event Handler, Domain Service
• Umfeld: Actor, External System, Context Mapping

Dazu kommen zwei Erweiterungen. Mit Domain Storytelling hältst Du fest, wie Fachleute ihre Arbeit erzählen: Wer macht was, mit welchem Arbeitsgegenstand. Mit Given-When-Then beschreibst Du Verhalten als Spezifikation: Welche Ereignisse liegen vor, was wird ausgelöst, was soll herauskommen. Beide Erweiterungen nutzen dasselbe Format und dieselben Werkzeuge, ohne den Kern zu verändern.

Wichtig ist auch, was ESDM nicht ist. Es ist kein Event-Store, kein Framework, keine Laufzeitumgebung und kein Codegenerator. ESDM beschreibt das Was, nicht das Wie. In welcher Sprache und mit welcher Datenbank Du das Modell später umsetzt, bleibt Deine Entscheidung.

Wie das aussieht

Nehmen wir ein Beispiel, das im Umfeld der Sage 100 häufig vorkommt: eine Retourenabwicklung, die als eigene Anwendung neben der Warenwirtschaft läuft. Kunden melden Retouren über ein Portal an, das Lager prüft die Ware, und erst am Ende entsteht in der Sage 100 eine Gutschrift. Das Aggregate für die Retoure sieht in ESDM so aus:

apiVersion: schema.esdm.io/core/v1
kind: aggregate
name: retoure
scope:
  domain: kundenservice
  boundedContext: retourenabwicklung
identifiedBy:
  source: state
  field: retourennummer
state:
  type: object
  properties:
    retourennummer: { type: string }
    kundennummer: { type: string }
    lieferscheinnummer: { type: string }
    status: { type: string }
  required: [retourennummer, kundennummer, lieferscheinnummer, status]

Der Befehl, mit dem ein Kunde eine Retoure anmeldet, und das Ereignis, das daraus entsteht, sind jeweils eine eigene Datei:

apiVersion: schema.esdm.io/core/v1
kind: command
name: anmelden
scope:
  domain: kundenservice
  boundedContext: retourenabwicklung
  aggregate: retoure
data:
  type: object
  properties:
    kundennummer: { type: string }
    lieferscheinnummer: { type: string }
    grund: { type: string }
  required: [kundennummer, lieferscheinnummer, grund]
publishes:
  - angemeldet

apiVersion: schema.esdm.io/core/v1
kind: event
name: angemeldet
scope:
  domain: kundenservice
  boundedContext: retourenabwicklung
  aggregate: retoure
data:
  type: object
  properties:
    retourennummer: { type: string }
    kundennummer: { type: string }
    lieferscheinnummer: { type: string }
    grund: { type: string }
  required: [retourennummer, kundennummer, lieferscheinnummer, grund]

Das ist kein Code, den irgendjemand ausführt. Es ist eine Beschreibung, die Entwickler und Fachabteilung gleichermaßen lesen können. Die Sage 100 selbst taucht im Modell als External System auf, an das die fertige Gutschrift übergeben wird. Über ein Context Mapping hältst Du fest, wer dabei wem was liefert.

Die Werkzeuge

ESDM kommt als einzelne Programmdatei für Windows, macOS und Linux. Das Schema steckt darin, ein Netzwerkzugriff ist nicht nötig. Das ist praktisch für Build-Server, die nicht ins Internet dürfen. Die wichtigsten Befehle:

• esdm lint prüft das Modell gegen das Schema und gegen feste Modellierungsregeln. Ein Fehler kommt mit Datei, Zeile und Spalte. Ist alles sauber, gibt es keine Ausgabe.
• esdm view zeigt das Modell als Hierarchie, die sich auch mit Fachleuten durchgehen lässt.
• esdm documentation schreibt das ganze Modell als verlinkte Markdown-Seiten, eine pro Element.
• esdm glossary erzeugt das Glossar der Fachbegriffe, die sogenannte Ubiquitous Language, als ein Dokument.

Der Linter ist bewusst nicht konfigurierbar. Das klingt zunächst unbequem, hat aber einen Grund: Wenn jedes Team eigene Regeln einstellen kann, entstehen Dialekte, und ein Modell bedeutet im nächsten Projekt plötzlich etwas anderes. Für einzelne Stellen lässt sich eine Regel per Kommentar im YAML abschalten, sichtbar und nachvollziehbar.

Wo wir ESDM einsetzen

Die Sage 100 ist und bleibt bei unseren Kunden das führende System für Belege, Buchungen und Stammdaten. Ihr Datenmodell ist über viele Versionen gewachsen und durchdacht, daran ändern wir nichts. ESDM nutzen wir dort, wo rund um die Sage 100 etwas Eigenes entsteht und die fachlichen Abläufe nicht im Standard stecken.

Fachworkshops mit direktem Ergebnis

Statt am Ende des Workshops das Whiteboard zu fotografieren, schreiben wir Ereignisse, Befehle und Abläufe direkt in Dateien. Der Linter meldet sofort, wenn ein Ereignis keinen Auslöser hat oder ein Befehl ins Leere läuft. Fragen, die sonst erst in der Umsetzung auffallen, klären wir so noch im Raum, solange die Fachabteilung dabei ist.

Erweiterungen und Schnittstellen

Bei Zusatzanwendungen, die neben der Sage 100 laufen, liegt das Modell im selben Repository wie der Code. Wer ein Aggregate umbenennt oder einen Prozess aufteilt, ändert die YAML-Datei im selben Pull Request. Im Review sieht man im Diff nicht nur, was sich im Code ändert, sondern auch, was sich fachlich ändert. Prüft der Build-Server zusätzlich mit esdm lint, fällt ein vergessenes Update sofort auf.

Bestehende Lösungen nachträglich beschreiben

Nicht jedes Projekt fängt auf der grünen Wiese an. Bei gewachsenen Erweiterungen nutzen wir ESDM auch rückwirkend: Wir beschreiben, was die Anwendung heute tatsächlich tut. Dabei fallen regelmäßig Lücken auf, etwa ein Status, den es im Code gibt, den aber niemand mehr fachlich erklären kann.

Mit KI modellieren, mit dem Linter prüfen

Das Format ist so klar strukturiert, dass ein Sprachmodell es direkt lesen und schreiben kann. Wir lassen einen KI-Assistenten aus Workshop-Notizen oder aus bestehendem Code einen ersten Entwurf des Modells erstellen. Der Linter ist dabei die Kontrollinstanz: Was die KI schreibt, ist entweder ein gültiges Modell oder es gibt eine konkrete Fehlermeldung, die sie selbst beheben kann. Fachlich entscheidet am Ende trotzdem immer ein Mensch. Aber der Weg vom leeren Blatt zum ersten diskutierbaren Entwurf ist deutlich kürzer.

Dazu passt, was wir im Beitrag über LLMs und die Zukunft des ERP beschrieben haben: KI arbeitet dann zuverlässig, wenn sie auf klare Strukturen trifft. Ein festes Schema mit benanntem Vokabular ist genau so eine Struktur.

Was es bringt

• Eine Quelle für das Fachmodell. Nicht mehr Foto, Folie und Wiki, sondern Dateien, die mit dem Code versioniert werden.
• Das Modell veraltet nicht still. Änderungen laufen durch dasselbe Review wie der Code, und der Linter hält Widersprüche auf.
• Gemeinsame Sprache mit der Fachabteilung. Das Glossar und die Ansicht per esdm view lassen sich ohne Programmierkenntnisse durchgehen.
• Schnellere Einarbeitung. Wer neu ins Projekt kommt, liest zuerst das Modell und versteht, was die Anwendung fachlich tun soll, bevor er den ersten Code öffnet.
• KI mit Leitplanken. Entwürfe aus dem Sprachmodell werden sofort geprüft, statt nur plausibel zu klingen.
• Offen und unabhängig. Das Format ist offen, die Werkzeuge sind kostenlos, und das Modell bindet Dich an keine Datenbank und kein Framework.

Wo die Grenzen liegen

ESDM ist auf ereignisgetriebene Systeme zugeschnitten. Für eine einfache Stammdatenerweiterung mit ein paar Zusatzfeldern ist es zu viel. Dort reicht eine Tabelle und eine kurze Beschreibung. Seinen Wert spielt es aus, sobald Abläufe über mehrere Schritte gehen, mehrere Beteiligte im Spiel sind oder später nachvollziehbar sein muss, was wann passiert ist.

Außerdem ist ESDM noch jung. Das Schema ist versioniert, ähnlich wie bei Kubernetes, sodass ältere Modelle auch nach einem größeren Versionssprung gültig bleiben. Trotzdem lohnt es sich, die Entwicklung im Blick zu behalten.

Fazit

Das beste Fachmodell nützt wenig, wenn es nach drei Monaten nicht mehr stimmt. ESDM löst das nicht durch Disziplin, sondern durch Werkzeuge: Das Modell liegt neben dem Code, wird mit ihm geprüft und mit ihm geändert. Dass Mensch und KI dasselbe Format lesen und schreiben können, macht den Einstieg zusätzlich leicht.

Eigene Abläufe rund um die Sage 100 sauber modellieren

Du planst eine Erweiterung oder Schnittstelle zur Sage 100, bei der die fachlichen Abläufe nicht trivial sind? Wir bringen die Fachabteilung und die Entwicklung an einen Tisch und halten das Ergebnis so fest, dass es auch in zwei Jahren noch stimmt.