Suche
Interview mit Dr. Markus Völter

DDD versus DSL: Was Domain-driven Design mit domänenspezifischen Sprachen zu tun hat

Hartmut Schlosser

Markus Völter

Um Fachabteilungen besser mit der Software-Entwicklung zu verbinden, kommen domänenspezifische Sprachen (DSLs) zum Einsatz, die speziell für ein bestimmtes Problemfeld entworfen werden. Die Idee dabei: DSLs können direkt durch Domänenspezialisten ohne tiefgreifendes IT-Wissen manipuliert werden. Auch im Ansatz des Domain-driven Design steht ein Domänen-Modell im Zentrum des Entwicklungsprozesses; auch hier ist das Ziel, die Fachlichkeit in den Fokus der Software-Entwicklung zu stellen.

Wir haben uns mit Modeling-Experte Dr. Markus Völter über den Zusammenhang zwischen DSLs und der Domänen-Modellierung, wie sie im Kontext des Domain-driven Design und der Microservice-Debatte verstanden wird, unterhalten. Dabei kommen aktuelle Trends der Software-Modellierung zur Sprache.

Dieses Gespräch wurde aufgezeichnet und anschließend transkribiert.

JAXenter: Hallo Markus, du beschäftigst dich seit mehreren Jahren mit modellgetriebener Softwareentwicklung, unter anderem hast du mit Thomas Stahl und anderen das Buch „Modellgetriebene Softwareentwicklung“ geschrieben. Was war damals eigentlich der Ausgangspunkt für eure Sichtweise auf die Softwaremodellierung? Ihr habt das ja MDSD genannt und euch damit explizit von MDA abgesetzt.

Irgendwann kam die Erkenntnis auf, dass Grafik nicht zur Lösung aller Probleme geeignet ist.

Markus Völter: Angefangen hat das alles mit der Idee, die Architektur eines Systems, also Softwarekomponenten und Softwarestrukturen, zu modellieren und daraus einen Architekturrahmen zu generieren. Mit UML-Tools war es ganz früher so, dass man Klassen modellieren und damit Klassenskelette generieren konnte, in die die Fachlichkeit von Hand hinein programmiert wurde (Protected Regions, Generation Gap Pattern). Das konnte man weiter treiben, indem man den UML-Klassen Stereotypen gegeben hat, durch die beispielweise ein Persistenz-Layer oder eine Zugriffs- oder Serialisierungsmethode mit generiert wurden. Das war der Startpunkt.

Über die Jahre hinweg hat man sich dann immer weiter weg von UML und hin zu anderen grafischen Modellierungssprachen entwickelt, die man für die betreffenden Domänen selbst gebaut hat. Der Unterschied zu MDA war zum einen das, was ich bereits erwähnt habe, also dass die Modellierung nicht zwangsläufig auf UML beruhen musste. Das war zumindest später so, zu Anfang hat man schon mit UML gearbeitet, weil es kein anderes Tool gab, um “Bilder zu malen”. Im Gegensatz zu MDA haben wir aber weniger versucht, die Fachlichkeit zu modellieren, sondern viel mehr die Technik. Auch der zentrale Punkt der Plattformunabhängigkeit, den die OMG historisch immer sehr in den Vordergrund gestellt hat und der auch bei der MDA wichtig war, hat oft keine Rolle gespielt, weil die Zielarchitektur meistens klar war. Und das Ganze war viel, viel pragmatischer: kleinere Tools, schlankere Prozesse, weniger Transformationen zwischen Modellen auf verschiedenen Abstraktionsebenen, was die Tools alle nicht wirklich beherrschten und was auch nicht skaliert hat.

Irgendwann kam dann aber die Erkenntnis auf, dass Grafik nicht zur Lösung aller Probleme geeignet ist. Daraufhin haben wir uns textuellen Notationen mit Xtext zugewandt: kleine textuelle Sprachen für den jeweils vorliegenden Anwendungszweck.

JAXenter: Nun entstand um das Jahr 2003 herum das Konzept des Domain Driven Designs. Wie stark hat das dich bzw. die Modellingszene beeinflusst?

DDD war in dreierlei Hinsicht eine Inspiration für mich.

Markus Völter: Ich habe schon während meiner Diplomarbeit ’99 ein bisschen mit UML modelliert und Code generiert; so gesehen war das also schon immer ein Interesse von mir. Aber mein eigentlicher Fokus auf Modellierung, Codegenerierung und MDSD entstand um 2004/2005. Das DDD-Buch gab es da also schon. Es war in dreierlei Hinsicht eine Inspiration für mich. Zum einen war da diese Idee von Anti-Corruption-Layers und verschiedenen Subdomänen, verschiedenen Teilsystemen, die man möglichst robust voneinander entkoppelt. Für die technische Implementierung war das natürlich schon nützlich. Genauso wie die zentralen Architekturabstraktionen, also Entities, Repositories, Value-Objects, die DDD so in den Vordergrund gestellt hat. Die sind in bestimmten Systemen auch schon im MDSD-Umfeld zum Einsatz gekommen, indem man dort entsprechende Stereotypen definiert hat. Sehr gerne wurde das für Entitäten und Value Objects gemacht. Es kam auch schon vor, dass man Code generiert hat, der diesen Patterns entsprach. Aber ich würde nicht sagen, dass uns DDD jeden Tag beschäftigt hätte.

Ein ganz wesentlicher Punkt ist natürlich schon das, was in DDD als Ubiquitous Language bezeichnet wird, also das Verständnis der Fachdomäne in ihrer ontologischen Struktur und deren Repräsentation in der Sprache. Im DDD ist das eine nicht-formale Sprache; also Wörter und Beziehungen zwischen Wörtern, die sich dann vielleicht in Klassen oder Namen von Value Objects oder Namen von Entitäten ausdrücken. Natürlich ist diese Ubiquitous Language in gewisser Weise auch der Kern von fachlichen DSLs.

JAXenter: Du hast dich dann ja im Rahmen von OAW mit DSLs auseinandergesetzt. Wo liegen die Gemeinsamkeiten zwischen einer Domäne wie sie in DDD verstanden wird und wie sie im Kontext einer DSL modelliert wird?

Markus Völter: Wir achten heute immer stärker darauf den fachlichen Kern einer Domäne zu verstehen und diesen dem Fachentwickler über die DSL als First-Class-Sprachkonstrukte zur Verfügung zu stellen. Wenn man eine Domäne nicht kennt, fängt man oft mit einer klassischen Domänenanalyse an. Man überlegt, was die wichtigsten Konzepte darin sind, in welcher Beziehung sie zueinander stehen, was die wichtigsten Aktivitäten sind. Da hat man die Idee einer Ubiquitous Language aus dem DDD durchaus. Ansonsten muss ich sagen, dass DDD bei mir heutzutage keine Rolle mehr spielt.

Wo liegen die Unterschiede? DSLs gehen viel, viel weiter. Sie formalisieren die Ubiquitous Language, definieren eine Syntax, man definiert eine IDE dafür und generiert oder interpretiert die damit erstellten Modelle. Das wollten die DDDler ja eigentlich nie so richtig – wenn man mit Eric Evans und anderen redet, gibt es keine so große Begeisterung für die Idee, das generativ oder interpretativ mit einer wohldefinierten Sprache zu machen.

Wir haben gerade einen Kunden, der DDD religiös angewendet hat und das nun aufgibt, weil er gemerkt hat, dass eine vernünftig definierte DSL wirklich viel, viel weiter geht. Auch wenn man die Ubiquitous Language als Startpunkt verwendet bleibt dann von DDD nicht mehr sehr viel übrig. Auch die zentralen Architekturabstraktionen wie Entity, Value Object, Repository und so weiter sind nur eine Möglichkeit, eine technische Architektur zu strukturieren, und funktionieren in technischen Systemen eigentlich nicht: diese Abstraktionen sind für klassische, datengetriebene Business-Applikationen entstanden, und das ist ja nicht alles, was man softwaretechnisch macht.

JAXenter: Im Kontext der aktuellen Microservice-Debatte wird dazu geraten, Software in kleine Services aufzuteilen, die von fachlicher Seite her Sinn ergeben. Einer der Gründe: Jeder Service kann so von einem spezialisierten Team, das sich in der jeweiligen Domäne auskennt, auf seine Weise umgesetzt werden. Auch mit einer DSL versucht man eine Brücke zwischen Softwareentwicklung und Domänenexperten zu schlagen. Ergänzen sich die Ansätze oder vergleichen wir Äpfel mit Birnen?

Markus Völter: Zunächst einmal vergleichen wir Äpfel mit Birnen. Bei Microservices geht es um die technische Strukturierung eines Systems, also um Aspekte wie eine Reduktion von Abhängigkeiten, oder ein unabhängiges Deployment. Es geht darum, dass man einen Service einfach wegschmeißen und neu implementieren kann, ohne jedesmal das ganze System neu bauen zu müssen. Das stimmt zwar alles nur bedingt, weil die semantische Kopplung natürlich trotzdem da ist, aber wie dem auch sei – im Grunde ist das alles eher eine technische Geschichte.

Wenn man hingegen DSLs richtig umsetzt, erreicht man damit eine Trennung von Technik und Fachlichkeit. Mein Versicherungsmodellierer, mein Versicherungsvertragsgestaltungsexperte kann mir den Versicherungsvertrag völlig unabhängig von einer irgendwie gearteten technischen Implementierung beschreiben. Die werden ihr System natürlich in irgendeiner Art und Weise modularisieren. Aus diesen Modularisierungen auf fachlicher Ebene werden auf technischer Ebene später vielleicht Microservices, aber das muss nicht so sein. Insbesondere dann, wenn man interpretativ arbeitet, also die fachlichen Modelle nicht durch Generierung und Neu-Deployment ins Rechenzentrum bringt, sondern durch die Speicherung der Daten in einem Repository, einer Datenbank. Dann ist es gar kein Problem, Dinge separat upzudaten denn man muss nur den betreffenden Teil des Modells ändern. Die ganze Problematik, bei Änderungen immer das komplette System depolyen zu müssen – was man dann vielleicht mit Microservices lösen kann – stellt sich mir hier gar nicht.

In diesem Sinne sind die beiden Dinge  – DSLs und Microservices – ganz, ganz anders. Bei Microservices würde man ja nicht behaupten, dass der Microservice von einem fachlichen Entwickler implementiert wird, der keine Ahnung von Programmierung hat. Daher also Äpfel und Birnen. Auf der anderen Seite ergänzt sich beides aber auch, weil das eine davon eine technische Geschichte ist, das andere eine fachliche, wenn man DSLs auf der fachlichen Ebene einsetzt.

Natürlich kann man DSLs auch zur Modellierung von Schnittstellen zwischen Microservices und zur Versionierung von Schnittstellen und für Contracts und Migrationen einsetzen. Das ergibt auch Sinn und dann besteht durchaus ein direkter Bezug zu Microservices. Allerdings werden DSLs, also fachliche, domainspezifische Sprachen, heute zumeist nicht so genutzt.

JAXenter: Dann blicken wir zum Schluss ein wenig auf den aktuellen State of the Art in Sachen Modeling: Welche spannenden Entwicklungen siehst du momentan in diesen Bereichen?

Die Tools sind besser dazu geeignet, endbenutzer- taugliche DSLs zu bauen.

Markus Völter: Zum einen haben wir bessere Werkzeuge, mit denen man den fachlichen Kern wirklich so in eine Sprache verpacken kann, dass ihn Fachexperten, also Nicht-Programmierer, verstehen. Das hat viel mit Notationen zu tun, also damit, dass man Entscheidungstabellen als Tabelle repräsentiert, Entscheidungsbäume als Baum und dass man Schlüsselwörter so repräsentiert, dass die Leute sie verstehen. Man hat einfach mächtigere Tools zur Verfügung, die einen weiteren Scope erlauben und mehr Gestaltungsspielraum für die Sprachen bieten.

Dann sehen wir eine zunehmende Integration mit formalen Methoden zur statischen Prüfung, also zum Beispiel die Integration von Solvern, die prüfen, ob die Verzweigungen, Entscheidungsbäume und Entscheidungsstrukturen vollständig und überlappungsfrei sind. Oder man modelliert Prozesse oder Abläufe als Zustandsmaschinen und lässt dann einen Modelchecker drüber laufen. Die entsprechenden Werkzeuge sind heute reif für die Praxis, und wir sehen durchaus, dass nicht nur wir das cool finden und gerne anwenden wollen, sondern dass es auch bei den Kunden auf offene Ohren stößt und diese einen darauf ansprechen.

Zu guter Letzt sind die verbesserten Tools nicht nur besser dazu geeignet, endbenutzertaugliche DSLs zu bauen, sondern erleichtern und beschleunigen auch die Entwicklung der Sprachen immer mehr. Das heißt, dass man kürzere Turnaround-Zeiten hinbekommt und man Fachler besser in den Bau der DSL integrieren kann. Man kann schnell in einer Viertelstunde etwas bauen, während der Fachler zwei E-Mails beantwortet. Und dann dreht man den Laptop um und lässt ihn die Sprache ausprobieren. Damit kann man sehr effiziente Sprachbau-Workshops mit den Fachlern durchführen.

Was da auch mit rein spielt, ist die Geschichte mit der Sprach-Wiederverwendung und Modularisierung. Wenn man die entsprechenden Tools einsetzt, also beispielsweise MPS, Spoofax oder Rascal, kann man heutzutage wiederverwendbare Kerne von Sprachen definieren oder wiederverwendbare Notationsprimitive, beispielsweise Tabellen oder mathematische Symbole, die man dann sehr einfach in eine kunden- oder domainspezifische Sprache einbauen kann. Damit wird der Aufwand zur Spracherstellung weiter reduziert. Dieser Aufwand ist ja schon generell nicht unglaublich groß, wenn man sich überlegt, was man damit erreichen kann. Doch wenn man dem Kunden sagt „wir bauen eine eigene Sprache“, ist es natürlich auch aus politischen Gründen immer wichtig, dass man sehr schnell zu ersten Ergebnissen kommt, damit der Kunde nicht glaubt, dass er Monate oder Jahre investieren muss, um irgendwann mal eine 08/15-Sprache gebaut zu kriegen. Das ist teilweise noch immer die Vorstellung der Kunden.

JAXenter: Vielen Dank für das Interview!

voelter_markusMarkus Völter works as an independent researcher, consultant and coach for itemis AG in Stuttgart, Germany. His focus is on software architecture, model-driven software development and domain specific languages as well as on product line engineering. Markus also regularly writes (articles, patterns, books) and speaks (trainings, conferences) on those subjects. Contact him via www.voelter.de.

.

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare
  1. Jörg Rade2016-09-07 12:50:33

    Wenn ich mir die Beispiele unter https://www.quora.com/What-are-some-examples-of-domain-specific-languages anschaue, dann sind eigentlich alle Domains I-technischer Natur.

    Gibt es Beispiele für Business DSL's?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.