Ja, es freut mich sehr, dass trotz der frühen Stunde schon so viele Leute da sind, um über Domain-Driven-Design was zu hören. Wir machen jetzt so einen Rundumschlag, also wir schauen mal, wo das Domain-Driven-Design eigentlich herkommt,

warum die Idee entstanden ist, wie es damals, also Anfang der 2000er, erfunden wurde sozusagen und wir schauen uns halt an, was seitdem passiert ist und warum Domain-Driven-Design jetzt so eine kleine Renaissance erfährt und noch mal ein Blick ist, betrachtet zu werden.

So, über mich kurz. Ich organisiere seit Mitte des Jahres das Domain-Driven-Design-Meetup in Köln, also wer da Interesse hat, kann da gerne mal vorbeischauen. Bei Twitter findet man mich hier unter Sustainable Pays und unschwer zu erkennen, viel Werbung auf den Folien und T-Shirt bin ich Software-Entwickler bei der REWE digital.

Genau, über die REWE kurz. Die REWE ist ja etwas mehr als nur der Supermarkt. Man weiß gar nicht, dass die REWE noch viel, viel mehr macht, das heißt, es gibt hier Touristik-Sparte, es gibt hier die Heimwerker-Sparte, wir sind auch im Ausland sehr aktiv mit anderen Ketten und die REWE macht halt gerade eine Transition durch, das heißt,

weg von dem reinen Offline-Geschäft in das Online-Geschäft, also die Digitalisierung ist auch bei der REWE endlich angekommen und wir haben da so ein neues Unternehmen gegründet, die REWE digital. Die quasi dafür da ist, die ganzen Online-Aktivitäten der REWE-Groofer jetzt voranzutreiben. Genau, und darüber bin ich halt auch mit dem Domain-Öven-Design in Kontakt gekommen.

Das ist das Produkt, was wir im Moment haben, das heißt, das größte Produkt ist im Moment, dass wir einen Lieferservice anbieten für Lebensmittel, das heißt, man bestellt im Web und kriegt die Sachen komplett mit Einhaltung der Kühlkette und so weiter nach Hause geliefert und ja, wir arbeiten dann noch an viel mehr Neuerungen und ja, wer mal Interesse hat, schaut einfach mal rein.

Gut. Woher kommt Domain-Driven-Design? Wir fangen mal ganz früh an, in den 60ern. Es gibt dazu einen sehr, sehr schönen Talk von der DDD Europe, einer Domain-Driven-Design-Konferenz, die es seit zwei Jahren gibt. Da hatte hier der David West,

der hatte da erzählt, wie quasi, wo Domain-Driven-Design herkommt, wo es hingeht und so weiter und man sieht es ja auch an seinem Äußeren, der ist jetzt schon ein etwas älteres Semester, er weiß, wovon er redet und zumindest fing er damals an, bei einer Bank zu arbeiten als Softwareentwickler und er war damals der erste reine Softwareentwickler, der in der Bank gearbeitet

hat, sonst waren die ganzen Leute, die mit den Computern zu tun hatten, das waren Banker, die hatten sich halt das Computer ein bisschen drauf geschafft, waren aber per Definition Banker, also vom Fach. Das heißt, als es damals angefangen hat, war es halt so, es gibt halt sehr viele Fach-Experten und ein paar von denen sind halt auch Software-Experten.

Das heißt, es gab da noch nicht so was wie eine Trennung von diesen beiden Disziplinen. Das heißt, wer mit Computern zu tun hatte, kam vom Fach her und wusste auch, wie das alles so funktioniert. Im Lauf der Zeit ist es dann so, dass halt der IT-Sektor immer weiter wächst, wie auch der David West, der war halt der erste Nicht-Banker in dieser Bank

und wie gesagt, mit der Zeit konnten einfach die ganzen Fach-Experten nicht mehr dieses ganze Software-Entwicklungs-No-How oder IT-No-How abdecken und es hat dann halt so eine Spezialisierung eingesetzt und eine eigene Bewegung ist gestartet, die quasi unabhängig vom Fach sich dann um die technologischen Probleme gekümmert hat.

Und das ist halt immer weitergegangen, immer weitergegangen, die Technologie ist ja heute riesengroß und die Trennung ist halt unaufhörlich weitergegangen. Das heißt, Technologie und Fachwissen sind quasi schon getrennte Disziplinen, was natürlich auf der einen Seite gut und verständlich ist. Das heißt, es gibt ja sehr viele neue Herausforderungen, die auch von Experten bewältigt werden müssen.

Auf der anderen Seite ist halt der Dialog schwerer geworden. Das heißt, mal auf der einen Seite Experten, auf der anderen Seite Experten, wie schafft man es, dass die trotzdem noch effektiv zusammenarbeiten? Denn dieses Auseinanderdriften hat halt auch sehr viele schlechte Symptome mit sich gebracht.

Das heißt, die Softwarequalität war wirklich schlecht, wenn man mal 20 Jahre zurückblickt. Symptome, ich sag mal, die Informatik ist entstanden. Das heißt, die Leute, die früher noch im Fach gearbeitet haben, die haben jetzt quasi nur noch Technologie gemacht, die haben eigene Ausbildungszweige durchlaufen, die haben quasi die Sache eher aus der technologischen Brille betrachtet und nicht mehr geschaut,

wie wenden wir diese Sachen jetzt eigentlich in der Realität an, um Probleme zu lösen? Eine unglaubliche Professionalisierung ist eingetreten. Das heißt, es gibt jetzt Firmen, die nur noch Technologie machen, in gar keiner Domäne mehr verhaftet sind. Auf der anderen Seite hat man das natürlich zur Kenntnis genommen und gesehen, okay,

IT ist jetzt sowas was Eigenes, das können wir uns dann einfach billigstmöglich dazu kaufen. Das heißt, wir können das alles outsource nach Indien und die machen das alles für uns und wir können uns auf unser Fach konzentrieren und sind fein raus. Oder andernfalls sagt man, die IT hat es wieder versaut und wir kämen ja

so schnell voran, wenn es nicht diese IT gäbe und uns da zurückhalten würde und wie gesagt, es ist eigentlich diesem Phänomen geschuldet, dass beide Disziplinen irgendwie auseinanderlaufen und nicht mehr miteinander sprechen. Das heißt, schlechte Software, schlechte Stimmung und wenig Fortschritt. Das kurz zur Exposition. Also da standen wir so vor 20 Jahren.

Jetzt schaue ich mal, wo das Domain-Ribbendesign da aufgepoppt ist. Das heißt, irgendwie war das Bedürfnis da, dass diese beiden Seiten ja doch wieder so zusammenfinden müssen und da die Entfremdung etwas zurückgedreht wird. Und um diese Zeit sind halt sehr viele Disziplinen entstanden, die das ganze Problem aus einer unterschiedlichen Perspektive betrachtet haben.

Das heißt, zum Beispiel die Softwareleute haben sich gedacht, wir können das Problem schlechter Software lösen, indem wir einfach bessere Software schreiben. Das heißt, hat sich die Software Craftsmanship Community gebildet, die halt Wert darauf legen, handwerklich guten Code zu schreiben und

versucht haben, das Problem eher technisch zu lösen, also ein valider Ansatz, will das nicht schlechtreden, aber es ist halt sehr stark aus der Technologiebrille gesehen. Extreme Programming geht schon ein bisschen mehr, so die Fachrichtung, weil ja auch das ganze Continuous Deployment und so weiter da mit kam. Aber trotzdem ist halt hier auch so die Sache,

wir wollen vielleicht eher testgetrieben und eher das Entwickler untereinander pairen, aber nicht pairen mit den Fachexperten. Also, die Entwickler können gerne pairen, aber nicht auch die Fachexperten. Genau, und andere Sachen, wie zum Beispiel Scrum, wo es dann eher darum geht, was haben wir denn für ein Framework, wie wir zusammenarbeiten, welche Meetings gibt es da vielleicht, welche Artefakte werden da gepflegt.

Das heißt, das bringt schon mal die Fachseite und die Softwareseite irgendwie zusammen, aber es regelt gar nicht, wie die wirklich zusammenarbeiten sollen. Genau, und auch hier zum Beispiel Lean Startup, das sagt halt eher, okay, wir haben schlechte Software, wir müssen einfach schauen, dass wir flexibler werden, wir müssen schneller

neue Produkte bauen, also MVP und Pivot sind ja so Begriffe, die aus der Ecke kommen, die das ganze halt dann sehr aus der Fachseite betrachten. Ja, und auch Kanban, was halt eher so aus der Fertigung kommt, wo halt auch eher geschaut wird, ja, wir haben schlechte Software, müssen einfach schauen, dass wir vielleicht unseren Durchfluss der Entwicklung schneller machen. Das heißt, das sind alles so Ideen, die im Prinzip dieses eine Problem lösen wollen.

Genau, und einer dieser Strömungen ist halt auch das Domain Driven Design, was ich euch jetzt mal in den Grundzügen ein bisschen näher vorstellen will, denn beim Domain Driven Designer sagt man eher, okay, wir haben die Fachseite und wir haben die Softwareseite, vielleicht müssen die beiden einfach mal zusammenarbeiten, also nicht nur zusammen in Meetings sitzen, sondern wirklich zusammenarbeiten.

Genau, entstanden ist das 2004, der Eric Evans hat das bahnbrechende Buch damals geschrieben, das gilt immer noch so als der Meilenstein des Domain Driven Designs. Heute etwas schwieriger zu lesen, komme ich gleich noch mal drauf zu, warum, aber von

den Ideen her ist das ein super originelles Buch und auch heute noch mit Abstrichen lesenswert. Ich will euch jetzt mal kurz das kleine Einmalreins des Domain Driven Designs nahebringen. Wer von euch kennt Domain Driven Design schon?

Wer verwendet das so im Alltag? Cool. Also ich habe jetzt mal drei Aspekte rausgesucht, die mir besonders wichtig sind rüberzubringen, das heißt erst mal namensgebend ist ja schon die Domain, also die Domäne, was ist das eigentlich genau? Das bezeichnet die Fachlogik und die Fachlichkeit eines Geschäftsfelds oder halt auch das Anwendungsgebiet und der Einsatzbereich einer Software,

also welche Probleme will man eigentlich lösen mit einer Software, um nochmal auf die Rewe zurück zu kommen, das heißt wir haben quasi das Problem, wir haben hier Kunden, wir haben hier Waren, wie schaffen wir das, dass der Kunde mit den Waren nach Hause geht? Das ist unser großes Problem.

Das Domain Model ist eigentlich so der Clou, wo quasi die Zusammenarbeit stattfindet zwischen Fachexperten und Software-Experten. Die Idee ist folgende, ich habe quasi hier meine Fachexperten, ich habe hier meine Software-Experten und wir müssen es quasi schaffen,

aus der komplexen Domäne, aus diesem komplexen Anwendungsgebiet ein Modell zu extrahieren, was reduziert ist und von der Komplexität eher klein ist, was ich auch dann eben gut umsetzen kann in ein Modell, was ich in Code übersetzen kann. Das heißt ich muss erstmal schauen, welche Sachen aus meiner Domäne möchte ich überhaupt modellieren, damit ich sie halt in Code abbilden kann.

Wie jetzt so ein Domain Model aussieht, ist jetzt relativ frei, das heißt es können jetzt UML-Diagramme sein, es könnte jetzt einfach Text sein, es geht halt darum, dass man ein gemeinsames Verständnis schafft, wenn man jetzt sehr technikaffine Fachleute hat, könnte das auch Code sein von mir aus.

Wichtig ist halt nur, dass es an einer Stelle gekapselt ist und wie gesagt die Intention rüberbringt, das zum Domain Model und das etwas sperrige Wort hier, das ist die Ubiquitous Language, man könnte das mit ubiquitäre Sprache

übersetzen, was es jetzt nicht besser macht, ubiquitär heißt sozusagen allgegenwärtig, wichtig ist, dass man eine Sprache hat, mit der man quasi das Domain Model beschreibt, das heißt man verhindert jetzt nicht irgendwelche Begriffe,

die einem so einfallen, sondern man versucht eine Sprache zu finden, die aus der Domäne kommt und mit dieser Sprache das Modell zu beschreiben, damit eben Fachexperten und Software-Experten dieselbe Sprache sprechen und dass die Ubiquitous Language einen großen Einfluss hat und dass quasi der Kern auch des Domain Driven Designs zeigt, dass zum Beispiel der Eric Evans sich als Domain Linguist bezeichnet,

also die Sprache ist ein sehr großer Bestandteil eben des DDDI, so was kennt man vielleicht, ich hoffe das ist jetzt nicht zu klein von der Schrift her, die Welt, wie sie von einem objektorientierten Programmierer gesehen wird, da gibt es hier

zum Beispiel den Entertainment Provider Singleton oder das Glas Wasser ist der Thirst Quencher Container oder das Peephole hier ist der Visitor Monitoring Interface oder am besten der Sofa ist der Multi-Bud-Supporter, man lacht, man kennt das aus dem Alltag,

gerade wenn man so aus der Java Welt kommt, begegnet das einem doch immer noch sehr häufig und das kommt aus keiner Domäne, das sind jetzt Kunstwörter, die aus irgendwelchen Patterns kommen, aus irgendwelchen Konventionen usw., das sollte man sich halt irgendwie abschmecken so was in Modellen zu verwenden, weil das die Fachseite natürlich überhaupt nicht versteht so was.

Also wie gesagt, wenn man so was als Domain hätte, wäre das das TV, das wäre das Sofa, das Peephole, das Bild, das, wie heißt das, das Rollo, sagt man sowas, Jalousie,

genau, habe ich noch gescheite Notizen dazu, ja wie gesagt das Wichtigste ist halt eben, dass das die allgegenwärtige Sprache ist, die dann auch das Domain Modell beschreibt. Das sind die drei Punkte, ich mache mal ein kurzes Beispiel, ein Exkurs, wir gehen mal in eine Domäne, die an sich schon relativ abstrakt ist, das ist das Schach,

wir vergessen jetzt mal kurz die Schachregeln, die wir jetzt so kennen und stellen uns mal vor, die sind irgendwo aufgeschrieben, die Schachregeln, und wir haben gehört, es gibt dieses coole neue Spiel Schach und wir würden das gerne mal modellieren, und da gehen wir mal zu einem Schachexperten hin, der das wohl kennt und für den das dann alles klar ist und wir als Entwickler kennen das halt überhaupt nicht,

und dann fängt man halt an zu modellieren, dann sagt man hier, ich würde gerne mal so ein Schachspiel machen, dann sagt halt der Schachexperte, das ist kein Spiel, das ist, wir spielen immer eine Partie Schach, also Partie ist schon mal eine Sache, die man modellieren möchte. Okay, man spielt das hier wohl auf diesem Viereck da, ja das ist das Brett, das ist das Schachbrett,

und dieses Muster, was da drauf ist, wie nennt man das, ist das wichtig oder ist das nur Dekoration? Nee, das sind die Felder, die sind sehr wichtig, warum sind diese Felder wichtig? Man sieht es ja schon, dass da so Buchstaben und Zahlen dranstehen, A, A bis H und 1 bis 8, das heißt, wofür macht man das? Ja, ich will die Felder natürlich genau identifizieren können,

okay, dann kommt das in ein Modell rein, das heißt, ich habe jetzt eine Partie, eine Partie besteht aus einem Brett und das sind irgendwie Felder auf dem Brett. Klingt soweit ganz gut, ja und da stehen ja so komische Püppchen drauf auf dem Brett, haben die irgendeinen Sinn oder? Ja, das sind keine Püppchen, das sind Figuren, nennen wir das und also die können da draufstehen, vielleicht auch nicht und

die haben auch Namen, das gibt es zum Beispiel hier, oh das ist ja so ein kleines, ein Pony oder was ist das? Nee, das ist ein Springer, nennen wir das. So fließt halt so die ubiquitäre Sprache langsam in das Modell rein und wir bilden das halt in einem Modell ab.

Mein Fehler, genau und so geht es halt weiter. Man könnte fragen, oh wer fängt denn jetzt an bei dem Spiel? Der jüngste Mitspieler oder? Nee, es fängt immer der mit den weißen Steinen an. Ja und bewegen die sich auch? Ja, ich kann jede Figur eine bestimmte Gangart bewegen, also Gangart ist dann auch was, was im Schach wichtig ist.

Und so habe ich vielleicht schon mal eine Struktur geschaffen und jetzt, okay, die Figuren da stehen jetzt alle auf dem Brett rum, ist das gewollt, dass die so da stehen? Dann sagt man, ja, das nennt sich die Grundstellung. Dann denk mal, ah, ich könnte das hier mal zusammenfassen, die Sachen, die ich hier habe, das ist dann wahrscheinlich sowas wie eine Stellung und der default ist dann eine Grundstellung.

Und all die Sachen, die ich eben hier aufschreibe, das sind halt Sachen, die ich vielleicht später aus diesem Modell als Objekte modellieren kann und so quasi eine eins zu eins Übersetzung habe von dem Modell. Das heißt, ich habe jetzt nicht nur sowas, dass ich hier mir die Nomen raussuche und die quasi als Objekte machen, sondern ich möchte auch wissen hier,

die können jetzt irgendwas machen, die Spieler zum Beispiel ziehen, das ist ja wichtig. Das heißt, ich kann jetzt nicht nur ziehen, sondern ich kann jetzt nicht nur sagen, die Figur zieht von Feld A nach Feld B, sondern ich denke, okay, die drei Sachen gehören hier irgendwie zusammen, ich modelliere das mal als ein Zugobjekt zum Beispiel. Und so findet man eben mit dem Fachexperten zusammen immer bessere Begriffe für

die Konzepte, die es eben gibt in der Domäne und kann die da zusammenfassen. Genau, so Sachen wie jetzt Pad, Mat, Remie, ist alles schöne Sachen. Natürlich, man muss jetzt nicht das ganze Schach abbilden, wie es ist, sondern man kann sich die Sachen raussuchen, die für die eigene Implementation halt wichtig sind.

Das heißt, sowas wie eine Bedenkzeit oder eine Schachruhe brauche ich vielleicht gar nicht, wenn ich ein einfaches Schachspiel modellieren möchte, das kann ich einfach weglassen. Das ist dann Teil der Domäne, aber nicht Teil meines Domainmodels. Auch so Sachen hier aufgeben, Remie anbieten, ganze Spielanalysebegriffe kann ich alles ignorieren, wenn ich einfach nur ein ganz privales Schachspiel modellieren möchte.

Genau, ein anderer wichtiger Bestandteil ist das Modellierens, dass ich halt schauen muss, dass ich mein Modell vor ungewollten Veränderungen schütze. Das heißt, ich will halt vermeiden, dass halt irgendwie jetzt ein ungültiger Zustand auf meinem Bretter erscheint, dass da irgendwie drei Könige stehen oder sowas.

Das heißt, ich muss halt Sorge dafür tragen, dass in dem Modell bestimmte Innenvarianten greifen, die dafür sorgen, dass es immer ein konsistenter Zustand ist. Das heißt, die Figuren dürfen sich nur der entsprechenden Gangart bewegen, dann wäre das zum Beispiel, der eigene König darf nicht ins Schach geraten.

Das heißt, ich würde halt in meiner Zielenmethode quasi eine, vielleicht eine Funktion aufrufen, die halt genau das prüft und die heißt eben, genauso ist der eigene König ins Schach oder sowas. Dass man das auch als Fachexperte noch begreifen kann.

Genau, also wir haben quasi die Begriffe, wir extrahieren aus der Domäne ein Modell, wir wollen das Modell in semantischen Code überführen und wir wollen das Modell schützen vor ungewollten Veränderungen. Diese drei Sachen sollten aus dem Beispiel hervorgegangen sein. Genau, Zeit für ein Schluck Wasser.

Also nochmal zu rekapitulieren, Domäne ist das Anwendungsgebiet, das Fachgebiet, die Fachlogik. Das Domänenmodell ist die Reduktion, die Abstraktion der Domäne auf meinen Anwendungsfall und die ubiquitäre Sprache ist halt die Sprache, die halt genau dieses Domänenmodell beschreibt.

Gut, wie war das denn jetzt Anfang der 2000er? Wir hatten noch immer noch diese Situation, dass quasi Software-Experten, Fachexperten sind voneinander entfremdet. Wir hatten die ganzen Disziplinen, die da aufpoppen und versuchen diese Entfremdung zu heilen und gewonnen hat so der Agile-Komplex, würde ich sagen.

Das heißt, das ist das, was sich auch durchgesetzt hat irgendwie und auch mal in der Fachwelt irgendwie einzugehalten hat. Das heißt, das kennt man jetzt irgendwie, Agile, insbesondere Scrum, das ist sehr enterprise geworden und die anderen Disziplinen sind da vielleicht so ein bisschen ins Hintertreffen geraten.

Ich will das auch nicht schlechtreden, also das sind schon gute Sachen, die das mit sich bringt, das ganze Agile und das Scrum. Es ist halt so ein bisschen entartet, würde ich sagen, in den letzten Jahren. Und man sollte vielleicht nicht mal wieder so auf die Wurzeln besinnen und DDD ist davon vielleicht eine Disziplin, die der ersten Welle des Agilen leider nicht mitgekommen ist.

Das heißt, ich komme mal auf das Buch zurück von dem Eric Evans, das war leider so, das sagt er heute auch selbst, dass es leider er die Kapitel falsch rum beschrieben hat. Das heißt, die spannenden Sachen, die sind so Kapitel 14 und 15 und die

ganzen, also die strategischen Patterns nennt er das und die eher für Entwickler interessanten Sachen, also wie man jetzt wirklich, also Building Blocks nennt er das, wie ich jetzt wirklich das in Code abbilde. Das sind halt fünf Kapitel direkt am Anfang und da liest man dann drei von und hat jemand das Buch gelesen hier im Publikum oder auch durchgelesen?

Ach, das sehe ich schon hier. Man lernt erstaunlich viele Leute kennen, die das mal so angelesen haben und dann so ungefähr wissen, was es ist, aber halt den Schluss da nicht kennen. Wie gesagt, jetzt ist das halt leider in so eine Technologie-Ecke gerutscht und hat da nicht die große Anhängerschaft gefunden.

Also das war das Domain-Driven-Design bis so 2005, würde ich sagen. Und was seitdem passiert ist, zeige ich euch in dem letzten Abschnitt. Achsofalls, Fragen übrigens sind, man kann mich jederzeit unterbrechen. Jederzeit. Sehr gerne.

Das stimmt natürlich. Also wie gesagt, nicht zuletzt hat das Jahr gewonnen, das Scrum.

Es ist einfach eine schlechte Präsentation. Domain-Driven-Design ist eigentlich eine ganz einfache Sache, aber man kann sie natürlich auch sehr kompliziert erklären.

Großartig. Genau. Genau. Ja, ja. Genau. Ja, es fehlt halt so das Memen irgendwie, was das irgendwie so in die Masse transportiert.

Ja, guter Kommentar. Dankeschön. Ich finde, dass Scrum halt sehr stark prozessorientiert ist. Das heißt, das regelt halt sehr wenig, wie man jetzt wirklich zusammenarbeitet.

Oder es regelt eher so das Drumherum, dass ich die Art der Fakta habe, wie so ein Backlog zum Beispiel, welche Meetings ich haben soll, wer da drin sitzen soll. Oder es regelt jetzt nicht genau, wie die Arbeit aussieht, die da drin gemacht wird in diesen Meetings.

Wie gesagt, ich finde schon, das sind halt keine Sachen, die unbedingt konkurrieren, sondern sich vielleicht ergänzen. Und es wird im Moment eher etwas monothematisch ausgelegt, so wie ich es in der Branche kenne. Also ich finde schon, dass der Modellierungsaspekt eher nochmal ein bisschen nach vorne kommen sollte. Und DDD ist vielleicht eine Art, das zu tun, so würde ich das sehen.

Gut. Okay. Oh, Entschuldigung. Ich fange sofort damit an. Entschuldigung, ja. Ja.

Ja, nee, nee. Das ist auf keinen Fall.

Genau. Das wollte ich auch nicht sagen. Also die Sache war, dass DDD und Scrum sich natürlich ergänzen und nicht widersprechen, bin ich absolut dabei. Das sind halt viele Sachen, die ein ähnliches Problem lösen wollen, mit unterschiedlicher Perspektive und auch unterschiedliche Ansätze bringen. Man müsste halt eher versuchen, das nochmal durch einen Wolf zu drehen und da noch was besseres rauszubringen.

Denn wie gesagt, der Einwand kam eben auch, die Sachen sind halt schon alt. Das Wissen ist alles da und man sollte sich da nicht auf einzelne Disziplinen versteifen, die vielleicht gerade hip sind, sondern den Werkzeugkasten gerne erweitern.

Gut. Ich mache mal weiter, was seitdem passiert ist. Wie gesagt, wir haben jetzt diesen großen Agile-Komplex, der dazu gekommen ist. Die Frage ist jetzt, ist DDD, so wie es inzwischen interpretiert wird, vielleicht sowas, was helfen kann, die ganzen Sachen, Software-Experten, Fahr-Experten und auch das Agile so ein bisschen zusammen wiederzubringen.

Das heißt, sich wirklich als eine Agile-Disziplin darzustellen, die es wert ist, jetzt nochmal verwendet zu werden. Dazu habe ich zwei Beispiele mitgebracht. Das heißt, das erste ist der Bounded-Context und das zweite ist das Konzept von Domain-Events.

Bounded-Context sind auch was, was in dem Buch von Eric Evans vorkam, leider weiter hinten. Wir haben ja das Beispiel hier von der Rewe gehabt, also was muss ich wirklich tun, um dem Kunden Waren zu bringen. Es ist natürlich nicht ein großes Problem, was wir haben, sondern in Wahrheit haben wir viele kleine Probleme, die wir auf dem Weg lösen müssen.

Das könnte man jetzt als Subdomänen zum Beispiel betrachten. Genau, und jetzt kommt hier die Folie, auch du hast es eben angesprochen. Ich habe hier quasi die Unterscheidung zwischen Problemraum und Lösungsraum. Das heißt, meine Subdomänen sind quasi der Problemraum, also die Fachsicht auf das Ganze,

während dann der Bounded-Context den Lösungsraum beschreibt, also wie ich quasi diese Probleme, die in den Subdomänen gefasst sind, dann in Software gieße und dann eben in einem Kontext umsetze.

Genau, das Ganze sieht wie folgt aus, man sieht hier die gestricheten Linien, die immer die Domaingrenzen beschreiben und man sieht darüber gelegt in den durchgezogenen Linien die Kontext, also das sind wirklich die Softwareprodukte. Also hier so etwas Großes, das wäre dann irgendwie ein fettes Legacy-System, was irgendwie drei Domänen abdeckt

und in dem Sinn muss ich quasi, wenn ich hier was mache, immer mit drei Parteien reden und da Änderungen absprechen zum Beispiel und vielleicht auch mit drei Entwicklerteams reden oder keine Ahnung, oder drei, sorry, mit drei Fachabteilungen sprechen. Genau, wichtig ist jetzt der Bounded-Context, ist halt in sofern bounded, dass ich quasi für jeden Kontext mir so ein Domainmodell überlege,

dass ich quasi in den Bounded-Context anwende und auch natürlich dann quasi, weil ja eine ubiquitäre Sprache immer ein Domainmodell betrifft, habe ich halt quasi pro Bounded-Context immer ein Domainmodell, was durch eine ubiquitäre Sprache beschrieben wird.

Das heißt, die Sprache ist halt wirklich kontextabhängig. Genau, und wenn man das jetzt wirklich auf die Spitze treiben würde und dann würden Problemraum und Lösungsraum natürlich sich sehr schön überlappen. Das heißt, ich hätte das fachliche Problem eins zu eins in eine technische Lösung übersetzt und ich hätte genau die Zuordnung von Fachexperten zu Softwareexperten.

Genau, in der Realität ist das leider selten der Fall. Eine Modularisierungsstruktur, wie meinst du das? Ja, das ist natürlich eine Art von Dekomposition, ich weiß jetzt nicht, das ist jetzt etwas…

So, ich habe es echt. Ich habe optimale Dekomposition vorhanden. Da gibt es zwei einfache Grundregeln.

Das ist optimal gestaltet und eine Modularisierung des Moduls in einem hohen inneren Zusammenhang hat und die Schnittstellen zwischen den Modulen so dünn wie möglich sind. Die beiden einfachen Regeln. Meines Erachtens ist das Modell ist Softwareengineering. Das ist das, was es hier überhaupt gibt und die soweit einfachen Regeln. Ja, das würde ich genauso sehen.

Also, es ist schon eine Art Modularisierung. Das heißt, ich muss quasi so ein konzeptuelles Ganzes irgendwie finden, was ich zusammenfasse und ich muss das irgendwie weghalten von allem, was das irgendwie verwässert oder stört. Und wie gesagt, eine sehr hohe Kohäsion und eine sehr geringe Schnittstellenmenge, die halt dann auch wohl definiert ist und auch es vor Korruption schützt.

Ja, okay. Das wäre erstmal alles, was ich dazu sagen will. Genau. Wie wäre das denn jetzt? Natürlich will ich in einer sehr großen verteilten Anwendung auch mal Konzepte betrachten, die jetzt vielleicht nicht in meinem Kontext liegen.

Zum Beispiel, wenn ich jetzt hier bei Rewe Waren ausliefern will, muss ich natürlich wissen, was hat der Kunde am Anfang für eine Adresse eingegeben, zum Beispiel. Das heißt, ich muss halt schauen, wie übersetze ich jetzt Sachen aus dem einen Kontext in den anderen Kontext. Also auch hier wieder die Sprache, das heißt, ich übersetze quasi von der einen in die andere. Ich habe hier mal ein Beispiel mit sehr kleiner Schrift.

Bei Rewe haben wir zum Beispiel hier am Anfang so einen Customer Data Service, der halt Kundendaten verwaltet. Das sind halt Sachen, die der Kunde in seinem Konto zum Beispiel eintippt. Und natürlich gibt es hier unten zum Beispiel so etwas wie den Checkout Service, der dafür sorgt, dass halt die Sachen, oh, das Checkout Service ist vielleicht kein gutes Beispiel.

Vielleicht haben wir eher der Delivery Service, der jetzt die Sachen an den Kunden ausliefert. Für den sind natürlich jetzt ganz andere Sachen, ganz andere Attribute des Kunden interessant als jetzt vielleicht für das Kundenkonto. Das heißt, das Kundenkonto hat vielleicht hier viel mehr Sachen, wie zum Beispiel die Payback Nummer, die er da eingegeben hat.

Hier unten interessiert mich keine Payback Nummer von einem Kunden. Das heißt, im Übersetzungsschritt kann ich quasi die Sache einfach fallen lassen. Andere Sache, wenn ich zum Beispiel jetzt eine Lieferadresse hier habe, die will ich natürlich übersetzen. Ich kann die natürlich dann hier noch anreichen, dass ich sage, ich will zu der Lieferadresse jetzt noch eine Geo-Koordinate ermitteln, damit der Lieferfahrer weiß, wo er dann genau hinfahren muss. Das heißt, dann so kann ich quasi gewährleisten, dass ich Kunden vielleicht nur in dem System anlegen kann.

Ich kann sie aber trotzdem hier auf eine Queue zum Beispiel legen und noch in anderen Kontexten dann irgendwie interpretieren. Genau, das wäre so der bounded context.

Ich komme jetzt zur Sache, die nennt sich Conway's Law. Das muss in jedem DDD-Vortrag einmal erwähnt werden, sonst ist es kein DDD-Vortrag. Hier ist die Slide und die Aussage ist relativ banal. Das heißt, dass Software oder Architekturen quasi immer dem Muster folgen, wie halt die Leute organisiert sind, die quasi diese Systeme erstellen.

Das heißt, wenn ich jetzt ein Team habe hier und ein Team in Australien und sage denen, baut bitte eine Software, sind das nachher zwei verschiedene Systeme, die über eine API miteinander sprechen. Einfach weil die Leute genauso miteinander arbeiten. Die haben vielleicht ihren ISC-Kanal, über den die reden und die Software redet dann über eine Press-Stützstelle oder über eine Queue oder wie auch immer.

Dieses Muster kann man eben sehr gut verfolgen und man kann sich das natürlich in dem DDD jetzt zunutze machen. Dass man sagt, ich betrachte gar nicht den Weg so rum, sondern sag einfach, was ist denn meine Zielarchitektur? Also schön verteilt mit separaten Kontexten und dann baue ich quasi einfach meine Teams so, dass sie dieser Struktur genügen.

Also quasi so eine Umkehrung des Conway's Laws. Habe ich da ein Beispiel? Ja, bei Revo zum Beispiel. Wir hatten mal angefangen mit einem fetten Monolithen, den hatten zwei Teams betreut.

Dann kam ein Architekt hier dabei, finde den Fehler und dann haben wir eben angefangen mit dem Konzept von Squarts und Microservices. Das heißt, wir haben angefangen mit Squarts sozusagen abzubilden, dass wir einzelne Subdomänen auf Teams zusammenfassen und denen auch einzelne Services geben, die quasi fachlich geschnitten sind.

Genau, das treiben wir jetzt immer weiter, immer weiter. Das heißt, man findet hier immer mehr diese Deko-Komposition, die man jetzt in der Domäne hat, die man in der Software hat, auch in den Teams wieder. Genau, das heißt, im Moment haben wir so diese vier fachlichen Säulen quasi.

Das heißt, der Kunde kommt auf die Seite und soll auf der Seite bleiben. Der kann Sachen suchen und finden. Der kann hier seinen Warenkorb vollmachen und hier dann quasi den Checkout durchlaufen und die Sachen bezahlen und so weiter. Und im letzten Schritt kriegt er die Sachen nach Hause geliefert.

Und ja, so haben wir eben vier Domänen. Wir haben vier verschiedene Systeme, sage ich mal, und vier verschiedene Squarts, die dann wieder einzelne Teams haben, die sich um diese Sachen kümmern. Genau, also das ist das Converse Law. Das heißt, ich kann es anwenden, um quasi nicht nur Fachlichkeit und Software zu skalieren, sondern auch die Teams, die das eben betreuen.

Ich riskiere gerade mal einen Blick auf die Uhr. Oh, okay. Wir sind aber ganz gut in der Zeit. Self-Content Systems. Kennt ihr den Griff jemand? Ja, cool. Sehr schön, drei Hände, finde ich gut.

Was sind Self-Content Systems? Es ist ja so, dass man früher mal gedacht hat, es wäre eine gute Idee, Software technologisch zu schneiden. Das heißt, man packt alle Views in ein Paket oder alle Repositories in ein Paket und so weiter. Was natürlich auch damals vielleicht den Vorteil hatte. Ich habe hier alle meine Datenmacherexperten, die hier bei den Repositories arbeiten.

Und hier meine Frontendler, die mir schöne Views bauen. Hat sich ja auch irgendwo eine Existenzberechtigung gehabt, das so zu schneiden. Inzwischen geht der Trend eher dahin, dass man es doch wieder fachlich schneidet, also eher vertikal statt horizontal. Das heißt, hier bei REWE zum Beispiel gibt es hier Orders und Products.

Und ich habe dann in dem Orders Kontext quasi View, Controller, Model und Repository drin. Genau, Self-Content System, wo kommt der Begriff her? Das ist so eine Art von wie man Microservices interpretieren kann. Microservices sind ja in aller Munde, nur meint irgendwie jeder was anderes damit.

Es ist halt ein sehr schwammiger Begriff und man kann das sehr, sehr schwer fassen. Und wenn man darüber spricht, kommt es halt auch zu Missverständnissen und so weiter. Und es gibt so eine deutsche Beraterfirma, die heißt InnoQ. Da sind einige renommierte Leute drin, wie zum Beispiel Stefan Tilfkopf und so weiter.

Und die haben halt die Idee von diesen Self-Content Systems aus ihrer Beratungstätigkeit refined und gesagt, wir definieren uns einfach mal eine bestimmte Interpretation von Microservices für dieses Szenario, was wir bei unseren Kunden am häufigsten sehen.

Wie sieht das aus? Istralierung, wie eben schon angesprochen. Ich sage quasi ein Self-Content System wie hier, das darf nur von einem Team betreut werden. Das heißt ich habe nicht zwei Teams, die in ein System irgendwie um mangeln und sich gegenseitig blockieren, sondern es gibt immer nur ein Team, was in einem SCS Änderungen machen darf.

Gut, anders herum kann ich natürlich sagen, ein Team kann natürlich beliebig viele SCS betreuen. Das will ich nicht ausschließen, aber die wichtige Regel ist halt, dass jeder SCS von genau einem Team betreut wird. Genau. Des Weiteren kann man sehr schön abbilden, dass man sagt, ein SCS, was ja quasi ein technologischer Schnitt quasi ist,

entspricht eins zu eins einem Baumundet-Kontext, also quasi der Übersetzung von der Subdomäne in ein SCS. Das heißt ich kann das sehr schön eins zu eins vom Konzept her zusammenfassen. Und das ist auch so ein bisschen die Idee, dass ich quasi mit dem SCS ein Konzept in der Technologie habe,

mit dem ich eins zu eins Baumundet-Kontext implementieren kann. Genau, und das Wichtigste natürlich, ich verteile meine Fachlogik nicht über alle Kontext hinweg, sondern jeder SCS hat quasi einen Kontext und auch sein Stück der Subdomäne dementsprechend.

Vielleicht nochmal um es etwas schärfer zu Microservices abzugrenzen. Man hat natürlich oder die Größe von einem Microservice, das sagt ja schon der Name, Mikro ist natürlich deutlich kleiner als die Größe von einem Self-Content-System. Da kann jetzt schon noch mehr drinstecken. Und ich habe auch von der Anzahl natürlich mehr Microservices als Self-Content-Systems.

Aber ein Self-Content-System kann auch eine Mehrzahl an Microservices beinhalten. Wichtig sollte sein, dass die halt nicht synchron miteinander kommunizieren. Ganz einfach aus dem Grund, wenn jetzt der den fragt, der fragt den, der fragt den und den und den.

Und dann geht jeder mal was kaputt. Und dann ist halt die ganze Kette im Eimer und ich kriege es vielleicht noch nicht mal mit. Und es dauert halt super lange. Genau und auch noch wichtig, dass ich sage, wenn ich verschiedene Kontexte, verschiedene Self-Content-Systems integrieren möchte, dann mache ich das auf der UI-Ebene.

Das heißt, jeder meiner Self-Content-Systems hat quasi eine UI vorne und die kann ich dann eben zusammen integrieren, wenn ich das möchte. Das heißt, es geht dann nicht, dass die auf der Serverseite unten miteinander sprechen und da irgendwie der Austausch stattfindet, sondern jeder macht halt seinen View fertig und die werden dann einfach zusammengestöpselt. Genau, das kann man auch mal nachlesen.

Auf der Seite, die halt von InnoQ gemacht ist und da ist der Unterschied eigentlich ganz schön dargestellt. Genau, also wir nutzen das bei Rewe sehr intensiv und das bewährt sich eigentlich auch, wenn man mal so ein bisschen auch hört, was die von InnoQ dort zu sagen, die bewerben das als so eine Art Meeting-Vermeidungsstrategie. Das heißt, man hat dadurch eine sehr schöne Skalierung eben, dass man sagt,

die Software-Leute, die haben halt quasi diesen Kontext, die reden nur mit diesen Fahr-Experten und die haben halt quasi nur diese Software-Komponente, die sie betreuen müssen. Und wenn ich eine Änderung machen will, ist das halt immer ein sehr begrenzter Personenkreis und ich muss halt nicht die halbe Firma involvieren, wenn ich mal was ändern möchte.

Wir können gerne noch mal Fragen einlegen zu dem ersten Bereich, wenn das gewünscht ist. Ja, sehr gern. Diese hier? Ja.

Ja. Ja.

Also wenn ich es richtig verstanden habe, die Idee finde ich eigentlich sehr schön, von dem kathetischen Produkt zu sprechen, weil ich ja quasi technologisch diese Konzepte habe und fachlich diese Produkte. Ja, die Frage ist quasi, dass die fachliche Sicht ist natürlich diese hier,

die technologische Sicht ist eher diese hier. Man spannt damit ja quasi ein kathetisches Produkt auf und die Frage ist, wie man das in DDD abbilden kann, wenn ich es richtig verstanden habe, oder wie? Ja. Ja.

Ach so, okay, also es gibt Probleme, die halt nicht nur fachlich sind, sondern technische Probleme. Ich denke, der Übergang ist natürlich da, dass ich halt auch irgendwann Technologie als meine Domäne irgendwo habe,

wenn ich so tief da reingehe. Und wie gesagt, man hat ja jetzt auch nicht so die Silver Bullet Lösung, wo man sagt, das ist es jetzt, also man muss halt schon, finde ich, abwägen. Und wie gesagt, DDD ist ja jetzt auch kein Rezept, den man jetzt folgt.

Das ist eine Empfehlung und Perfektion ist da nichts, was man irgendwie anstreben kann und Ausnahmen wird man da immer haben. Ich befürchte, das ist jetzt für dich keine befriedigende Antwort. Ansonsten würde ich sagen, lass uns doch vielleicht danach nochmal drüber sprechen, sonst komme ich, glaube ich, mit meiner Zeit irgendwie in Bedrängnis.

Aber finde ich spannend. Genau, denn wir wollen noch über die Domain-Events sprechen, was fast noch das spannendere Konzept ist. Hast du jetzt verrutscht? Meine Fohlen sind verrutscht, egal. Genau, was ist ein Domain-Event? Ein Domain-Event ist ein Fakt,

also ein unveränderbarer Fakt aus der Vergangenheit, der halt für Domain-Experten von Interesse ist. Das heißt, es ist irgendetwas passiert in meiner Domäne, zum Beispiel eine Bestellung ist eingegangen oder ein Kunde hat seine Lieferadresse geändert oder irgendwas. Das sind halt Sachen, die mich als Domain-Experten vielleicht interessieren würden.

Und es ist interessant mal zu betrachten, wenn ich modelliere aus so einer Event-Sicht heraus, was dann passiert. Denn manche Domänen eignen sich vielleicht besser dafür, eher aus Event-Sicht modelliert zu werden. Ich habe mal wieder dieses Schachbeispiel, weil es halt hier sehr schön passt.

Wir hatten ja vorher schon das Konzept hier der Stellung gehabt. Wie kann ich eine Stellung modellieren im Schach? Ich kann zum Beispiel sagen, ich speicher mir einfach die aktuelle Stellung immer ab. Das heißt, ich mache einen Zug, das Brett sieht so aus und ich speicher den aktuellen Zustand des Bretts einfach ab. Und da gibt es zum Beispiel hier so eine Notation, die nennt sich fourth, da heißt AdWords-Notation.

Es ist dann hier so ein langer String, das hat hier zum Beispiel drei leere Felder, dann steht da ein Bishop, dann habe ich zwei leere Felder, dann steht da ein Rook und ein King, also die oberste Zeile. Und so kann ich quasi alle acht Zeilen hier durchgehen und habe dann quasi den aktuellen Zustand meines Bretts damit modelliert.

Was jetzt halt schwierig ist, wenn ich sagen will, ich würde jetzt gerne einen Zug rückgängig machen. Ich sehe hier raus nicht mehr, was jetzt der letzte Zug war. Ich kann nicht erkennen, was jetzt der letzte Zug war. Und bei so einer Domäne ist dann vielleicht ganz schön zu sagen, dann modelliere ich das mit Events.

Das heißt, ich kann ja meine Stellung aus der Historie aller Züge immer zusammensetzen. Das heißt, ich kann nochmal bei Null anfangen, spiele alle Züge ein und habe dann eben den Zustand meines Bretts da. Und als Bild nochmal vielleicht diese Portable Game Notation vor Augen führen,

die das ja im Prinzip genauso macht, die sagt, okay, zuerst hat er auf E4 gezogen, dann hat er auf C5 und so weiter und so weiter und so weiter. Und wenn ich die Züge alle nochmal nacheinander auf den Grundzustand ausspiele, komme ich ja auch zu meinem Zustand. Genau, man kann da sehr schön paaren mit CQRS.

CQRS ist so ein Pattern Command Query Responsibility Segregation. Das wird halt oft zur Skalierung eingesetzt. Das heißt, ich möchte da quasi trennen zwischen der Seite, die quasi Befehle in Empfang nimmt und Daten ändert, und der Seite, die Daten einfach nur ausliest und irgendwie darstellt.

Denn oft ist das halt irgendwie asymmetrisch. Das heißt, die eine Sache selten gemacht wird, die andere Seite sehr oft gemacht wird. Das macht halt schon Sinn, das zu trennen. Im Beispiel hier könnte man es zum Beispiel so sehen. Ich habe halt hier den Fall, hier gibt der Benutzer seine Schachzüge ein. Die werden in dem Model gespeichert.

Ich speichere den Zug hier in so einem Event Store ein und sammle hier quasi alle Züge und publiziere dann ein Event, oh hier hat jemand nach C4 gezogen. Ich kann dann das quasi hier wieder auf meinen Query Model anwenden, was dann vielleicht so aussieht, dass da der Zustand des Bretts drin steht und ich kann den Zustand des Bretts dann quasi hier wieder anzeigen lassen.

Das heißt, ich habe hier eine Trennung, ich habe hier quasi alle Domain Events immer drin gespeichert und kann die Daten dann hier so aufbauen, wie ich es halt für einen entsprechenden View haben möchte. Zum Beispiel könnte man jetzt sagen, ich habe jetzt hier einmal ein View für das Schachbrett und noch ein View für eine Schachuhr zum Beispiel. Und die Schachuhr interessiert sich ja nur, dass jetzt überhaupt ein Zug gemacht worden ist.

Die interessiert sich gar nicht, wohin der gezogen hat, sondern einfach, okay, dann ist wohl jetzt der andere dran und ich muss die andere Uhr runterzählen. Das heißt, so kann man es ganz schön trennen voneinander auf Basis von Events. Genau, und jetzt würde ich gerne noch eine Sache vorstellen, das nennt sich Event Storming. Hat das schon mal jemand gehört?

Oh cool, auch Hände, sehr schön. Das ist auch eine Sache, die relativ neu ist. Das sieht so aus, das ist ein kollaboratives Werkzeug, um gemeinsam mit Software-Experten und Fahr-Experten eine Domäne zu erforschen und zu modellieren.

Man muss sich das so vorstellen, man versammelt sich in einem möglichst großen Raum. Man hängt eine Tapetenrolle an die Wand, gibt jedem eine Menge Post-its und Stifte und gibt ein paar Regeln vor. Zuerst fordert man die Beteiligten auf, einfach mal zu überlegen,

was gibt es denn alles für Domain-Events in der Domäne, die wir vielleicht für unsere Problemlösungen betrachten. Und da stehen erst mal alle so da und wissen nicht so recht, was sie da tun sollen. Und dann fängt halt der Erste an und sagt, oh, ich denke, das ist ein Event. Und dann taut das so langsam auf und die Leute posten so die Events an die Wand,

die sie meinen, die da relevant sind. Und dann entstehen erste Gespräche und Fachleute und Software-Leute kommen ineinander in Gespräche. Und mit der Zeit entsteht da eben hier so ein Bild, was quasi eine Modellierung der Domäne eben ist. Das heißt, ich kann sagen, welche Kommandos lösen denn vielleicht das Event aus?

Und welche Regeln müssen denn eingehalten werden, damit mein Modell valide bleibt? Und wie muss es dann dargestellt werden und so weiter? Und da geht einem das Event-Storming ein sehr schönes Regelwerk an die Hand, mit dem man halt erforschen kann und modellieren kann.

Und wenn man jetzt hier sieht, das ist auch eins zu eins die Konzepte, die ich halt auch im CQRS habe. Ich habe zum Beispiel Commands, die reinkommen. Ich habe hier sowas wie ein Model. Ich habe eben hier das Event selbst. Und ich habe hier sowas wie den Query-Zweig. Das heißt, man könnte das relativ gut übersetzen von einer Modellierung eben in eine CQRS-Umsetzung.

Genau, das zum Event-Storming. Also ich finde es halt ganz schön, weil meiner Erfahrung nach ist man halt, also womit ich da oft konfrontiert bin, ist halt User-Stories oder User-Story-Mapping. Dass man sagt, man betrachtet das Ganze aus der User-Sicht.

Dann hat man immer so Stories oder so Sachen. In einem System dahinten passiert irgendwas, weil irgendwas anderes passiert ist. Da kriegt man jetzt keinen User rein bemangelt. Das kann man sich irgendwie zurecht machen. Aber wie gesagt, das Event-Storming hilft einem wirklich dann ganze Business-Prozesse zu modellieren.

Und das ist dann auch nicht pünftig aus einer User-Perspektive, sondern ganzheitlich. Genau, das zum Event-Storming. Bam, viele grüne Haken. Und hier nochmal die Übersicht. Das heißt, genau, das Konzept, das die Domain-Events schafft, ist eben,

ich verzahne halt alle drei Bereiche miteinander. Ich habe halt oben ein agiles Konzept Event-Storming, mit dem ich quasi Models erzeuge, die auf Domain-Events basieren.

Domain-Events spiegeln damit quasi Business-Prozesse wieder. Und ich kann die eben sehr schön einsetzen, um mit CQRS und Event-Sourcing halt so message-getriebene Systeme zu bauen. Das heißt, wieder ein Konzept DDD, was quasi den ganzen Laden irgendwie zusammenhalten kann. Genau, das waren jetzt so die beiden Neuerungen, Gründe für die DDD-Renaissance vielleicht.

Ja, und abschließend halt so die Hoffnung, dass DDD wirklich so eine verlorene, agile Disziplin ist, die es lohnt, mal wieder hervorzukrammen, mal zu schauen, was hat sich da getan die letzten Jahre,

und zu schauen, wie kann ich das eben nutzen, um den ganzen anderen Werkzeugkoffer an agilen Werkzeugen, den man so mit sich rumträgt, anzureichern, um eben die Zusammenarbeit zwischen Software-Experten und Fach-Experten besser zu machen. Ja, das wäre es von meiner Seite. Wer Interesse hat an Domain-Driven-Design? Ich habe es eben schon gesagt, es gibt hier jetzt ein Domain-Driven-Design Meetup

mit einem schönen Kölner Dom hier in der Mitte. Das findet im Moment einmal monatlich statt. Jetzt im August haben wir auch einen Workshop zum Event Storming, im September zu Domain-Storytelling und im Oktober zu einer Möglichkeit,

in JavaScript Domain-Driven zu arbeiten. Würde mich freuen, wenn der eine oder andere mal da schauen würde. Das gibt es bei Meetup.com. Einfach mal nach Domain-Driven-Design Köln suchen. Ansonsten, auch weil der Rewe digital, Werbung, sind wir sehr daran interessiert, Domain-Driven zu arbeiten. Das heißt, wer da Lust hat, sich da zu betätigen, kommt gerne auf mich zu,

kann die Jobs hier anschauen. Wir würden uns freuen. Danke euch. So, wir haben jetzt noch sieben Minuten bis elf. Also wenn jetzt noch Fragen sind, gerne, ja, ich würde schön.

Also die Frage war, welcher Zusammenhang besteht zwischen Domain-Specific-Language, DSL und Domain-Driven-Design? Es besteht natürlich einen Zusammenhang.

Da sagt ja schon der Name Domain. Das heißt, Domain-Specific-Languages sind eher schon eine sehr konkrete Ausprägung. Das heißt, das kann ich machen, wenn ich mein Modell oder mein Domain schon sehr gut verstehe, glaube ich. Das heißt, weil ja eine domain-spezifische Sprache

schon auch mit Aufwand verbunden ist, die zu implementieren und so weiter. Und ich würde sagen, das ist halt eine sehr konsequente Fortsetzung für Domänen, die schon sehr gut verstanden sind und ausgereift sind, wo man halt nicht mehr viel erforschen muss, sondern das schon mit gutem Gewissheit in sowas gießen kann,

was ich dann eben auch in Software benutzen kann. Also ich finde schon, dass das einen sehr starken Zusammenhang hat, ist vielleicht in den letzten Jahren, aber es ist vielleicht auch ja so nicht ein Thema, gerade weil es vielleicht nicht so häufig ist, dass man wirklich so komplexe Domänen hat, wo sich der Aufwand lohnt, das wirklich zu tun.

Wenn ich eine domain-spezifische Sprache für einen bestimmten Bereich nutze,

dann bin ich automatisch benutzter Domain-driven Design. Wie gesagt, es heißt ja auch Domain-driven Design. Also es ist ja eigentlich nur Design-Disziplin. Es geht da eigentlich nicht darum, Software zu schreiben. Also der Kern des Domain-driven Designs, so wie ich es verstehe, ist halt schon, dass du die beiden Seiten zusammenbringst, die sollen modellieren.

Und natürlich ist es ein Bonus, finde ich, wenn danach so eine Sprache rausfällt, mit der ich halt in die Software schreiben kann. Ich finde das ist aber ein Bonus. Und vielleicht verliert man was, wenn man sagt, ich habe ja schon die Sprache und mache das dann einfach, und die Fachexperten sind außen vor. Ich selbst habe sehr wenig Kontakt gehabt mit domain-specific Languages, deshalb kann ich das nicht aus erster Hand sagen,

aber das wäre jetzt meine Intuition, dass das vielleicht passieren könnte. Hat noch jemand eine Frage? Ja, gerne.

Genau.

Also bei uns ist das so, wir machen das halt auch eventbasiert über so eine Message-Queue. Das heißt, es sind wirklich getrennte Datenbanken, die wir da haben. Und sobald du halt eine Änderung machst in dem Kundendatenservice, wird halt quasi ein Domain-Event gefeuert, also auf diese Queue gelegt. Hier, die Kundenstammdaten haben sich geändert, mit der Änderung eben.

Und da kann eben der Delivery Service drauf hören auf diese Queue und sagen, okay, hier hat sich was geändert. Das ist in der Sprache. Ich übersetze das jetzt in meinen Kontext und speichere mir das dann einfach bei mir lokal in meine Datenbank ab. Also es ist eine asynchrone Kommunikation quasi. Das sollte man schon beachten.

Das ist jetzt nichts, was synchron passiert und man das direkt verwenden kann, sondern es wird dann einfach so übersetzt in die anderen Kontexte. Also Kafka benutzen wir als Message-Tool.

Wie gesagt, der Kommentar war, dass man vielleicht DDD nicht am Anfang machen sollte,

sondern erst mal ganz normal agil anfangen sollte, um erst mal zu schauen, ob die Domäne komplex genug ist, dass sich der Aufwand mit Domain-Driven-Design lohnt. Kann ich erst mal nichts gegen sagen. Es ist halt auch immer die Frage, was ist komplex?

Also die Frage der Komplexität explodiert auch mal schnell und oft sind halt auch Sachen dabei, die auf den ersten Blick einfach sind. Wir hatten jetzt ziemlich viel bei Rewe mit Payback gearbeitet. Und da hast du immer gesagt, es gibt eine Payback-Kunden-Nummer, eine Kontonummer, eine Kartennummer. Man sagt immer noch die Payback-Nummer.

Und das ist so schnell, dass du da auseinanderläufst und da modellierst du immer eine Payback-Nummer. Das passt ja gar nicht zusammen. Und deshalb ist es halt oft sinnvoll schon, ich finde schon sprachlich, früh damit anzufangen. Und wie gesagt, Domain-Driven-Design ist ja auch nicht so preskriptiv, dass es dir genau sagt, du musst jetzt diese ganzen Schritte machen.

Ich finde, wenn du das schaffst, in Scrum zum Beispiel die Stakeholder zusammenzubringen und die über die Sachen gut reden können, dann hast du ja auch den Gewinn quasi schon. Und das Domain-Driven-Design ist dann quasi noch die Stützräder nebendran, dass das dann auch richtig läuft.

So, ich bekomme gerade das unmissverständliche Endezeichen von dahinten.

Insofern danke ich euch alle nochmal, dass ihr hier wart und schönen Tag noch.