Domain-driven Design – wer braucht denn sowas?

„Herausforderungen, also ich würde eher sagen, es hat mein Leben irgendwie einfacher gemacht.“

Herzlich willkommen zu „Querverlinkt – Technik über dem Tellerrand“! Nach unserem letzten Podcast zum Thema Programmiersprachen haben wir heute für euch noch eine vertiefende Folge zu unserem Lieblingsthema Softwareentwicklung im Gepäck. Diesmal geht’s um Design-Konzepte in der Softwareentwicklung, genauer gesagt, um Domain-driven Design. Eine Möglichkeit, komplexe Software zu modellieren. Da stellen sich natürlich sofort Fragen: Warum modelliert man und was hat das mit Softwareentwicklung und Softwarearchitektur zu tun? Thomas Sinnwell und unsere Experten, Marcel Zinnow und Michael Bub, erklären es euch. Domain-driven Design, wer braucht denn sowas?

Viel Spaß beim Hören!

Transkription

Thomas Sinnwell: Hallo zusammen! Heute sprechen wir über das Thema Domain-driven Design. Es ist ein sehr spannendes Thema. Um der Frage nachzugehen, worum es sich da genau handelt, habe ich mir zwei Gäste eingeladen. Das ist zum einen der Marcel Zinnow und zum anderen der Michael Bub. Marcel Zinnow kennt der ein oder andere Zuhörer vermutlich schon aus der Podcast-Folge, als wir über das Thema agile Softwareentwicklung gesprochen haben. Und der Marcel verantwortet bei consistec oder er leitet bei consistec sehr große Individual-Softwareentwicklungsprojekte. Schön, dass du da bist. Sei doch bitte so nett und stell dich kurz vor.

Marcel Zinnow: Danke Thomas! Mein Name ist Marcel Zinnow, ich bin seit 14 Jahren jetzt bei der consistec angestellt, habe Informatik studiert an der htw Saarland. Und wie du bereits erwähnt hast, seit mehreren Jahren jetzt Projektleiter für Softwareentwicklungsprojekte in der Telekommunikationsbranche.

Thomas Sinnwell: Danke schön! Michael Bub ist heute in seiner Rolle als Softwarearchitekt mit an Bord. Schön, dass du da bist. Michael, sei so nett und stell dich doch bitte kurz vor.

Michael Bub: Danke Thomas! Mein Name ist Michael Bub. Ich habe Informatik studiert an der htw Saarbrücken. Ich bin dann 2007 als Java-Entwickler ins Berufsleben eingestiegen. Ich bin dann 2011 zur consistec gekommen, immer noch im Java-Umfeld und mache jetzt seit einigen Jahren dort Design- und Architekturthemen für die Projekte, in denen ich tätig bin.

Thomas Sinnwell: Vielen Dank! Kommen wir dann zur Klärung der Frage, was ist denn Domain-driven Design? Um das vielleicht vorweg mal in die Runde zu werfen, treffe ich jetzt mal die Aussage: Ja, das ist eine Möglichkeit zur Modellierung von Software. Aber was heißt das denn? Was bedeutet denn Modellierung von Software?

Michael Bub: Na ja, Modellierung bedeutet letztlich, dass man irgendeine Sache aus der realen Welt in eine Software überführt, sag ich mal. Also wir machen ja Software nicht aus Spaß, sondern wir entwickeln Software, um Probleme zu lösen, die in der realen Welt entstehen. Zum Beispiel, ich möchte ein Produkt verkaufen und brauche dafür irgendeine Software, die mich dabei unterstützt. Und damit ich dieses Problem letztlich in Software lösen kann, muss ich eben diese Problem, das sich in dieser Domäne …

Thomas Sinnwell: Abbildet?

Michael Bub: … muss ich in Software überführen. Und das ist der Versuch, was die Modellierung tut. Also wir gucken uns die reale Welt an und ihre Probleme und ihre Mitspieler. Ein einfaches Beispiel, sagen wir mal, ich müsste jetzt ein Schachprogramm entwickeln, dann muss ich die Regeln von Schach beherrschen. Und dann versuche ich, diese Regeln in eine Software zu packen. Es ist also sozusagen eine vereinfachte Darstellung von einer realen Sache in eine Software hinein. Zum Beispiel sagen wir, egal, für mein Schachspiel, das ich programmiere, wie ein Springer aussieht, weil das Aussehen spielt für meine Problemlösung keinerlei Rolle, aber es ist für mich zum Beispiel relevant, dass es eben ein Springer ist und dass er die Farbe Weiß hat.

Thomas Sinnwell: Okay! Das müssen wir noch ein bisschen vertiefen. Aber mir drängt sich da jetzt oder grad zwei andere Fragen auf: Was hat das denn jetzt mit Softwarearchitektur oder auch mit dem Code zu tun?

Marcel Zinnow: Die Architektur ist auf der einen Seite eine Vorgabe für Softwareentwickler, wie die Software zu modellieren ist, wie die Software aussehen soll, wie die Programmierer das Ganze entwickeln sollen.

Thomas Sinnwell: Also von ihrer Struktur her?

Marcel Zinnow: Von ihrer Struktur her. Genau! Und auf der anderen Seite werden die Entwickler auch eigene Modelle mitbringen. Was dann auch wieder so ein Teil der Gesamtarchitektur ist. Ich denke da zum Beispiel an Datenmodelle. Die Struktur der Daten, die werden im Groben von Architektur vorgegeben, an die sich gehalten werden muss, an die sich die Entwickler halten müssen, aber so richtig im Detail füllen werden das die Entwickler. Genauso sind das die Code-Modelle, es können Sequenzdiagramme erstellt werden, Aktivitätsdiagramme, um bestimmte Aktivitäten zu modellieren. Und das ganze Zusammenspiel, das ist dann eben Architektur, Softwareentwicklung und dann auch, wie wir später noch drauf zu sprechen kommen, die Fachexperten.

Thomas Sinnwell: Wenn ich euch da jetzt richtig verstanden habe, reicht diese Modellierung sowohl in die Architektur hinein als auch in den Code? Korrekt?

Michael Bub: Das ist vollkommen richtig. Also Architektur kann sich auf sehr vielen verschiedenen Ebenen abspielen. Das kann mal sehr, sehr grob gehen bis hin zu, dieses System lebt auf diesem Server in irgendeinem anderen Land und dieses System lebt irgendwo anders. Das kann dann aber auch tief runtergehen bis ins Detail, sodass man schon auch Klassen, Hierarchien angibt, in welchen Beziehungen die miteinander stehen. Also das kann sowohl das große Bild beschreiben, aber auch schon sehr spezifisch, was nachher in einer individuellen Software passieren soll.

Thomas Sinnwell: Gut! Jetzt sind wir auch schon nahtlos bei diesem Thema Softwarearchitektur. Ich denke, so Anfang 1990 wurde das Thema Softwarearchitektur ja ein ganz eigenes Teilgebiet in der Informatik, hat auch einen Raum bekommen. Da haben sich auch viele kluge Leute schon dazu ausgelassen. Aber worum geht’s denn jetzt beim Thema Softwarearchitektur? Ein paar Dinge hast du ja schon genannt.

Michael Bub: Im Grunde genommen geht’s darum, einfach mal einen groben Plan zu haben. Also das Wort Architektur oder Architekt, das kennt man ja zum Beispiel vom Hausbau. Da fängt man ja auch nicht einfach mal an ein Haus zu bauen, sondern man macht sich vorher einen relativ detaillierten Plan darüber, wie das denn mal aussieht. Da kann man nicht einfach mal eine tragende Wand irgendwie wegmachen, die muss schon an eine spezifische Stelle. Und so ähnlich ist es dann auch in der Softwarearchitektur. Also man schaut sich eben an, was muss ich tun, welche Aufgabe muss ich mit dieser Software erfüllen? Und da sprechen wir hauptsächlich von nichtfunktionalen Anforderungen, also was genau der Inhalt ist.

Thomas Sinnwell: Nicht…, was ist das?

Michael Bub: Die nichtfunktionale Anforderung, das ist im Prinzip das Gegenteil der Fachlogik. Also da kommen dann Themen ins Gespräch wie, ich muss irgendeine Antwortzeit garantieren können. Dazu muss ich vielleicht eine gewisse Technik anwenden, um die Software eben so schnell machen zu können. Und andere Thema. Da kann zum Beispiel ein Thema Datenschutz mit reinkommen, das jetzt irgendeine Auswirkung hat darauf, wie ich ein System baue. Das muss ich berücksichtigen. Und all diese Blöcke, die ich brauche, die gewisse Aufgaben erfüllen, die versucht man in der Architektur zu finden und sie zum einen grob aufzuzeichnen und wie sie zusammenstehen im Gesamtsystem. Und versucht auch kurz zu beschreiben, wie man diese benutzt. Also sozusagen eine Komponente bietet eine Schnittstelle an, über die sie benutzt werden kann, und der Rest, sagen wir mal, die genaue Implementierung, was dahintersteckt, ist uninteressant, das ist für die Architektur erstmal uninteressant und wird dann sowieso erst viel weiter unten vom Entwickler mit Leben gefüllt.

Thomas Sinnwell: Das heißt, was ich jetzt da mitgenommen habe, ist, dass es bei der Softwarearchitektur ja also auch um diese nichtfunktionalen Anforderungen geht. Und da war ja auch schon von Performance jetzt die Rede. Ich denke, das kann man ja nahtlos erweitern um Wartbarkeit. Das bedeutet, wenn Software mal fertigentwickelt ist und übergeben ist, dass sie durch andere Leute auch noch, oder auch durch das Unternehmen, das sie erstellt hat, gepflegt, weitergepflegt werden kann, weiterentwickelt werden kann. Es geht auch um Themen wie Zuverlässigkeit. Und du hast am Anfang dieses Beispiel mit Hausbau gebracht.

Michael Bub: Ja.

Thomas Sinnwell: Und da kommt ja auch der Architekt, der macht einen Plan. Dann kommt der Statiker. Dann wird das vielleicht nochmal modifiziert, irgendeine Mauer wird ein bisschen dicker gemacht oder irgendwo wird noch ein Träger eingezogen. Dann steht das. Das ist ja starr. Wie passt denn jetzt das Thema Softwarearchitektur zu agiler Softwareentwicklung? Ist das ein Widerspruch?

Marcel Zinnow: Also erstmal, die Softwarearchitektur ist komplett unabhängig von der agilen Vorgehensweise. Man kann Softwarearchitektur genauso im Wasserfallmodell betreiben wie in der agilen Entwicklung, wie in der agilen Vorgehensweise.

Thomas Sinnwell: Aber wie läuft das dann konkret? Weil dann mache ich ja wohl nicht die fertige Architektur initial und entwickele anschließend agil.

Marcel Zinnow: Genau! Nein, das ist, wie die agile Vorgehensweise das vorgibt, in iterativen Schritten wird auch die Architektur aufgebaut. Das ist aus dem Grund geschuldet, weil sich die Anforderungen eben schnell ändern können. Da bietet sich die agile Vorgehensweise auch genauso an für die Architektur, dass man eben, wenn man die Architektur baut nach den aktuellen Anforderungen, wie sie momentan sind, festlegt. Und wenn sich die Anforderungen ändern, dass man dann auch die Architektur in verschiedenen Intervallen, verschiedenen Schritten ändern kann.

Thomas Sinnwell: Jetzt sind wir aber am Punkt angelangt, da können wir jetzt nahtlos übergehen. Was ist denn jetzt Domain-driven Design so ganz genau?

Michael Bub: Es ist immer ein bisschen schwierig, das ganz genau in einem kurzen Satz zu beschreiben. Sagen wir mal, es versucht, eine Sache wiederzugewinnen, die man mal hatte ganz früher, so zu Anfang der Softwareentwicklung, sagen wir mal so, irgendwann in den 60ern vielleicht. Da hat es sich ergeben, da waren die ersten Softwareentwickler, das waren die Leute aus der Fachabteilung, die das halt gelernt hatten mit dieser Softwareentwicklung, und haben dann die ersten Programme geschrieben für das Unternehmen. Und irgendwann wurde die Informatik halt stärker und größer und wurde eine eigene Abteilung. Und man hatte auf einmal eine strikte Trennung zwischen den Fachexperten und den Leuten, die die Software bauen wollen. Mit dem Domain-driven Design versucht man jetzt an der Stelle die Fachexperten und die Entwickler wieder zusammenzubringen, um ein gemeinsames Bild von dem zu erstellen, was man denn da jetzt tatsächlich tun möchte. Das ist so von dieser Seite her das, was Domain-driven Design zu erreichen versucht.

Thomas Sinnwell: Das heißt, den Leuten in den Fachabteilungen da auch ein Stück weit, ich sag mal, zumindest mal so ein Elementarwissen oder eine konkrete Vorstellung zu vermitteln, um was geht’s da bei der Softwareentwicklung, wie passiert das, wie wird das gemacht. Weil sie das nachher ja auch anwenden müssen und umgekehrt bei den Softwareentwicklern aber auch ein bisschen stärker noch die Fachlichkeit zu etablieren.

Michael Bub: Genau! Also im Grunde versucht man wieder den programmierenden Fachexperten zu gewinnen auf irgendeiner Stelle, damit da jemand kompetent entwickeln kann, was auch tatsächlich der Realität entspricht. Denn wenn man ehrlich ist, ist ja so eine fertige Software hinterher nicht das, was sie eigentlich tun soll. Sie ist das, was die Leute, die sie entwickeln, verstanden haben, was sie tun soll. Und da versucht man halt sehr genau zu sein und eben genau dieses Verhalten der Wirklichkeit dann auch exakt abzubilden und da jetzt möglichst Spielraum für Interpretation auszuräumen.

Thomas Sinnwell: Jetzt spielt ja Fachlichkeit und Fachlogik, das sind ja Begriffe, die schon gefallen sind, eine ganz elementare Rolle bei Domain-driven Design. Aber was dürfen sich denn unsere Zuhörer unter Fachlichkeit oder Fachlogik vorstellen?

Michael Bub: Na ja, das ist, man könnte sagen, bleiben wir noch mal beim Beispiel des Schachspiels, wenn ich jetzt ein Schachspiel entwickeln möchte und das domain-getrieben machen möchte, dann muss ich eben diese Regeln des Schachspiels verstanden haben, ich muss die gelernt haben, muss die anwenden können auf eine Software. Das heißt, ich werde dann mir erklären lassen von Fachexperten, wie es funktioniert, und werde dann mit denen zusammen ein Modell entwickeln, also zum Beispiel in Form eines Bildes könnte man das machen, vielleicht auch als Text, so dass dann hinterher alle derselben Meinung sind, ah, so wird Schach gespielt und nicht anders.

Thomas Sinnwell: Was mir da jetzt gerade einfällt, was denke ich auch immer wieder auch für Fragen sorgt jetzt auch bei Kunden, der Begriff des Pattern oder des Anti-Pattern? Gibt’s hier ein Anti-Pattern? Oder was ist überhaupt so ein Pattern?

Michael Bub: Ein Pattern, dem Namen nach, ist ja eine Sache, die irgendwie immer wieder vorkommt, ein Muster. Und dann gibt’s aber auch so Muster, die kennt man aus der Entwicklung. Da gibt’s ein Singleton zum Beispiel, um nur mal eins zu nennen. Und dann gibt’s aber auch so Muster, die man immer wieder antrifft, die als Lösungen verwendet werden in Softwaresystemen. Die funktionieren zwar, sonst würde man sie ja nicht einsetzen, aber sie haben eher einen schädigenden Effekt. Also sie sind auf irgendeine Art und Weise langfristig nicht gut. Das kann verschiedene Ausprägungen haben. Sie sind vielleicht zu langsam, sie sind vielleicht schlecht zu warten, sie bringen irgendwelche Nachteile mit sich. Und das ist dann typischerweise ein Anti-Pattern.

Thomas Sinnwell: Und wie würde jetzt oder wie sieht das Anti-Pattern bei Domain-driven Design aus?

Michael Bub: Es sind natürlich verschiedene Probleme denkbar, die man da entdecken könnte. Was auf jeden Fall für meinen Begriff das Schlimmste ist, ist, wenn man ein Domain-Modell entwickeln würde, das nicht sozusagen die Spielregeln enthält. Also das jetzt auf Klassenebene gesehen einfach nur Klassen enthält, die einfach Daten beinhalten, aber die keinerlei Verhalten mitbringen. Und das ist genau der Punkt, den das Domain-driven Design auch erreichen möchte. Also in vorherigen Projekten, da kann man sagen, also gibt’s da so diesen Serviceansatz, nenne ich ihn mal. Man hat da diese Datenstrukturen, das ist dann zum Beispiel mein Schachbrett, bleiben wir mal beim Beispiel, und dann gibt’s irgendeinen Dienst, der irgendwas macht mit diesem Schachbrett. Also da ist die Funktionalität, die Operation und das Verhalten strikt getrennt von diesen Daten. Das macht es ein bisschen schwierig, das alles im Überblick zu behalten. Und wenn man ein richtiges funktionierendes Domain-driven Design erstellt, dann hat man das Schachbrett und das Schachbrett hat auch gleich die Operationen, die es zum Beispiel ausführen soll. Also das Schachbrett hätte jetzt vielleicht diese Operation: Mache einen Zug von einer Figur auf ein spezifisches Feld. Das wächst da alles zusammen.

Thomas Sinnwell: Jetzt würde ich gern noch ein bisschen näher auf das Domänen-Modell eingehen bei Domain-driven Design. Also ich habe es wahrgenommen, dass es da ganz viel Fach-Wording gibt, was in Teilen erstaunlich nah an einer Begriffswelt ist, die man auch als Laie ganz gut verstehen kann. Aber das hat ja auch, denke ich, eine Absicht. Da kannst du ja ein bisschen was zu sagen und vielleicht mal ein paar von diesen Begrifflichkeiten erläutern. Michael, kannst du da noch ein bisschen was zu sagen?

Michael Bub: Ja, also wenn man sich Domain-driven Design näher anschaut, da gibt’s ganz, ganz viele Begriffe, die da auftauchen. Ich will mich da mal nur auf ein paar Wesentliche beschränken, die glaube ich so der Knackpunkt sind des Ganzen. Da ist zum einen ein Begriff, der heißt Aggregat. Das ist sozusagen, ich sage immer so salopp, das ist der Star dieser Domäne. Also zum Beispiel jetzt beim Schachspiel wäre das jetzt das Schachbrett, das ist so das Hauptding, mit dem ich operiere. Es ist jetzt, glaube ich, definiert konkret als eine Gruppe von zusammenhängenden Objekten. Also ich stelle mir jetzt vor, wenn ich das Schachbrett designe, dann hat das eben auch irgendwie diese Figuren, die es in sich trägt. Also das ist dann nicht nur ein einsames Schachbrett, sondern das ist dann schon eine komplexere Struktur, das auch eben diese Figuren und ihre Position et cetera in sich trägt. Das wäre in diesem Beispiel wahrscheinlich ein typisches Aggregat. Das Aggregat zeichnet sich dadurch aus, dass es auch die einzige Komponente ist oder die einzige Klasse, wenn man so will, ist, die diese Operation empfangen kann. Es ist dann so geregelt, auch wenn ich diese Figuren habe als einzelne Objekte, dann kann ich keine Figur direkt ansprechen, wenn ich das so modelliere. Wenn die so in dem Aggregat stecken, dann muss ich das immer über das Schachbrett tun. Das geht dann nicht direkt, also auch wieder das Thema Schnittstelle und Kapselung, also ich kann da kein Schindluder treiben direkt mit dieser Figur, sondern das Schachbrett hat da immer ein Auge drauf sozusagen, dass auch der Zug, den ich mache, dass es nicht auf Z5 ziehen soll, ein Feld, das es gar nicht gibt, das muss halt sozusagen das Schachbrett prüfen. Denn seine Konsistenz ist halt auch eine Aufgabe des Aggregats zu gucken, dass ein interner Zustand auf jeden Fall immer valide ist. Also das darf einfach nicht zulassen, dass irgendwer irgendwas machen kann, was zu einem Zustand führt, der irgendwie falsch ist. Das ist so grob die Rolle des Aggregats. Das ist auch, sage ich mal, das wichtigste Ding für meine Begriffe in so einem Design. Ein anderer Begriff, der nennt sich Entität. Der kommt, glaube ich, häufiger vor in der Informatik, auch im Bereich so Datenbank ist das ja ein Begriff, der immer auftaucht. Eine Entität, das wäre jetzt in unserem Schachbeispiel so eine Figur. Das ist ein Ding, das hat auch irgendwelche Informationen, die es mitbringt, aber es hat auch insbesondere eine ID, genauso wie das Aggregat, über die es gezielt angesprochen werden kann. Das heißt, es ist mir nicht egal, welchen weißen Springer ich jetzt ziehen muss, sondern es ist ein spezifischer, und deswegen muss ich den halt auch spezifisch benennen können über eine ID. Und das bilden Entitäten ab. Das letzte Ding, und auch sozusagen das wahrscheinlich am einfachsten zu verstehende, würde ich mal behaupten, ist dann das Wertobjekt. Das hat man auch an anderen Stellen vielleicht schon mal gehört den Begriff. Das ist dann zum Beispiel, also unserem Schachbeispiel könnte das die Farbe sein. Das ist sozusagen ein einfacher Wert. Es könnte ein komplexerer Wert sein. In der Literatur wird gerne Geld als Beispiel genommen. Da hat man dann so eine einfache Klasse mit zwei Attributen, das ist dann der Betrag und die Währung. Und da gibt’s keine ID, weil es ist mir egal, was genau das für zum Beispiel 3 Euro sind, sondern da sind 3 Euro immer 3 Euro, ganz egal, welche es sind.

Thomas Sinnwell: Das hört sich jetzt alles ein stückweit trocken an oder auf alle Fälle mal theoretisch. Was erreicht man denn jetzt mit so einem Domänenmodell ganz konkret? Warum treibt man diesen Aufwand? Warum hat man diese Konstrukte eingeführt?

Marcel Zinnow: Also zum einen ist das Domänenmodell dafür da, um den Fachbereich mit den Softwareentwicklern zusammenzubringen. Gerade bei großen Softwareprojekten können die Funktionalitäten so komplex sein, dass es von einer Person oder von ein paar einzelnen Personen gar nicht mehr zu bewerkstelligen ist. Da ist gerade dieses Domänenmodell dann wichtig als gemeinsame Sprache zwischen den Fachleuten und den Softwareentwicklern, damit man miteinander, damit überhaupt die Möglichkeit besteht miteinander zu kommunizieren. Und eben aus dem Grund, weil die ganze Architektur von einer Software, wenn diese Softwarearchitektur von Anfang an in die falsche Richtung geht, kann das sehr teuer werden fürs Unternehmen. Also man betrachtet immer von Anfang an die betriebswirtschaftlichen und die technischen Anforderungen. Und das wird eben gerade bei DDD im Rahmen dieses Domänenmodells oder mithilfe dieses Domänenmodells umgesetzt.

Thomas Sinnwell: Wenn ich das jetzt richtig verstanden habe, ist doch dann eine sehr enge Zusammenarbeit zwischen Entwicklern und Fachexperten von Nöten?

Marcel Zinnow: Genau! Genau das ist das, was im Domain-driven Design auch verlangt wird. Die Fachlogik steht im Fokus von dem ganzen Design und von der ganzen Architektur der Softwareentwicklung. Und da ist eben das Ziel, dass mit den Fachexperten und mit den Softwareentwicklern zusammen das Domänenmodell ausgearbeitet wird, was die Grundlage ja dann von allem ist.

Thomas Sinnwell: Ja. Darüber hatten wir ja ausführlich gesprochen.

Marcel Zinnow: Genau.

Thomas Sinnwell: Und das steht ja wirklich dann im Fokus.

Marcel Zinnow: Die Vorteile davon sind dann eben, dass man betriebswirtschaftliche Funktionalitäten, dass man den Fokus darauflegen kann, was von den Fachexperten kommt. Genauso wie die technischen Anforderungen und die dann von Softwareentwicklern kommen.

Thomas Sinnwell: Oder vom IT-Betrieb.

Marcel Zinnow: Oder vom IT-Betrieb. Genau! Das ist ein großer Punkt. Ein anderer Vorteil ist, dass man Grenzen auch kennenlernt von einem Projekt oder von den Anforderungen. So ein Projekt hat ja immer ein bestimmtes Ziel, einen bestimmten Fokus, eine Kernfunktionalität, und die ist im ersten Schritt für die Fachexperten auch gar nicht so ersichtlich. Und im Rahmen des Domänenmodells der Ausarbeitungen von den fachlichen Begriffen legt man einfach Grenzen fest. Und anhand dieser Grenzen wird auch für die Fachexperten dann ersichtlich: Was machen die Entwickler? Um was geht’s denn jetzt genau? Wir entwickeln jetzt das Stück Software für eine gewisse Funktionalität beziehungsweise für ein gewisses Ziel, und andere Ziele, andere große Ziele sind dann eben erst mal ausgeklammert. Und das ergibt sich alles im Rahmen …

Thomas Sinnwell: Und das meinst du jetzt mit Grenzen?

Marcel Zinnow: Genau!

Thomas Sinnwell: Also nicht den großen Wurf schon komplett betrachten, sondern im agilen Sinn so die erste Stoßrichtung, den ersten Funktionalitätsblock, der auch sehr, idealerweise dann sehr wertschöpfend ist, und weitere Ergänzungen kommen zu einem späteren Zeitpunkt im Projekt?

Marcel Zinnow: Richtig, genau! Auch ein weiterer Vorteil ist dann auch für die Fachexperten: Man bekommt so ein bisschen den roten Faden für das Projekt. Wenn es größere Projekte sind, allgemein bei großen Projekten sind meistens ja kleinere Projekte untergliedert und da erhalten auch die Fachexperten einen roten Faden, um zu sehen: Diese Vorgehensweise innerhalb des Projekts, wohin führt die, wozu ist die gut? Und wir arbeiten alle gemeinsam, um dieses Endziel von dem Gesamtprojekt zu erreichen.

Thomas Sinnwell: Ich denke, ein spannender Aspekt auch noch für die Leute jetzt aus den Fachbereichen ist es, auch ein Stück weit zu lernen, was vielleicht bei einer aus ihrer Sicht einfachen fachlichen Anforderung im Hintergrund alles implementiert werden muss, an was man vielleicht rein von der Fachseite gar nicht denkt. Und so dieser wechselseitige Aufbau von Verständnis ist, glaube ich, dann auch ein ganz entscheidender Schritt zu einem erfolgreichen Projekt. Und ich würde dann gerne noch mal betrachten: Wenn man denn jetzt so ein Softwareentwicklungsprojekt aufzieht und sich dann entscheidet, Domain-driven Design einzusetzen, wie läuft sowas denn konkret ab? Wir haben jetzt viel über Konzepte, über Begrifflichkeiten, über Zusammenhänge gesprochen. Aber möglicherweise hat der Zuhörer noch gar keine konkrete Vorstellung: Und was heißt das jetzt? Wie sieht das dann in der Praxis aus? Könnt ihr da bitte noch ein bisschen was zu sagen?

Michael Bub: Ich kann jetzt mal versuchen, meine Eindrücke zu schildern. Man läuft insbesondere natürlich dann in Probleme hinein, wenn man mit mehreren Teams arbeitet. Also da muss man schon aufpassen, was man da tut. Also ich hatte eben erwähnt, zum Beispiel beim Aggregat, das muss sicherstellen, dass es konsistent ist, dass eben den Regeln sozusagen des Spiels entspricht. Und wenn man jetzt beliebige Leute an diese Stellen ranlässt, von denen sie vielleicht nicht unmittelbar Ahnung haben, dann kann das nach hinten losgehen. Man ist also gut beraten, auch wenn man diese Software entwickelt, eine gewisse Trennung herbeizuführen zwischen dem Code und den unterschiedlichen Teams. Also da gibt’s auch diverse Möglichkeiten, das zu organisieren. Da gibt’s auch diverse Begriffe zu, die hier aus dem DDD kommen, die versuchen, so gewisse Abhängigkeiten zwischen Teams und ihrer Entwicklung zu koordinieren, sodass man sich nicht gegenseitig unbedingt reinfuscht, dass der eine nicht allzu abhängig ist vom anderen. Das wird da schon so ein bisschen auch diskutiert. Aber unter diesen Begriffen gibt’s auch durchaus einige, die auch gut zur Anwendung kommen können, wenn man zum Beispiel nur ein Team hat. Ich denke da insbesondere, der Bounded Context, wie es genannt wird, das ist ein sehr nettes Mittel, um eine gewisse Grenze zu schaffen in einer Domäne, in der ich eben implementiere, um zu sagen, das ist jetzt genau dieser Kernpunkt. Also ich zerlege quasi etwas Größeres noch mal in was Kleineres und setze da nur genau ein Team drauf. Sodass, diese Fachexperten sind für genau diesen Teil, und andere Teams kümmern sich um andere Sachen. Denn man kann da schnell in die Bredouille kommen. Wenn wir beim Schachspiel bleiben, dann habe ich hier mein Schachbrett in der Domäne, wo ich eben Schach spiele, und jetzt könnte, sagen wir mal, dasselbe Unternehmen das Schachspiel, das will auch Schachbretter verkaufen. Also taucht der Schachbrett-Begriff nochmal auf ganz woanders, wo ich aber Schachbretter verkaufe. Also eine ganz andere Sicht habe auf so ein Schachbrett. Und davon halt eben die Brillen sozusagen nicht mischen, wenn man dann auf Schachbretter schaut. Man muss wissen, welche Brille betrachtet das Schachbrett.

Thomas Sinnwell: Wenn wir jetzt an dieser Stelle angelangt sind, würde ich noch gerne über Kern-Fachlichkeit sprechen. Das ist ja doch auch ein sehr, sehr wichtiger Begriff im Rahmen des Domain-driven Design.

Michael Bub: Ja genau! Man unterscheidet da so ein bisschen eben. Es gibt die Kern-Fachlichkeit und dann so Dinge, ich sag mal, die man notwendigerweise haben muss. Also wieder das alte Schachbrett-Beispiel: Wenn ich jetzt Schach spiele, dann ist es im Wesentlichen mal interessant, dass ich eben die Regeln verstanden habe. Und wenn ich das schon mal implementiert habe, dann kann ich schon mal Schach spielen. Das ist schon mal fein. Und da ist ja dann auch der Wert dahinter für das Unternehmen letztlich. Jetzt gibt’s aber natürlich, na ja, so Sachen, die man eben immer hat. Ich brauche irgendwie eine Rechteverwaltung. Wenn ich Schach spielen möchte, dann muss ich mich vorher ausweisen, als wäre ich Schachspieler. Es darf nicht jeder Schach spielen natürlich, ganz klar. Dann brauche ich auch so eine Art User-Management. Und das ist dann wieder ein eigenes Thema für sich. Das ist dann aber auch, man würde jetzt sagen, ein anderer Baum und Kontext, der in diesem Gesamtkonstrukt Schachspielen zwar vorkommt, der aber jetzt nicht die Fachlichkeit des eigentlichen Schachspiels betrifft. Man würde dann sich eher beim Entwickeln auch auf diese Kern-Fachlichkeit des Schachspiels erst mal beschränken, weil wie gesagt, da steckt der meiste Wert dahinter. Und die anderen Sachen, die sind dann eher so reingeflanscht.

Thomas Sinnwell: So jetzt rein in der Literatur findet man ja dann auch Aussagen, ja, und auch, was die Kern-Fachlichkeit betrifft, da muss man die allerallerbesten Entwickler ansetzen. Was bei mir so beim Lesen dann auch immer so ein leichtes Schmunzeln verursacht hat. Ich brauche ja auch wirklich eingearbeitete Teams und ich würfele ja nicht nach Anwendungsfall die Entwickler immer wieder lustig durcheinander. Wenn ich mal so ein eingespieltes Team habe, hat das ja auch ganz eklatante Vorteile. Wie seht ihr das? Sehe ich das so losgelöst oder gebt ihr mir da Recht?

Marcel Zinnow: Ich sehe das genauso wie du. So ein eingespieltes Team, das hat sehr, sehr viele Vorteile, vor allem, wenn wirklich das Team von Anfang an dabei ist. Ein Softwareprojekt beginnt ja immer mit der Sammlung der Anforderungen durch Interviews, die mit den Fachexperten stattfinden, durch Ausarbeitung von Dokumenten, Anforderungsdokumente. Und das Team, das sind die Leute, die das Ganze ausarbeiten, die sich die Arbeit machen und ins Detail gehen und sich das alles genau angucken. Und wenn das Team dann auch genau die Software umsetzt und das Verständnis ja auch schon da ist durch die ganzen Interviews und durch die ganzen Ausarbeitungen, dann führt das zu wesentlich mehr Erfolg, als wenn ich ein Team die Anforderungen machen lasse und die Interviews, und dann ein ganz anderes Team, die überhaupt nicht in dem Thema drin sind, auf einmal die Software umsetzen lasse. Das führt sich dann über den ganzen Softwareentwicklungsprozess hinweg bis am Ende bis zur Testbarkeit, schlägt das auch wieder zu, dieses Wissen, was erwartet wird, das muss als Gesamtteam kommen. Und zu dem Team gehört dann eben auch der Fachexperte dazu, der dann seine Fachlichkeit testen soll. Wenn diese Leute, wenn die Fachexperten nicht von Anfang an dabei sind, weiß keiner, was getestet werden muss.

Thomas Sinnwell: Gut! Dann möchte ich unser bisheriges Gespräch kurz zusammenfassen. Domain-driven Design ist eine Möglichkeit zur Modellierung von Software mit dem Ziel, fachliche Anforderungen möglichst gut umzusetzen. Die Softwareentwicklung an sich, die erfolgt agil und das in einer Art und Weise, so wie man das kennt. Das Besondere an Domain-driven Design ist nun die Fokussierung auf die fachliche Logik, da haben wir ja ausgiebig drüber gesprochen, und die wird durch viele Aspekte im Domain-driven Design adressiert. Für die Fachseite, und Fachseite kann im eigenen Hause sein, das kann aber genauso gut auf der Seite des Auftraggebers sein, jedenfalls für die Fachseite bedeutet das, dass durch die von den Entwicklern verwendeten Begrifflichkeiten in Kombination mit der agilen Vorgehensweise eine gute und möglichst präzise Verständigung zwischen Entwicklern und der Fachseite entsteht. Gut! Abschließend möchte ich euch zwei persönliche Fragen stellen. Oder was heißt, persönlich, oder von jedem mal wissen: Was seht ihr denn so als die größte Herausforderung in Projekten, die jetzt auf Basis von Domain-driven Design umgesetzt werden? Marcel, magst du starten, oder?

Marcel Zinnow: Für mich ist ganz klar als größte Herausforderung in Projekten mit Domain-driven Design die Kommunikation mit den Fachexperten. Allein schon, weil sich DDD an die agile Vorgehensweise orientiert, und sobald eine agile Vorgehensweise versucht wird, in eine Software oder in ein Unternehmen in einen Softwareentwicklungsprojekt reinzubringen, dann kommt das bei Fachexperten, die das nicht gewohnt sind, stößt das erstmal an Grenzen.

Thomas Sinnwell: Das ist dann noch so der generelle Effekt, den man beim Menschen vorfindet. Es gibt wenige, die sich immer nach Veränderungen, nach Neuem geradezu lechzen. Und bei vielen setzt so eine natürliche Reaktion des Widerstandes vielleicht eher mal ein. Das kenne ich nicht und das heißt also, letztendlich ein Change-Prozess, den man da durchlaufen muss.

Marcel Zinnow: Richtig, genau!

Thomas Sinnwell: Wie sieht’s bei dir aus, Michael?

Michael Bub: Herausforderungen, ich würde eher sagen, es hat mein Leben irgendwie einfacher gemacht. Also ist natürlich erst mal als Entwickler ein bisschen eine Herausforderung, das alles zu verstehen und auch richtig anzuwenden und einfach dahinter zu steigen, wie das eigentlich funktionieren kann. Aber wenn ich mir dann das Endresultat anschaue, dann muss ich sagen, im Vergleich zu Dingen, die ich vorher schon gesehen habe, ich hatte es eben mal kurz beschrieben, wenn man einfach nur diese Klassen hat, die einfach nur Datenstrukturen sind, und dann irgendwelche Services, die darauf operieren. Das macht die ganze Sache nicht einfach verständlich oder lesbar oder sonst wie. Also da bin ich schon auch ein großer Freund davon, dass man diese Fachlichkeit wirklich damit zusammenpackt, wo sie hingehört, nämlich auch zu ihren Daten, auf denen sie operiert. Also die Spielregeln und die Dinge, mit denen gespielt wird sozusagen, direkt in einer Schublade aufbewahrt, sodass ich sofort sehe, was Sache ist, das gefällt mir unheimlich gut an der Geschichte. Und sofern bin ich eigentlich nur begeistert, möchte ich mal fast sagen, und kann eigentlich gar nicht sagen, dass das jetzt eine große Herausforderung war, es war eher eine Erleichterung.

Thomas Sinnwell: Ja super! Vielen Dank, Michael! Im Untertitel zur aktuellen Folge haben wir provokant die Frage gestellt: Wer braucht denn sowas? Ich denke, dass wir diese Frage für Domain-driven Design jetzt erst mal beantworten konnten. Und zusammenfassend können wir festhalten, dass Domain-driven Design eine gute Vorgehensweise zur Umsetzung von Softwareentwicklungsprojekten für alle Unternehmen ist, die ihre Prozesse durch eine Unternehmenssoftware abbilden möchten. Warum will man sowas? Da gibt es sicherlich ganz unterschiedliche Beweggründe. Ein Grund kann sein, dass vielleicht gewachsene heterogene IT-Strukturen abgelöst werden sollen oder die software-basierten Prozesse sind nicht mehr schnell genug und müssen besser skalieren. Es kann natürlich auch sein, dass ein Unternehmen vielleicht noch gar keine gute IT-gestützte Abbildung ihrer Prozesse hat. Warum auch immer Unternehmen sich jetzt für eine derartige Entwicklung entscheiden, Domain-driven Design ist eine sehr gute Möglichkeit zur optimalen Umsetzung der fachlichen Anforderungen. Vielen Dank! Hat mir Spaß gemacht wie immer. Wenn ihr Fragen habt oder Anmerkungen habt, dann schaut doch gerne in die Shownotes. Ich freue mich schon auf die nächste Runde in vier Wochen. Bis dahin, tschüss!

Michael Bub: Tschüss!

Marcel Zinnow: Tschüss!

So das war‘s mal wieder von uns für heute. Wir hoffen, wir konnten euch nochmal ein bisschen mehr in die Welt der Softwareentwicklung entführen und euch gut unterhalten. Wie immer haben wir weiterführende Links zur aktuellen Folge für euch in den Shownotes und wenn ihr Lust auf mehr habt, dann freuen wir uns natürlich, wenn ihr uns abonniert.

Übrigens auf unserem YouTube-Channel gibt’s noch viele weitere Infos und natürlich auch Videos zu unseren Podcast-Themen. Klickt einfach rein!

In der nächsten Folge, am 5. August, kommt dann endlich der versprochene Podcast mit Christian Walter, dem Geschäftsführer der Bechtle-Niederlassung Saarbrücken. Mit ihm sprechen wir über unser gemeinsames Credo im Bereich IT- und Security: Breaking the silos. Wenn ihr wissen wollt, was das ist, schaltet einfach ein. Wir freuen uns auf euch.