Was ist Model-Driven Engineering?
Statt erst Code zu schreiben und dann zu hoffen, dass alle dasselbe gemeint haben, malst du zuerst ein Modell — und der Rest wird daraus erzeugt. Methode seit ~2003 · gescheitert in der Wave 1 · jetzt in der Wave 2 wieder relevant.
Mit einem konkreten Beispiel
Stell dir vor, du baust einen Tank-Sensor-Service. Der Sensor misst den Füllstand, ein Display zeigt ihn an, eine Pumpe schaltet sich bei < 20 % ein.
Klassisch schreibst du:
- Backend-Code (Rust) für den Sensor-Auslesepfad
- Mobile-App (Swift / Kotlin) für die Anzeige
- Embedded-Firmware (C) für die Pumpensteuerung
- Web-Dashboard (TypeScript) fürs Service-Personal
- Datenbank-Schema (SQL)
- API-Schnittstellen-Beschreibung (OpenAPI / Protobuf)
Sechs Stellen, an denen „Tankfüllstand" in irgendeiner Form codiert ist. Wenn jemand entscheidet, dass der Wert künftig in Litern statt Prozent ankommt, musst du alle sechs anfassen. Eine vergisst man — und im Feld kommt der Bug raus.
Mit MDE machst du es so:
- Du beschreibst einmal in einem Modell:
topic Tankfuellstand { wert: Liter gemessen_um: Zeitstempel } - Ein Generator macht daraus den Rust-Code, den Swift-Code, den Kotlin-Code, das SQL-Schema, die OpenAPI-Definition. Alle.
Wenn die Einheit jetzt von Prozent auf Liter wechselt, änderst du eine Zeile im Modell. Der Generator macht den Rest.
Modell zuerst, Code danach. Eine Wahrheit, sechs Outputs.
Warum hat das in den 2000ern nicht funktioniert?
In den 2000ern gab's einen großen Hype um MDA (Model-Driven Architecture) und UML als universelle Modellierungssprache. Das hat aus mehreren Gründen nicht geklappt:
- Die Tools waren zu schwer. IBM Rational Rose, Sparx Systems Enterprise Architect — riesige Commercial-Suites, die mehr Zeit in Konfiguration als in Modellierung kosteten.
- Die Generatoren waren Black-Boxes. Was rauskam, war nicht lesbar, und wenn man's anpassen wollte, war man verloren.
- UML war zu allgemein. Eine Sprache, die alles modellieren kann, modelliert nichts gut.
- Die Modelle waren in proprietären Formaten — nicht versionierbar, nicht diff-bar, nicht in Git.
Warum es jetzt anders ist
- Modelle sind heute Text. YAML, JSON, TOML, oder eine Domain-Specific Language (DSL). Versionierbar in Git, diff-bar, pull-request-bar.
- Generatoren sind transparent. Sie sind selbst Open Source, der erzeugte Code ist lesbar wie handgeschriebener.
- Domänen-spezifische Modellierungssprachen statt einer allmächtigen UML — z.B. eine Sprache nur für DDS-Topics, eine nur für Hardware-Register.
- Multi-Output ist Standard. Aus einem Modell wird wirklich Rust + C + TypeScript + Schema + Doku gemacht, nicht nur Java.
- Versionsverträglich. Wenn dein Modell in v2 ein neues Feld bekommt, weiß der Generator, wie es zu dem v1-Bestand passt.
Wo passt das ins ZeroDDS-Bild?
DDS braucht Modelle. Eine „Topic" — also ein Datenfluss zwischen Maschinen — wird durch eine Type-Definition beschrieben. Klassisch macht man das in IDL (Interface Definition Language). Aus dieser einen IDL-Datei wird Code für jede Sprache erzeugt.
Das ist klassisches MDE. ZeroDDS macht das mit dem Tool idlc (IDL-Compiler), der aus einer .idl-Datei native Rust-, C++-, Java-, Python- und TypeScript-Klassen baut.
Was wir mit Zero PDE drauf setzen: ein Werkzeug, in dem du nicht nur Type-Definitionen, sondern die ganze Architektur modellierst — Topics, QoS-Profile, Sicherheits-Domänen, Hardware-Mapping. Aus einem Modell. In Git versionierbar. Transparent generiert.
Wo's nicht passt
- Wegwerf-Skript für eine einmalige Datenmigration. Da reicht ein Python-Skript. MDE ist Overhead.
- Frontend-Prototyping. Wenn du in einer Woche ein UI-Mockup bauen willst, brauchst du keinen Code-Generator.
- Sehr kleine Teams ohne Doku-Druck. MDE zahlt sich erst aus, wenn mehr als 2-3 Leute das Modell verstehen müssen.
Ein guter Indikator: wenn dein Projekt eine „Wahrheit" hat, die an mehr als 3 Stellen codiert sein muss, ist MDE einen Blick wert.
In drei Sätzen
Model-Driven Engineering ist die Idee, eine einzige Wahrheit in einem versionierbaren Modell zu pflegen und alle Code-, Schema- und Doku-Outputs daraus zu generieren. Es ist seit 20 Jahren versprochen worden und seit 5 Jahren tatsächlich machbar. Die ZeroDDS-Familie nutzt es konsequent — vom IDL-Compiler bis zum Architektur-Modellierer.
Weiter: Was ist DDS? · Glossar