Domain-Driven Design einführen – bloß wie?

Domain-Driven Design einführen – bloß wie?

Wann wurden Sie das letzte Mal beauftragt, eine Software zu entwickeln, damit endlich einmal wieder ein O/R-Mapper eingesetzt werden kann? Noch nie? Ich auch nicht. Das liegt daran, dass Software nicht um der Technologie willen entwickelt wird, sondern um fachliche Probleme zu lösen: Software soll das Leben angenehmer, einfacher, komfortabler und sicherer machen. So traurig diese Erkenntnis für technologiebegeisterte Entwickler sein mag: Software ist kein Selbstzweck – Software ist Mittel zum Zweck.

Um eine Software zu entwickeln, die ein fachliches Problem zielgerichtet löst, muss man sich als Entwickler gut mit den verwendeten Technologien auskennen. Das ist das Pendant zu einem Handwerker, der sein Werkzeug kennen und beherrschen muss. Doch das ist nur die eine Seite der Medaille. Die andere, die für eine zielgerichtete Lösung viel wichtiger ist, ist ein tiefgreifendes Verständnis für das zu lösende fachliche Problem: Wer das eigentliche Problem nicht verstanden hat, kann wenig zu dessen Lösung beitragen.

Zugegebenermaßen betrifft das allerdings nicht nur Entwickler. Das gleiche gilt auch für Designer, Architekten, Datenbankexperten, das Marketing, und alle weiteren an einem Projekt beteiligten Rollen. Kurzum: Moderne Softwareentwicklung findet in aller Regel in interdisziplinären Teams statt, und es ist Aufgabe dieser interdisziplinären Teams, die Fachlichkeit zu verstehen.

Dafür gibt es verschiedene Ansätze. Einer dieser Ansätze, der inzwischen knapp 20 Jahre alt ist, ist das Domain-Driven Design, abgekürzt als DDD. So wie Test-Driven Design die Tests in den Mittelpunkt stellt, rückt DDD die Domäne in den Vordergrund – also die Fachlichkeit. DDD ist dabei keine technische Methode, sondern ein Vorgehen, um in einem interdisziplinären Team zu einem gemeinsamen fachlichen Verständnis und vor allem zu einer gemeinsamen fachlichen Sprache zu kommen, der sogenannten Ubiquitous Language. DDD beschreibt dabei ein strukturiertes Vorgehen, was der eigentliche Vorteil beim Einsatz von DDD ist.

Insofern lässt sich sagen, dass DDD eine großartige Sache ist. Das Problem ist nur: Sobald man diese Erkenntnis für sich selbst gewonnen hat, gilt es, andere zu überzeugen, auch die eigenen Vorgesetzten. Schwierig dabei ist, dass DDD aller Großartigkeit zum Trotz am eigenen Anspruch scheitert, denn DDD selbst verwendet ein dermaßen wenig intuitives Vokabular, dass es Menschen, die sich noch nie damit beschäftigt haben, erst einmal nichts verstehen. Stattdessen verbringt man viel Zeit damit, Begriffe wie Bounded Context, Aggregate oder Transactional Boundary zu erklären. Rasch entsteht dann der Eindruck, es mit einem höchst komplizierten und überkomplexen Verfahren zu tun zu haben – weshalb man besser beim altbewährten bleiben sollte.

Hinzu kommt noch, dass dem eigenen Vorgesetzten DDD in gewissem Sinne herzlich egal ist: Solange die entwickelte Software funktioniert, nicht mehr kostet als erwartet, und wartbar bleibt, ist aus seiner Sicht alles in Ordnung. Auch hier gilt wieder, dass auch DDD kein Selbstzweck, sondern nur Mittel zum Zweck ist. Trotzdem weiß man, dass das Ergebnis mit DDD besser werden wird als ohne. Was also tun? Wie begeistert und überzeugt man andere Menschen von DDD, ohne sie mit der Komplexität von DDD abzuschrecken?

Genau darum geht es in meiner Session „The DDD Convincing Your Boss Guide“ auf der diesjährigen Developer Week.
Die Problemstellung habe ich wie folgt zusammengefasst:

 

“DDD is a great thing – only your boss doesn’t know about it. The problem: Once you start raving about DDD, he doesn’t understand anything anymore. From his point of view, that’s understandable: He doesn’t care about DDD as long as the developed software works and is maintainable. So how do you pitch DDD to someone who’s not interested in it?”

 

Falls Sie dieses Problem also kennen, oder falls Sie zu denen gehören, die noch überzeugt werden müssen – ich würde mich freuen, Sie in meiner Session begrüßen zu dürfen. Und so viel sei verraten: Es gibt einige sehr gute Gründe, warum man DDD einsetzen sollte, selbst dann, wenn man das noch gar nicht weiß. Seien Sie gespannt!