Gespräche mit deinem Code: So erweckt Modelith Domain Models zum Leben

Mal ganz ehrlich — die meisten Projekte beginnen mit den besten Vorsätzen. Jemand skizziert das Domain Model an einer Whiteboard-Tafel, alle nicken, und dann... landet es still und leise in irgendeiner Ecke von Confluence, wo es niemand je wieder anfässt.

Das Problem liegt nicht am Konzept des Domain Modeling an sich. Es liegt daran, wie Domain Models عادةً behandelt werden:

• Einmal geschrieben und dann vergessen
• Getrennt vom Code gepflegt
• Nur in speziellen Tools lesbar
• Kaum automatisch validierbar

Modelith geht einen anderen Weg. Hier wird dein Domain Model nicht als abzuhakendes Deliverable betrachtet, das man abgibt und archiviert. Stattdessen ist es ein lebendiges Artefakt, das direkt neben deinem Code existiert, durch Gespräche entsteht und automatisch in der CI-Pipeline geprüft wird.

Was ist ein Domain Model eigentlich?

Bevor wir weitermachen, sollten wir uns einig sein. Ein Domain Model ist deine konzeptuelle Landkarte des Systems — die Substantive (Entitäten), ihre Beziehungen untereinander und die Regeln, die sie steuern. Es ist kein Datenbankschema und keine API-Spezifikation. Es ist der kanonische, in einfacher Sprache formulierte Ausdruck davon, was dein System tut.

Stell es dir als gemeinsames Vokabular für dein gesamtes Team vor. Wenn alle aus demselben Model lesen, werden Gespräche präziser, das Onboarding neuer Kollegen geht schneller, und neue Services oder Features zu entwickeln fühlt sich nicht mehr an wie eine archäologische Ausgrabung durch Legacy-Code.

Der Modelith-Workflow: Beschreiben, Entwerfen, Prüfen, Rendern

Jetzt wird's spannend. Bei Modelith schreibst du kein YAML von Hand. Du denkst noch nicht einmal an YAML. Stattdessen beschreibst du deine Domain-Konzepte in einfacher Sprache gegenüber einem KI-Agenten — konkret einem Claude Code Skill — und der Agent erstellt das darunterliegende YAML für dich.

Der Ablauf sieht so aus:

1. Beschreiben — Du erzählst von deiner Domain in einfachem Englisch. „Wir haben Kunden, die Bestellungen aufgeben können. Bestellungen enthalten mehrere Produkte, aber Kunden dürfen maximal drei aktive Bestellungen gleichzeitig haben."

2. Erstellen — Das Claude Code Plugin übersetzt deine Beschreibung in eine modelith.yaml-Datei und validiert dabei bereits.

3. Prüfen — Du führst modelith lint aus, um Vollständigkeit und Konsistenz zu checken. Das wird dein CI-Gate.

4. Rendern — Du führst modelith render aus, um Markdown mit Mermaid-Diagrammen zu generieren. Das wird direkt neben dem YAML committet.

Das gerenderte Markdown ist ohne jegliche Tools lesbar. Das YAML ist die maschinenlesbare Quelle der Wahrheit. Und die CI-Pipeline stellt sicher, dass beides niemals auseinanderläuft — stell es dir vor wie eine Generated-Code-Prüfung, nur eben für dein Domain Model.

Warum dieser Ansatz funktioniert

Einfache Sprache senkt die Hürde

Nicht jeder in deinem Team fühlt sich wohl beim Lesen von JSON Schema oder UML-Diagrammen. Aber jeder kann einfaches Englisch lesen. Indem einfache Sprache zum Einstiegspunkt wird, demokratisiert Modelith das Domain Modeling. Dein Product Manager kann mitarbeiten. Dein QA Engineer kann es reviewen. Und dein Junior-Entwickler versteht endlich das große Ganze.

KI übernimmt das Fleißarbeit

YAML von Hand schreiben ist fehleranfällig und, seien wir ehrlich, langweilig. Wenn ein KI-Agent die Übersetzung von deiner Beschreibung zu valide YAML übernimmt, hast du weniger mentale Last und behältst trotzdem die Präzision.

CI-Validierung verhindert Auseinanderlaufen

Das ist das Killer-Feature für Teams. Dein Domain Model wird zum gleichberechtigten Bürger in deinem Entwicklungsworkflow. Jeder PR, der die Domain verändert, wird automatisch geprüft. Wenn jemand das YAML aktualisiert, aber vergisst, die Docs neu zu generieren — CI bemerkt es.

Das Model bleibt nah am Code

Wenn dein Domain Model im selben Repository wie dein Code lebt, bleibt es relevant. Es wird in Pull Requests reviewed. Es wird aktualisiert, wenn Features sich ändern. Es wird nicht zu veraltetem Dokumentationsmüll in irgendeinem anderen System, das niemand mehr prüft.

Wie du loslegst

Modelith ist darauf ausgelegt, niedrigschwellig zu sein. Du musst nicht das gesamte Schema von Anfang an verstehen. Fang klein an:

• Installiere das Claude Code Plugin
• Beschreibe ein paar Kernkonzepte deiner Domain
• Lass die KI das YAML entwerfen
• Führe modelith lint aus, um zu sehen, was noch fehlt
• Iteriere

Das Projekt enthält durchgearbeitete Beispiele — ihr Parking-Guide-Beispiel ist ein guter Einstieg, der dich Schritt für Schritt durch den Aufbau eines echten Models führt.

Der größere Zusammenhang

Modelith steht für einen breiteren Trend in der KI-unterstützten Entwicklung: Natürliche Sprache als Oberflächenschicht nutzen, während maschinenlesbare Artefakte darunter liegen. Du schreibst, was du meinst; das Tooling kümmert sich um Konsistenz und Validierung.

Für Teams, die komplexe Systeme bauen — besonders in Bereichen, in denen das Vokabular kritisch ist (Fintech, Healthcare, Logistik, überall dort, wo Geschäftsregeln wichtig sind) — könnte dieser Ansatz transformativ sein. Ein geteiltes, validiertes, lebendiges Domain Model bedeutet weniger Missverständnisse, schnelleres Onboarding und besser durchdachte Systeme.

Das Tool entwickelt sich noch weiter, aber die Kernidee ist solide. Dein Domain Model sollte kein Nachgedanke sein und auch kein Relikt aus der Projekt-Kickoff-Phase. Es sollte ein lebendiges Dokument sein, das sich mit deinem Code weiterentwickelt, durch Gespräche entsteht und automatisch validiert wird.

Wenn du selbst schon damit gekämpft hast, Domain Models in deinen Projekten aktuell zu halten, ist Modelith einen Blick wert. Manchmal ist das beste Tooling nicht das mächtigste — sondern dasjenige, das den richtigen Weg zum einfachsten macht.

Schau dir modelith.sh an und leg los.