Deep Dive 164 –

Domain-Driven Design mit Stefan Priebsch

18.10.2024

// Podcast
// Deep Dive 164

Shownotes

In dieser Folge widmen wir uns sehr tiefgehend dem Thema Domain-Driven Design. Falls dir das Thema noch neu ist, hör doch vorher in Folge 57 rein, „DDD, Event Sourcing und CQRS mit Golo Roden“.

Domain-Driven Design, kurz DDD, ist kein neues Phänomen mehr. In der Literatur existiert es bereits seit über 20 Jahren, aber gerade in der praktischen Anwendung hakt es noch häufig. Oftmals werden verschiedene Definitionen und Vorstellungen vermischt und Methodik mit Implementierung verwechselt.

Um mit all diesen Vorurteilen und Missverständnissen aufzuräumen, haben wir uns Stefan Priebsch ins Studio eingeladen. Gemeinsam diskutieren wir nicht nur die Geschichte von DDD, sondern auch den aktuellen Stand und lauschen seinen Erfahrungen aus 20 Jahren Praxis zu diesem Thema.

Download

/transkript/programmierbar/deep-dive-164-domain-driven-design-mit-stefan-priebsch

Jan: Hallo, liebe Zuhörerinnen. Bevor wir mit der heutigen Folge starten, gibt's einen kleinen Hinweis. Wir beschäftigen uns in dieser Folge sehr tiefgehend mit dem Thema Domain Driven Design. Das Thema haben wir bereits vor einigen Jahren im Podcast behandelt. Das war Folge siebenundfünfzig, damals zusammen mit Goloroden vor vier Jahren. In der Zwischenzeit hat sich die Welt natürlich weitergedreht und wir wollen mit unserem heutigen Gast über die Höhen und Tiefen von DDD sprechen. Daher ist das heute auch kein einführender Podcast in das Thema und wir empfehlen euch, falls das Thema für euch neu ist, vielleicht vorher noch einmal die Folge siebenundfünfzig mit Golo zu hören. Und jetzt viel Spaß mit der Folge. Hallo und herzlich willkommen zu einem neuen Deep Dive der programmier.bar. Hier ist für euch der Jan und neben mir in der linken Ecke des Tonstudios ist der Fabia Low. Hello, hello. Wir sind heute hier im Studio, einmal über ein Thema zu sprechen, das schon mal in der programmier.bar war. Wir wollen nämlich heute über Domain Driven Design sprechen und da hab ich mir so überlegt, wie nennen wir so eine Folge Fabi? Weil wir hatten das ja schon mal. Wir hatten schon mal in der Folge siebenundfünfzig vor über vier Jahren über das Thema Domain Driven Design gesprochen. Habe ich überlegt, macht man da Domain Driven Design zwei Punkt null, dann fliegt man da draußen von irgendwelchen Puristen wahrscheinlich auf die Nase, weil die sagen, da hat sich irgendwie an dem Konzept aber nichts geändert oder muss man das Domain driven Design the Goodparts so analog zu diesen guten Javacript Büchern oder muss man Domain driven Design revisited und gibt's aber Ärger von den Leuten, die sich immer aufregen, wenn bei der Programmierer irgendwas auf Englisch ist und nicht auf Deutsch. Deswegen Spannung, wir warten mal ab, was am Ende aufm Cover steht von dieser Folge.
Fabi: Oder wir waren uns einfach nur Domain driven Designer. Die letzte Folge hieß ja DDD Eventsourcing und SecureS, von daher
Jan: Ah, nur aus welchem Die Puristen wieder.
Fabi: Ja. Aber wir werden sehen. Mal gucken, worüber wo die Unterhaltung hinführt.
Jan: Ja. Und damit wir auch Expertise hier haben und nicht nur Fabio und ich über Domain of Design rätseln, haben wir uns den Stefan ins Studio eingeladen, den Stefan Briebsch. Hallo Stefan.
Stefan Priebsch: Hallo.
Jan: Stefan, Du bist Consultant bei The PHP Consulting Company. Das ist, glaube ich, auch so, wie wir uns vor Ewigkeiten mal kennengelernt haben. Ich glaube, ich stand mittlerweile mit jedem von euch, habe ich mir schon mal eine Bühne auf irgendeiner PHP Konferenz geteilt oder wir waren zumindest schon mal auf denselben Veranstaltungen und jetzt machen wir auch einen Podcast zusammen.
Stefan Priebsch: Das ist doch super.
Jan: Finde ich sehr cool.
Stefan Priebsch: Ich auch.
Jan: Ich fand das fand das so interessant, als ich mir hier die Recherche für die Folge gemacht hab, bin ich wieder über die Firma PHP CC gestolpert. Dabei habe ich das erste Mal in meinem Leben hinterfragt, wo diese Punkt c c Domain eigentlich herkommt. Deswegen jetzt, Stefan, bevor Du's verrät, Preisfrage an den Fabi. PHP Punkt c c, was ist c c?
Fabi: Creative Company, keine Ahnung, ich weiß nicht, wofür c c steht.
Jan: Na ja, es ist tatsächlich eine Länder TLD. Zweiter Versuch?
Fabi: Caman Iance hat nur eins, ich weiß es nicht.
Jan: Okay, Cayman Iainens ist es nicht. Stefan, wo kommt Cay her?
Stefan Priebsch: Jetzt stellst Du mich natürlich bloß Oh, Mist. Ein Ich fahr
Jan: meine Absicht.
Stefan Priebsch: Ich weiß, dass es eine Länderdomain ist und ich glaube, das ist irgendwas mit mit irgend eine Insel, mit Kokospalmen wachsen.
???: Genau.
Stefan Priebsch: Und was ich euch sagen kann, ist, also diese Domain ist halt, weil wir Punkt CC als Abkürzung für Consulting Company irgendwie cool fanden.
???: Weil ich hab
Stefan Priebsch: Creative Company. Wenn wir Jahre später, wenn wir gewusst haben hätten, was wir Jahre später mitunter für Probleme haben mit E-Mail-Zustellung mit dieser Domain, dann hätten wir uns vielleicht anders entschieden.
Fabi: Weil Leute einfach falsche Domain wählen oder angeben?
Stefan Priebsch: Leider und und Du hast leider son gewissen Grundverdacht irgendwie bei manchen Providern, ich will jetzt keine Namen nennen, dass Du irgendwie Spamy Mails verschickst, weil CC ist ja Da sitzt ja Also so ne, sone Firma wie wir würde ja Na ja Also das ist jetzt 'n bisschen suboptimal, ansonsten ist es halt 'n ganz cooler kurze Abkürzung für the Php Punkt Consulting Company. Und so haben wir das dann einfach reserviert, weil man ja heutzutage irgendwie in diesen Domain Kaufschleudern kannst Du hier alles Mögliche und nichts klicken. Und dann Damals gab's die ganz besonders gieckigen Domains wie Io und so noch nicht, ne.
Jan: Also CC sind die Kokosinsel. Wollte ich auch
Fabi: sagen, Kokosinsel. Nachdem Du zwei Leute bloßgestellt hast. Die Kokosinsel.
???: Die Kokosinsel. Die Kokosinsel.
Jan: Er hat das schon recht. Eine Insel, wo viel Kokosbäumen wachsen, so in der Nähe von Australien ist das, glaube ich, wenn ich nicht irre. Und so wie ich das gelesen hab, ist tatsächlich Punkt c c bei vielen Suchmaschinen oder E-Mail-Provider so auf der auf der Prohibit List gelandet, weil es durch seine Ähnlichkeit zu Punkt c o halt so zum Phishing einlädt, ja? Du kannst halt, wenn irgendjemand eine Co dot UK oder sowas macht, dann machst Du Punkt c c Punkt UK oder so und versuchst dir dann damit auszutricksen. Aber
Stefan Priebsch: Irgendwas ist immer, ne? Cool.
Jan: Und immerhin ist das 'n cooler Gesprächsopener, ja? Übrigens Punkt c c auch besonders beliebt bei allen Vereinen der katholischen und christlichen Kirchen, weil CC Astrologieic Church. Ja.
Stefan Priebsch: Okay. Also ich merk schon, ich bin hier im richtigen Podcast, weil ich lerne gerade ganz viel.
???: Ich wollt
Fabi: grad sagen, jetzt haben wir eigentlich auch schon genug gelernt oder? Das war's.
Jan: Das war's. War schön, dass ihr alle da wart heute. Nein. Wir wollten ja eigentlich über Domain Drive Design sprechen und Stefan, vielleicht willst Du einmal ganz kurz erzählen, wann bist Du denn so in den Domain Driven Design Zauberdrangkessel gefallen und wie bist Du dazu gekommen?
Stefan Priebsch: Ja, ich kann's dir jetzt gerade nicht mehr ganz genau sagen, wann es war. Es wird wohl so zweitausendfünf gewesen sein. Da war ich auf einer dieser legendären IPCs in Möhrfelden. Also für die, die das nicht kennen, Möhrfelden ist so in der Nähe vom Frankfurter Flughafen. Manche Leute nennen es Frankfurt. Es ist irgendwo in der Nähe von Frankfurt und Myrfelden sind so ganz legendäre coole PP Konferenzen gewesen, weil da war ein Hotel im Nichts und da hatte man keine andere Chance als so gefühlt drei Tage lang, die Bar zentriert diese diese Konferenz zu machen. Und das war total toll, weil sehr intensiv und da waren halt da wirklich ganz viele prominente Leute aus der PHP Community auch immer und das war zusammen damals mit MySQL Konferenz, also waren da auch immer Leute da und es war immer cool. Und ich war da auf einer Konferenz und da hatte mein Ich hab damals 'n Buch geschrieben für Hansa gerade, Hansa Verlag und der Hansa Verlag hatte da einen Stand beziehungsweise war mein Lektor von Hansa war da und Robert Lemke vom NEOS Projekt, damals TYPO3 war da. Und die haben damals grade begonnen, TYPO3 neu zu bauen. Das, was dann TYPO3 NEOS war und was dann NEOS als eigenes Projekt wurde. Und der Robert Lemke hat meinem Lektor total fanatisch von einem supergeilen Buch erzählt, das er grade gelesen hat, und zwar dieses Domain Driven Design von Eric Evans. Und das hat ungefähr so zwanzig Minuten Monolog gedauert von Robert, wo ich zugehört hab und mir dann gedacht hab, okay, das Buch musst Du lesen. So. Na so für
Jan: die zeitliche Einordnung, weil das Buch ist ja auch schon nicht mehr ganz so druckfrisch. Wann wann war das so ungefähr?
Stefan Priebsch: Das Buch ist von zweitausenddrei, wenn ich mich recht erinnere und diese Konversation wird wohl so zweitausendfünf stattgefunden haben. Plus minus ein Jahr kann jetzt sein, dass ich mich da vertue. Da ist meine Erinnerung, bei Jahreszahlen ist da son bisschen blurry. Und Robert hat das einfach so toll gepitcht, dass ich mir gedacht hab, ja, musst Du mal reingucken. Dann bin ich von dieser Konferenz zurückgekommen und hab mir das bestellt und hab es gelesen und glaubte, es verstanden zu haben. Und wenn man über das blaue Buch von Eric Evans eins sagen kann, dann, dass es nicht leicht zu lesen ist. Wenn man's dann fünf oder zehn Jahre später noch mal liest und da gebe ich jetzt zu, nicht mehr komplett von von vorne nach hinten, aber so in Auszügen liest man mal das eine oder andere Kapitel noch mal, dann stellt man immer fest, dass da jetzt plötzlich Sätze stehen, die beim ersten Lesen da nicht gestanden haben. Also es geht mir literally so, dass ich dann Sachen lese und sag, der stand doch das letzte Mal nicht da. Das hast Du beim letzten Mal nicht wahrgenommen, dass diese Aussage da steht. Dann sind aber so andere Aussagen, die wir beim ersten Mal total augenöffnend fand, sind dann beim nächsten Mal plötzlich so, ach so, ja klar, ja, ist 'n alter Hut. Also das finde ich total spannend und deswegen kann ich nur alle auch da draußen einladen. Ich glaube, Eric Evans gehört zu dem zu den Büchern, die man so als ernsthafter Informatiker durchaus mal gelesen haben sollte oder vielleicht sogar daheim im Bücherregal stehen haben sollte. Ist schon 'n bisschen alt jetzt zweitausenddrei. Aber wenn man es mit der heutigen Brille sozusagen liest, stellt man fest, dass Eric für damalige Verhältnisse halt einfach wahnsinnig weit vorausgedacht hat. Also er hat wahnsinnig viele Dinge in 'nem ganz anderen Licht betrachtet und eigentlich in einem sehr Enterprisey, sehr, sehr konservativen Entwicklungsmodell, wie man aus heutiger Sicht sagen muss, ja, da gab's nicht wirklich agile Projekte. Also da gab's zwar son agiles Movement, son beginndes, aber nicht groß, dass da irgendwie so jemand gesagt hätte, hey, wir machen agil, ja. Und in in dieser Zeit hat er da sehr, sehr viele Elemente, die wir ja auch in der Agilität wiederfinden und in anderen Ansätzen wiederfinden, schon einfach beschrieben und ja auch in einen Kontext gestellt, in sozusagen ein Gesamtpaket gestellt, wo er sagt, so, das ist hier irgendwie mal son Mindset, mit dem kann und sollte man Software entwickeln.
Jan: Mhm.
Stefan Priebsch: Genau. Und das hat mich damals son bisschen infiziert und ich hab dann immer Also ich würde so sagen, ich hab immer schon Ideen aus diesem Domain Driven Design für mich entnommen und adaptiert und habe immer mehr festgestellt, dass ich für mich selber eigentlich gar nicht anders arbeiten kann und denken kann als in diesem Mindset, hab das aber nie unbedingt so groß auf meine Fahne geschrieben, dass ich jetzt hier Domain Driven Design Consultant bin oder irgendwie so was. Es kam dann sone Zeit und das Ich bin ja Wir dürfen hier ja ganz offen sein. Wir sind unter uns, ne? Es kam dann sone Zeit, wo Domain Driving Design son bisschen gehypt ist, in dem Sinne, dass alle möglichen Schulungsanfragen kamen, wir wollen Domain Driving Design lernen. Und was die Leute eigentlich lernen wollten, wenn auf der Fahne stand, wir wollen Domain Driving Design lernen, war erst mal so, wie mache ich 'n OP richtig und solche Basics und was sind 'n Design Patterns und wie kann ich denn dieses Potenzial sozusagen ausschöpfen? Weil viele Leute halt im DDD Buch auch sich son bisschen die Patterns anschauen und sagen, ah, super, acroggate Repository value, ja, Open Host Service und so, super. Die Patterns, die finde ich ja heute in der Entwicklung quasi überall wieder. Und viele Leute glauben, dass das Domain Driven Design ist. Und das ist halt nur eigentlich ein Bruchteil dessen, was Domain Driven Design als Philosophie ausmacht.
Jan: Das ist vielleicht 'n guter Einstiegspunkt, weil jetzt haben wir schon zehn Minuten drüber gesprochen. Aber es hat ja vielleicht auch nicht jeder die erste Folge dazu gehört und vielleicht magst Du noch mal in ein bis drei Sätzen sagen, für alle, die da draußen noch kein festes Verständnis davon haben, was ist denn eigentlich Domain driven Design und was ist es nicht?
Stefan Priebsch: Also für mich ist Domain driven Design ein Mindset und da geht es drum, dass die Fachlichkeit im Zentrum steht bei der Entwicklung. Also nicht die nicht die Technologie, nicht die Technik. Und etwas, was wir auch im agilen Manifest beispielsweise ja finden, ist im Prinzip dort heißt es, die tägliche Zusammenarbeit zwischen Entwicklung und Fachexperten, ja, Fachlichkeit in den Mittelpunkt nur stellst, wenn Du Fachexperten da hast. Und das ist halt eben nicht nur der Entwickler. Es gibt tatsächlich, habe ich über die Jahre lernen müssen, echt Fälle, wo Entwickler auch sehr gute Fachexperten sind oder die besten Fachexperten, die 'n Unternehmen hat in 'nem bestimmten Bereich. Eigentlich idealtypisch und so wie es jetzt Eric Evans zweitausenddrei gesehen und beschrieben hat, ist der Fachexperte halt jemand, der irgendwo an irgendwas arbeitet und da eine Automation haben möchte und jetzt irgendwie mit 'nem Softwareentwickler sich mal zusammensetzt und sagt, wie kann man das machen? So. Und dann ist der erste Schritt, dass man als Softwareentwickler halt hinterfragt, was wollen wir da tun? Warum wollen wir das tun? Wie wollen wir das tun? Und dann gemeinsam man die Fachlichkeit versteht in 'ner Kollaboration. Das ist ja auch gerade wieder son ganz aktuelles Thema, Collaboration, Collaborative Modeling und so. Das ist, glaube ich, auch eine der Grundfesten von Domain Driven Design. Und vielleicht noch 'n bisschen als als eine hoffentlich konstruktive, aber sachliche Kritik. Für mich ist es nicht Domain driven Design, wenn jemand sagt, wie mache ich denn Domain driven Design in Larawell? Oder wie mache ich denn Domain driven Design in PHP? Oder wie mache ich denn Domain driven Design in XYZ? Weil das eigentlich zu kurz greift. Das sind, ne, die die die Patterns, die kommen dann schon vor und die kann ich in jeder Programmiersprache oder in jedem Framework auch irgendwie umsetzen. Aber eigentlich ist beim Domain driven Design viel wichtiger ist das sogenannte strategische Design und das Thema bounded Context. Also wie kann ich sozusagen meine Domäne in Teilprobleme zerschneiden, in Subdomaines zerlegen oder meine bounded Context schneiden, dann zu 'ner, eigentlich würde man so sagen, zu 'ner guten Architektur zu kommen. Und das ist 'n spannender Aspekt an Domain Driven Design, dass es eigentlich sehr viel über Architektur geredet wird, ohne dass es Architektur genannt wird. Und für mich ist 'n sehr enger Zusammenhang zwischen Domain driven Design, Bounded context, wie schneide ich meine Kontexte, wie zerlege ich mein Problem in Teilprobleme, wie komme ich von diesen Teilproblemen zu Systemen? Und Softwararchitektur, wo wir ja exakt genau das Gleiche auch tun. Mhm.
Jan: Jetzt hast Du ja schon angesprochen, Domain Driving Design ist nicht die Frage, wie wie mach ich das in in PHP oder wie mach ich das in Go oder in in Node oder sonst irgendwo. Aber wahrscheinlich rennen doch die allermeisten in diese Falle und denken, wenn sie irgendwie an Domain Driven Design, denken auch gleich immer an sowas wie Eventsource und SecureS und wie kriege ich irgendwie meine Händler und meine Events und meine Commands hier irgendwie implementiert? Ich hab das noch nie gemacht. Ich kenn nur clashes 0RM oder so was. Wie kann man das denn trennen und verhindern, überhaupt in diese Falle zu laufen?
Stefan Priebsch: Also ich glaube, dass es ein Erfahrungsthema ist. Und ich glaube, dass es für den für die meisten Entwickler tatsächlich gar nicht mal falsch ist zu sagen, ich fange mit mit meinem Environment oder meiner Programmiersprache oder meinem Framework irgendwie an und bin da irgendwo, wo ich zu Hause bin und von dort aus sozusagen erweitere ich meinen Horizont in Richtung diesem Thema und fang dann mal an, mich da ranzutasten. Das ist 'n supererster Schritt. Danach muss halt dann der zweite Schritt kommen, dass ich sage, okay, und jenseits vom Code, was bietet mir Domain Driven Design eigentlich noch, ja? Nämlich die Frage so, ja, was willst Du denn eigentlich coden und und wie sehen denn deine Aggregate aus und was sind denn deine Module in der Software, wenn mal so ganz oberflächlich gesagt. Und da gibt es eben sehr, sehr viel Wissen, was Eric Evans damals angefangen hat aufzuschreiben, was in den letzten zwanzig Jahren, muss man sagen, auch wahnsinnig weiter gedacht wurde von von anderen Experten, die die da ja auch heutzutage teilweise schon einiges an Büchern publiziert haben, die sich auf Konferenzen tummeln und auf diesen üblichen Kanälen ihr Wissen kundtun. Da gibt es auch sehr viel, sage ich mal, aktualisiertes Wissen und aktualisierte Expertise, die das Domain Driven Design von zweitausenddrei auch in den Kontext stellt von zweitausendvierundzwanzig, in den Kontext von agilen Methoden, in den Kontext von Team Topologies, gerade son ganz heißes Thema zum Beispiel. Und das ist superspannend, weil Domain driven Design halt nicht son so baust, so baust, so Softwareansatz ist, sondern eigentlich eine sehr offen Mindset ist. Und das kannst Du wunderbar kombinieren mit anderen Dingen. Also ich hab jetzt vorhin die Brücke, die ich sehe zur Architektur zum Beispiel dargestellt, ne. Zu agilen Methoden haben wir auch schon kurz angerissen, gibt's auch sehr, sehr viele Überschneidungen, die sich im agilen Manifest finden, die sich auch in der Philosophie von Domain Driven Design finden. Und ich finde das immer superspannend, wenn man in zwei unterschiedlichen Ansätzen Gleiches findet, weil für mich ist das son Indikator dafür, kann ja so falsch gar nicht sein, wenn da ganz unterschiedliche Leute auf ganz unterschiedlichen Wegen drauf gekommen sind, dass das irgendwie so sinnvoll ist. Und wenn ich dann eben diese Gleichheit hab, liegt halt auch nahe zu sagen, wie kann ich diese Ansätze kombinieren? Ja, und da ist halt nicht, bau deine Software nach Strickmuster x y und das ist mit allem anderen irgendwie nicht kombinierbar, ne. So kann man sehr erfolgreich Software schreiben. Aber wenn man sich, wenn man über 'n Mindset nachdenkt und sagt, ich möchte als Entwickler irgendwie eine möglichst in dem wirtschaftlichen Kontext gute Lösungen finden, ja, oder ich möchte noch allgemeiner sagen, ich möchte es als IT Fachmann gute Lösungen finden. Weil wenn ich sag Entwickler, dann habe ich ja eigentlich schon, dann ist ja schon vorgegeben, dass man Software entwickelt, ne. Also fragen Entwickler, wie er ein Problem löst, dann sagt er dir, ja da entwickle ich Software dafür. Frag einen IT Fachmann, wie er ein Problem löst, dann hast Du vielleicht einen Lösungsraum, make orbye. Ja, wir könnten 'n Off the Shelf System verwenden oder irgendwie sone Library und dann vielleicht 'n bissel was dazu bauen oder wir bauen das selber. Und das ist schon wieder sone Domain Driven Designgeschichte, dass man eben ganz früh in der Entwicklung nicht schon gleich in die Technologie abbiegt, ja. Klassischer Indikator, wenn Du mit Teams zusammenarbeitest, Woche eins, Sprint eins, Tag eins, welches Framework nehmen wir? Ja, das ist Technologie. Ja, was wollt ihr denn bauen? Wenn ihr noch nicht wisst, was ihr bauen wollt, wenn ihr noch nicht wisst, was für euch wichtig ist, dann habt ihr eigentlich keine objektive Entscheidungsgrundlage, welches Framework wollen wir denn verwenden? Weil ihr wisst ja noch nicht, was ihr bauen sollt. Es gibt Sachen, die man mit bestimmten Frameworks super bauen kann. Dann gibt's Sachen, bei denen das dann eher schwierig wird. Wenn ich vorher nicht weiß, was ich eigentlich genau wie bauen will, tue ich mich sehr schwer, Technologie zu wählen. Wenn ich jetzt Technologie wähle, habe ich meistens irgendwelche Entscheidungen zementiert, die später schwer zu ändern sind, ja. Und die Idee von Domain driven Design ist, macht es halt nicht zuerst, ja. Dann kommt man vielleicht relativ schnell bei so was wie hexagonaler Architektur raus, bau halt erst mal deine Domäne, Domain first, ne, Domain driven, Domain first. Bau erst mal deine Domäne, bau da vielleicht mal son paar Objekte, die interagieren und die dann lustig irgendwelche Use Cases abbilden können. Und so Aspekte wie Persistenz und Darstellung kümmern wir uns im zweiten Schritt.
Jan: Aber da hätte ich mal eine ketzerische Frage zu.
???: Mhm.
Jan: Weil es wird ja ganz oft betont, dass diese Stärke von Domain Driven Design eben genau das ist, was Du grade gesagt hast, ne, in dieser explorativen Phase die Domain zu finden, die Schnitte die Schnitte zu finden, wo hört ein Kontext auf, wo fängt der nächste an, was gehört wohin, eine gemeinsame Sprache und 'n gemeinsames Vokabular aufzubauen und all das. Und das ist ja grade in den Use Cases supersinnvoll und hilfreich, wo ich einen bestehenden Prozess abbilden will, weil ich, weiß ich nicht, ich hab einen bürokratischen Prozess oder ich hab ein produzierendes Gewerbe und ich will jetzt eben das das digitalisieren, das abbilden, was auch immer und da kann mir DDD mit seinen Praktiken irgendwie super helfen.
Fabi: Mhm. So.
Jan: Im es gibt ja aber auch den entgegengesetzten Fall, also wie Du grade gesagt hast, ne, wo ich selber noch gar nicht vielleicht weiß, was ich bauen will, weil ich vielleicht ein, ich weiß nicht, vielleicht vielleicht baue ich ein Spiel und ich muss son bisschen explorativer rangehen und Mechaniken probieren und 'n bisschen mehr mehr Prototypenen oder ich baue eine eine App, von der ich selber noch nicht ganz so genau weiß, wo wo sie hin, also weißt Du, wenn wenn ich einfach kein reales Äquivalent habe, das ich nach will, sondern ich will etwas komplett Neues bauen, so, wo viele von uns ja dann irgendwie geneigt sind so, na, ich mach hier 'n Prototyp und ich geh irgendwie schnell an meine Marktgruppe dran und hol mir Feedback und mach hier iterativ und ganz schnell und ganz schnell und ganz schnell. Und wo kann denn oder kann da überhaupt DDD seine Stärke ausspielen, wenn ich noch gar nicht diesen Kontext habe und den selber erst noch finden muss? Mhm.
Stefan Priebsch: Also ich glaube, das, was Du da beschreibst, das ist das, was ich Domain Design nenne. Also nicht die vorhandene Domäne treibt das Design, sondern wir designen die Domäne und zwar kollaborativ mit Fachexperten und Entwicklern und vielleicht auch anderen Stakeholdern, den Lösungsraum noch aufzumachen, make orbye. Also wollen wir eine fertige Lösung verwenden oder wofür, für welche Elemente wollen wir fertige Lösungen verwenden? Für welche Elemente macht es Sinn oder ist es gar notwendig, was selber zu entwickeln? Immer da, wo Du wo Du neue Pfade betrittst, wo es halt nichts gibt, da gibt es die Domäne nicht. Und das ist, glaube ich, was Du meinst. Und das sehe ich auch ganz oft so und kann es verstehen. Deswegen nenne ich das an der Stelle Domain Design und da spielt dann kollaboratives Modeling ganz stark eine Rolle. Und das Superpower da, nach meiner Erfahrung ist, Domain driven Design sagt ja unter anderem auch, also wir haben eine gemeinsame Sprache, die sich durchzieht vom Fachanwender über den Entwickler bis in die Software. Da sind überall die gleichen Begriffe und wenn man es 'n bisschen mehr mit der Architekturbrille sehen will, so steht es zwar bei Evans nicht geschrieben, aber ich interpretier das mal locker da rein. Du willst halt im Prinzip auch eine Software, die diese Struktur deiner Problemdomäne quasi widerspiegelt, ja? Also ich will jetzt nicht auf der einen Seite 'n Event Storming machen und irgendwie alles über Events modellieren und danach brauche ich eine MVC Anwendung. Die tut zwar vielleicht genau das, was ich in meinem Modell ermittelt habe, aber ich hab eine ganz andere interne Struktur. Das bedeutet, ich hab hier 'n Bruch. Ich kann nicht mehr die Software anschauen und auf das Modell zurückschließen. Die Idee der ist ja, dass das Modell in der Software auch quasi dem mentalen Modell der Fachanwender entspricht. Das zu erreichen, müssen wir uns in der Umsetzung von technologischen, das haben wir immer schon so gemacht, Dingen lösen, weil ich eben nicht sage, ja, da brauche ich jetzt mein OEM ein, weil wenn das im mentalen Modell des Fachanwenders so halt nicht vorkommt oder gar nicht notwendig ist, dann muss ich das halt auch infrage stellen. So, was hilft uns jetzt die Ubiquideous Language, wenn wir das Problem, das wir in den Köpfen der Fachanwender haben oder die Domäne, die wir gemeinsam ausgeprägt haben, so als Software aufschreiben, diese Domäne wird sich ändern. Wir werden das Verständnis für die Domäne wird sich ändern und die Domäne selbst wird sich ändern. Und dann ist die Frage, wie leicht können wir unsere Software ändern? Wenn wir da wenig technologische Schulden, Technical Debt, wie auch immer man es nennen möchte, drinnen haben, also Entscheidungen, die es uns schwierig machen, bestimmte Dinge zu verändern, dann haben wir es leichter, unsere Software an die Veränderungen an der in der Domain, an den Markt anzupassen. Und das ist, glaube ich, wo die die Ideen von Domain Driven Design auch an der Stelle sehr stark helfen können, nachhaltige Mainainable Software zu bauen. Muss ich aber gleich 'n Sternchen dran machen, deswegen betone ich auch immer Make or buy, weil es ist ja nicht immer richtig, jetzt alles, was man da haben will, als Custom Software from Scratch zu schreiben, ne. Man muss also auch gucken, kann ich vielleicht als Unternehmen, die neue Wege gehen, also wo kann ich wiederverwenden? An welchen Stellen muss ich meine Software selber schreiben, weil es gibt da halt nichts, ja? Wenn man heute zwanzig vierundzwanzig guckt, gibt es so viele Bibliotheken, so viele Systeme, so viele SaaS Services, so viele Cloud Angebote, die teilweise richtig gut sind und die teilweise bestimmte Sachen richtig gut machen. Wenn ich als alter Mann zwanzig Jahre zurückschau, da gab's das alles noch nicht und zwar literally alles noch nicht. Da musste man ganz viele Dinge selber bauen, ja. Und das ist halt was, was man vielleicht, wenn man heute auf Domain Driven Design guckt, dass man das vielleicht noch stärker betonen müsste, dass wir Make or Buy Entscheidungen viel stärker machen müssen, dass ich mir viel stärker überlegen muss, kann ich da jetzt irgendwelche Sachen, die es schon gibt, irgendwelche Services integrieren und dann noch Mehrwert hinzufügen oder muss ich mir jetzt irgendwie muss ich jetzt versuchen, eine ganze Plattform vom Scratch zu bauen? Das ist schon auch in den ursprünglichen Strategic Design Patterns von Evans durchaus drin, ja, wo er ja über Also auch im im Bounded Context eigentlich, wo er sagt, es gibt den Es gibt die Core Domain, es gibt generische Sub Domains, es gibt die Supporting Domains und Supporting Domain ist sowas wie doppelte Buchführung. Da gewinnst dir keinen Blumentopf, wenn Du das selber schreibst, außer Du bist die DATEV. So. Also, ich glaube, dass die Tatsache, dass die Software im in der Sprache und in der Struktur dem entspricht, wie wir unser Business haben wollen, dass das 'n großer Wettbewerbsvorteil ist, weil Du dann, wenn Du dein Business anpasst, natürlich auch die Software, ja, leichter anpassen kannst. Okay, muss man vielleicht noch dazu sagen, man muss das Ganze dann handwerklich auch richtig umsetzen und sinnvoll umsetzen, weil bloß weil ich eine Domain Driven Designanalyse mache, wenn ich dann die Software mit starker Kupplung umsetze und die eben nicht leicht änderbar ist, dann habe ich natürlich auch keinen Spaß im Leben.
Jan: Aber jetzt kommst Du da auf Fabi, Manuel?
Fabi: Also vielleicht, ich glaube in meinem Blick, wo ich mal sagen muss, ich bin ja derjenige, der wahrscheinlich hier mit der in der Realität Domain Driven Design umsetzen am wenigsten Erfahrungen hat. Ich weiß gar nicht, in wie viel Erfahrungen Du hast, aber ich bräuchte, glaub ich, noch mal son bisschen Kann ich mir probieren, mir jemand abzuholen, wie Domain Driven Design jetzt wirklich in meinem Alltag aussieht. Weil wenn ich darauf höre, denke ich so, ist ja viel, also kollaborativ wird die immer wieder genannt sozusagen. Wie sieht meine Kollaboration im Alltag aus? Weil irgendwie viel, der Ball spielt mir jetzt son bisschen drauf, bevor ich anfange, dass ich überhaupt diese gemeinsame Sprache finde, aber ich wirklich jetzt so, wenn wenn ich als Entwickler, sagen wir mal, ich arbeite in 'nem Kontext, wo ich wirklich mit diesem wo's diesen Fachexperten gibt, der nicht ich bin so, wie sieht mein Entwicklungsalltag in Domain Driven Design aus und wie gehe ich an ein neue Teilfeature ran? Wie gehe ich vielleicht auch beim ersten Mal die ganzen Beats? Wie sieht wirklich mein Alltag aus? Was ändert sich eigentlich in meinem Alltag, wenn ich Domain driven Design anwende? Weil das gefühlt, wenn ich da drauf höre, hat es mehr Einfluss auf mein Miteinander als auf meine reine Entwicklungsarbeit so und das ist das, was es für mich in meinem Kopf so unterschiedlich macht.
Stefan Priebsch: Mhm. Ich glaube, dass Du das schon schon absolut richtig erfasst hast. Also lass es uns mal an 'nem Beispiel durchgehen. Du bist Entwickler und Du kriegst in deinem Lieblingsticketsystem, kriegst son schönes Ticket, wo drinsteht, ich brauche und das brauche ich am besten demnächst so. Und dann macht ihr irgendwie son Sprint Planning und sagt, okay, lalalalalalal, baue ich jetzt mal im nächsten ein oder zwei Sprints. So. Und jetzt gucken wir mal, was la la
???: la la la la la la la la la la la la la la la la la la la la
Stefan Priebsch: la la la la la la la la la la la la la la
???: la la la la la la la la la
Stefan Priebsch: la ist. Das ist typischerweise die und die Prüfungen auf das Formular draufpacken und und fertig. So. Und dann guckt man sowas an und tut sich immer tatsächlich schwer, Akzeptanzkriterien dafür zu finden. Ja, andere als son Ende zu Ende Test durch die ganze Software. Und was hier grade passiert, ist, dass Du eine Lösung man dir aufgeschrieben hat. Das ist die Lösung, die ich möchte. Jetzt bitte der Kodierer möge das implementieren.
Jan: Darf ich da ganz kurz kurz reinhüpfen? Ja. Ich würd sogar noch 'n halben Schritt zurückgehen. Ich glaube, es ist nicht mal die Lösung, die dir da präsentiert wird, weil das ist ja das, von dem dein Stakeholder glaubt, dass es eine Lösung sein könnte. Das ist ja eigentlich viel konkreter sogar noch. Es ist ja schon eine Implementierung, weil er sagt, ich hätte genau gerne dieses Verhalten. Das Einzige, was Du ja dann machst, ist, wie Du sagst, nur dieses Verhalten zu implementieren. Aber es ist ja eben nicht die gemeinschaftlich erarbeitete Lösung, weil Du als Fabi weißt ja eigentlich gar nicht, was das Problem ist, was er eigentlich beheben will, sondern Du kriegst ja nur vorgehalten, mach mal.
Stefan Priebsch: Genau. Das ist genau der Punkt. Und also und das ist, das passiert, weil alle Beteiligten das Beste wollen, weil irgendwie gefühlt ist ja immer die Entwicklung der Engpass, Sie jetzt einfach mal so unkommentiert stehen. Gefühlt ist die Entwicklung der Engpass. Also versuchen wir vor der Entwicklung möglichst viel Arbeit zu machen, damit die Entwickler möglichst wenig zu tun haben und produktiv sein können. Das wäre jetzt mal agiles Arbeiten falsch verstanden, aber so zumeist sehe ich's umgesetzt. Und dann kommt jemand, der eigentlich nicht Entwickler ist und macht 'n Lösungsvorschlag, den er aus seiner Verstehens- und Erlebniswelt draus macht.
???: Und
Stefan Priebsch: wie Jan gerade gesagt hat, was hier verloren geht, ist, welches Problem wollen wir eigentlich lösen? Und Domain Driven Design ist, wenn man's mal ganz verkürzt darstellen will, im Grunde erst mal die Sache, dass Du sagst, welches Problem wollen wir denn lösen? Ich möchte das Problem verstehen. Ich möchte nicht den vorgeschlagenen Lösungsansatz verstehen, sondern was ist das Problem, was wir lösen wollen? Und wenn man das dann gemeinsam erarbeitet, dann kommt ein ganz anderer Lösungsraum noch mal auf. Wenn wir dann sagen, ja, pass mal auf, anstelle da auf der Seite in dem Formular das und das da einzubauen, könnten wir ja auch an einer ganz anderen Stelle das so bauen und das ist ja vielleicht viel schlauer. Und die Idee von Domain Driven Design ist am Ende des Tages, dass Du das nicht jedes Mal wieder über das Ticket in deinem Refinement machst oder noch schlimmer, nachdem Du die Software geschrieben hast und dann alle Beteiligten irgendwie feststellen, Scheiße, ist eigentlich nicht das, was wir haben wollten, sondern damit beginnen. Also gemeinsam über die Probleme sprechen und dann gemeinsam auf Augenhöhe Lösungen anbieten. Da spielt dieses Thema gemeinsame Sprache unter Menschen wieder eine ganz wichtige Rolle und jetzt muss ich mich, bin ja auch irgendwie im Herzen einen Entwickler, ne, wir sind ja auch son bisschen Technologiespielkram verliebt, haben jetzt letztens auf 'ner Konferenz 'n 'n coolen Vortrag gehört über Technologie XY, Framework irgendwas, neue Ding, AI irgendwas. Müssen wir unbedingt ausprobieren. Also quatschen wir das halt auch in irgendwelche Lösungen rein, weil wir sagen, hey, das macht man jetzt so. Das ist jetzt voll hip. Das muss jetzt so sein. Ja. Und das ist wirtschaftlich 'n totaler Quatsch. Ja das ist wirtschaftlich 'n totaler Quatsch, ja. Eigentlich müssen wir viel weniger technologie- und lösungsverliebt sein als Entwickler und viel weniger sagen, ja, ich will das jetzt bauen, weil das cool ist, sondern ich muss überlegen, was braucht eigentlich mein Unternehmen? Was ist der Geschäftswert? Was ist das, wo ich jetzt irgendwie für alle mit möglichst wenig Aufwand eine gut genug Lösung schaffen kann? Und dann werden wir uns anderen gut genug Lösungen widmen. Und am Ende des Tages ist die Erfahrung aus vielen Projekten und auch von vielen Leuten und das ist ja auch publiziert, dass man eigentlich viel besser fährt, wenn man sich mit so gut genug Lösungen quasi zufriedengibt, weil die dann halt fertig sind, wertent entfalten versus, ich versuche hier perfekte Lösungen zu bauen und brauch dann noch zwei, drei, vier Wochen. Und kennt ihr das, wenn man son Sprint Review ist oder so und dann heißt es so, ich bin fast fertig. Und dann bist Du zwei Wochen später, ich bin fast fertig. Und dann zwei Wochen später, ich bin fast fertig. Und dann fragst Du irgendwann, also wann wann ist 'n jetzt fast fertig? Da ist irgendwie 'n Problem.
Jan: Ja. Aber Aber diese Argumentation würde ich gerne mal umdrehen. Okay. Weil Du sagst, na, jetzt jetzt war jemand auf 'ner Konferenz und hat hier irgendwie vom siebenhundertachtunddreißigsten JavaScript Web Framework gehört, das er gerne probieren wollte. Ich denk mir grade so, jetzt sitzt irgend 'n Zuhörer zu Hause und hört so diese Folge und ich so, oh, dieses Domain Driving Design, das ist ja megacool. Das brauchen wir auch. Und dann rennt er morgen in die Firma, ins Büro und geht zu seinem Teamlead oder seinem Team oder seinem Chef, was auch immer sagt, hey, hör mal, also egal, was das nächste Projekt ist, wir machen jetzt mal Domain Driving Design, weil ich hab gehört, das ist megacool und das hilft uns und das ist the Hot Shit, ja?
???: Mhm.
Jan: So, seit zwanzig dreiundzwanzig, das brauchen wir jetzt. Seit zwanzig drei, also. Ja, mhm. Und also ich will gar nicht schlecht reden, was Du sagtest, ne? Aber ich will nur verhindern, dass Leute in genau dieselbe Falle, aber halt eben nicht auf technischer, sondern auf methodischer Ebene sozusagen reinrennen. Und deshalb einmal ganz vorsichtig die Frage stellen, gibt es vielleicht auch Cases oder oder Arten von von Projekten oder oder Umgebung, wo Du sagst, also da ist Domain Driven Design vielleicht überhaupt nicht für geeignet, weil das einfach nicht in sonem Setting seine seine Stärken ausspielen kann, aber vielleicht mit allen Kosten daherkommen, ne. Du hast vorher viel von dem explorativen Aufwand. Du Du baust diesen Sprachkatalog auf, Du findest deine Kontext et cetera, aber aus irgend 'nem Grund ist dein Projekt so aufgebaut, dass Du nie in diese Phase reinkommst, die Stärke auszuspielen Und dann bist Du natürlich, wenn wir hier über Wertschöpfung reden, ganz schnell bei 'nem negativen Saldo sozusagen.
???: Aber
Fabi: das finde ich interessant, Stefan Dapfknecht, bevor Du drauf antwortest, weil wie gesagt, ich bin ja der son bisschen von außen draufblick. Und wenn ich jetzt grade son bisschen Ausführungen zugehört habe, ich eigentlich eher, das was mir, ich hab jetzt nicht das Gefühl, ich komm hier raus und denke Domain driven Design ist der absolute heilige Greif, mit dem ich diese Probleme löse, sondern eher die Problematik, das Problembild, was ja aufgemacht wurde, ist, die gemeinsame Lösungsfindung und die gemeinsame Arbeit wirklich an dem Problem und nicht eben die komplette Aufgabentrennung, was das angeht, sondern die die die Diskussion, die gemeinsame Lösungsfindung auf Basis des Problems und des Problems möglichst genau zu definieren an der Stelle und zu verstehen. Und ich, so wenn ich's jetzt betrachte, ich hätt wahrscheinlich eher als Nächstes gefragt, Stefan, ist Domain driven Design einfach nur eine Art, dieses Problem zu lösen oder bringt mir Domain driven Design am Ende noch mehr als nur das so? Oder könnte ich mir auch noch andere Lösungsmöglichkeiten für dieses Problem überlegen so? Weil daran würd ich für mich schon 'n bisschen ableiten, ist das wirklich der heilige Gral, der es überall löst oder ich denke eher, es wirkt wie ein mögliches Tool, dieses Problem zu lösen grade. So blick ich grad drauf.
Stefan Priebsch: Ja, das ist jetzt grade ganz viel, was ich da drauf sagen kann auf ganz vielen verschiedenen Ebenen. Ich ich hoffe, dass das in meinem Kopf jetzt alles im im Stack bleibt.
Fabi: Also Wir haben's ja auch nicht einfach gemacht Natürlich. Mit unserer Mehr Mehr
Stefan Priebsch: Natürlich. Mit der Durchführung. Bietet dir jetzt Domain Driven Design, zum Beispiel mit diesen Patterns, auch so eine Anleitung, wie man Dinge umsetzen kann. Das ist natürlich, wenn man vom Blauem Buch ausgeht, Stand zweitausenddrei. Da hat sich in den letzten Jahren viel getan und deswegen kommen dann so Themen wie CQAS und Eventsourcing gerne mit, weil deshalb modernere und auch sehr valide oder vielleicht validere Umsetzungsstrategien sein Strategien sein können. Ich glaube, dass am Ende des Tages kannst Du mit 'nem guten Problemverständnis und 'nem sehr starken, mit 'ner sehr starken guten Zusammenarbeit zwischen Fachexperten oder Product Owner oder wie man's immer auch nennen will und Entwicklern, kannst Du sehr erfolgreich sein, auch wenn Du relativ schlechte Software schreibst. Ich sehe das tatsächlich oft, dass Firmen sehr erfolgreich sind und man würde nicht sagen, ihre Software ist super. Ja? Ich glaube, das, was Jahn so ein bisschen infrage stellt, auch zurecht ist, bringt es uns irgendwas, die Software zur Perfektion zu treiben, wenn wir damit kein Geld verdienen oder wenn wir damit noch kein Geld verdienen? Ich würde das aufgreifen und sogar noch verstärken und sagen, These, wenn dem so ist, dass uns die Perfektion in der Software nichts bringt, dann sollten wir die Software gar nicht schreiben. Dann muss es das schon irgendwo geben. Dann sollten wir das wiederverwenden. Wir schreiben viel zu viel Software. Wir schreiben allesamt, wir schreiben viel zu viel Software. Wir können diese ganze Software, die wir bis jetzt schon geschrieben haben, gar nicht maintainen, ja?
???: Ich hab da
Stefan Priebsch: mal 'n Artikel drüber geschrieben, der heißt Entwickler gesucht, Mainainer gefunden. Ich hab letztens in 'ner Schulung in 'nem Workshop gefragt, wie viel Prozent Maintenance macht ihr denn? Dann kamen wir bei siebzig im Schnitt raus für einen Entwickler. Das ist eine harte Nummer. Also eigentlich sind wir alle keine Softwareentwickler, sondern eigentlich sind wir Software Maintenainer. So und wir schreiben so viel Software, die schwer zu maintainen ist und das wissen wir auch alle. Wir bauen uns da einen riesigen Haufen Sachen auf, die wir eigentlich gar nicht beherrschen können. Deswegen glaube ich ganz fundamental dran, dass wir weniger Software entwickeln müssen. Wir müssen also mehr standardisieren, wir müssen mehr auf Standardlösungen zurückgreifen. Wie gesagt, Stand heute gibt es viele coole Standardlösungen. Im Vergleich, ich mach das jetzt schon eine ganze Weile, was es vor zwanzig, fünfundzwanzig Jahren gab, ja, der PHP vier Zeit neunzehnhundertneunundneunzig, da gab's noch nicht mal oder da ist vielleicht grade WordPress in seiner ersten Version irgendwie rausgekommen und da konnte man quasi einen Blog damit als Content Management betreiben, ja. Und heute haben wir da ein ganz anderes Umfeld und das machen wir uns viel zu wenig zunutze oder manchmal viel zu viel, weil wir dann irgendwie siebenundzwanzig Cloud Services miteinander integrieren, die wir vielleicht gar nicht brauchen. Ja, also son gesunder Minimalismus schadet natürlich nicht. So, also ich glaube sehr wohl, dass man daran scheitern kann, Software zu schreiben. Und ich, also Du sagst, wenn wir die Software dann so mit allen Mitteln, Kunst, Domain Driving Design und so, ich sage, generell ist die Frage egal, ob wir gute oder schlechte Software schreiben. Wir müssen uns die Frage stellen, sollten wir diese Software schreiben? Welche Wartungsverpflichtung gehen wir mit der Software ein? Ich sag immer, die wichtigste Frage ist, wie lang soll dieses System leben? Wie lang haben wir das? Haben wir das für ein Jahr? Haben wir das für zehn Jahre? Haben wir das für zwanzig Jahre? Ja, also wie lang glauben wir, dass wir es brauchen? Wenn mir jemand sagt, wir brauchen es für zwanzig Jahre, aber bau es einfach mal quick and dirty, da passt was nicht zusammen, ne? Auf der anderen Seite, wenn mir jemand sagt, wir explorieren gerade einen Markt, wir wollen gucken, ob unsere Markthypothese passt und in 'nem halben Jahr sind wir entweder pleite oder wir müssen pivotieren oder wir sind super erfolgreich, dann bau jetzt Software, die für 'n halbes Jahr hält, weil danach wirst Du sie wegschmeißen müssen. Entweder weil Du was anders machen musst oder weil Du pleite bist oder weil Du so schnell wächst, dass Du deine Software, die Du in 'nem halben Jahr gebaut hast, nicht skaliert kriegst, sondern Du musst dann eine neue Iteration bauen. Also da müssen wir mal ehrlich sein und sagen, hey, wie lang soll das System leben? Wie gut müssen wir es bauen?
Jan: Da hab ich eine kleine Geschichte zum Teil. Okay. Die ersten Mal vor, boah, ist schon zehn Jahre her oder so, Software bauen, die mit Feiertagen gearbeitet hat.
???: Und
Jan: Feiertage, jeder, der weiß, ne, deutsche Feiertage hängen viel an der Kirche, Kirchenfeiertage hängen viel am Mondkalender. Und dann sitzt Du da und fängst an, sonen Mondkalender zu implementieren, ist okay, irgendwie Ostern ist immer nach dem Vollmond im Frühling und und bla bla bla. Und davon abhängig ist das ganze Kirchenjahr aufgebaut und rechnest Du zurück und überhaupt. Und so nach 'nem halben Tag hab ich gesagt, nee, hab das aber alles weggeschmissen, hab Kalender gegoogelt und hab die Feiertage der nächsten zwanzig Jahre da einfach hart einkodiert, weil die Chance, dass sich Weihnachten ändert, ist ehrlicherweise relativ gering, so, ja. Und selbst wenn sich irgendeine Feiertagsberechnung ändert, müsste ich ja meinen Algorithmus oder meine Funktion auch anpassen, so. Also ich gewinn ja eigentlich nix dadurch, so.
???: Und dann
Jan: haben wir gesagt, gut, wir hartkodieren da die nächsten zwanzig Jahre rein. Die Chance, dass diese Software ehrlicherweise zwanzig Jahre überlebt, ist verschwindend gering, so, ja? Wobei PHP Anwendungen ja relativ langlebig sind, aber das noch 'n anderes, 'n anderer Punkt. Und selbst wenn in den dann hat halt in habt ihr jetzt zwanzig Jahre Zeit, die nächsten zwanzig Jahre einzupflegen, so.
???: Ja, ich
Jan: finde Und das hat dann eine halbe Stunde gedauert und dieses Problem war gelöst auf die langweiligste Art und Weise so, ja? Aber es hat halt ehrlicherweise funk, das ist nicht spektakulär, Du gewinnst keinen Konferenztalk damit oder so, aber es war halt einfach fertig.
Stefan Priebsch: Ja, genau und wenn man halt angesichts von Y2K und dem der Apokalypse zwanzig achtunddreißig, ne, wenn der wenn der Linux Timestamp zweiunddreißig Bit überläuft und keiner weiß, ob dann die Aufzüge noch funktionieren und so. Wenn man angesichts solcher Probleme natürlich heute als Informatiker sagt, ich baue jetzt ganz bewusst eine Lösung, die sozusagen son End of Life hat, also zumindest son, wo jemand 'n Wecker stellen muss und dann musst Du da mal was tun, damit die Software wieder für so und so viele Jahre funktioniert. Dann sagt das Informatikerherz oft so, ups, wirklich echt?
Jan: Ja, ganz ekelhaft so.
Stefan Priebsch: Ja, aber wenn man's mal wirtschaftlich betrachtet, ist es genau genau genau das Richtige. Ja, und also ich hab über die Jahre sehr viel auch für mich selber mich fortgebildet und auch das Wissen weitergegeben über, wie baue ich denn nachhaltige Software? Wie nutze ich denn die Möglichkeiten, die mir OOP bietet? Gerade in PHP ist OOP heutzutage ja richtig super cool im Vergleich zu dem, was wir früher für OOP hielten in PHP. Und in anderen Sprachen ist es ja auf Augenhöhe gleich. Da kann man super viel machen und man kann eben sehr nachhaltige Software bauen. Also es sind so viele Kleinigkeiten, wenn man die beachtet, dann kommt halt nachhaltige Software raus. Und wenn man halt viele Kleinigkeiten nicht beachtet, die einzeln für sich immer so, ja, wurscht, passt schon, egal, ach mach nicht so, ach schieß, sei nicht so nitpicki. Und wenn ich dann halt solche Kleinigkeiten anhäufe, dann habe ich halt am Ende eine schlechter erwartbare Software, weil ich da härtere Kopplung drin hab und so weiter. Wenn Du sehr gut als Team auf der Lernkurve bist, nachhaltige, lose, gekoppelte wartbare Software zu bauen, dann kannst Du dir sehr viel erlauben im Sinne von, na, ich mach da jetzt mal so eine, sage ich mal, Billig Implementierung von irgendwas, die jetzt für 'n halbes Jahr gut genug ist. Es muss nur jemand aufm Radar haben, ne, dass man dann vorher, vor das halbe Jahr abläuft, da irgendwie noch mal ran muss, ja. Und wenn man ganz ehrlich ist, wir wir haben aktuell ist ja wieder son ganz großes Thema unsere Straßen, unsere Infrastruktur, unsere Brücken, ne. In Dresden ist ja letztens gerade wieder eine Brücken, ne. In Dresden ist ja letztens gerade wieder eine eingestürzt, was jetzt echt scheiße ist. So, zum Glück ist da soweit ich weiß niemanden, was passiert. Aber wenn man mal ehrlich ist, da wird das genauso gemacht. Da baut man jetzt ein Bauwerk mit 'ner Lebensdauer von vielleicht zwanzig Jahren. Da bauen wir jetzt ein Bauwerk, das wird, wenn wir es nicht warten mit einem bestimmten Aufwand, wird es in n Jahren irgendwann zusammenfallen und ist nicht mehr benutzbar oder vielleicht nicht mehr redbar. Also das passiert in der Welt da draußen, dass man alles eigentlich für eine sehr begrenzte Lebensdauer nur baut. Das wird vielleicht nicht so offensichtlich. Und bei Software haben wir uns irgendwie diese Illusion hingegeben, dass die für immer lebt oder für immer leben könnte, was ja auch so ist, aber der Wartungsaufwand ist halt da. Den sehen wir, glaube ich, gerne nicht in dem Maße, wie er eigentlich wirklich anfällt.
Jan: Wenn ich jetzt nachhaltig bauen will und auf den DDD Zug aufspringen möchte sozusagen, ja, und ich bin jetzt aber hier nur ein kleiner Entwickler, ein kleines Rad in der großen Maschine und würde das aber gerne irgendwie hier hier einführen. Was für Chancen habe ich denn? Also ich hab schon mit Teams gearbeitet, die versucht haben, generell agiles Arbeiten in Firmen zu etablieren, die einfach überhaupt nicht agil waren und dann sone kleine agile Insel in der Softwareentwicklung in einer großen Wasserfallfirma waren, ja, und das ist son Grundrezept, unglücklich zu werden, sag ich mal. Wie ist es denn mit Domain Driven Design? Gibt es da eine, ich sag mal, eine partielle Implementierung von oder ist das so ein All in on Nothing Ansatz? Also kann ich als Team sagen, wir arbeiten für uns, ich arbeite für mich nach diesem System, auch wenn alle da draußen da kein Interesse haben, das boykottieren oder was auch immer oder geht das nur, wenn alle wirklich mitmachen?
Stefan Priebsch: Also erstens mal würde ich sagen, ich stimme dir absolut zu, dass agil ein, also Agilität einführen aus der Entwicklung heraus, sagen wir mal, ein extrem hohes Scheiterungspotenzial hatte und hat. Also das hat nicht funktioniert, wenn man's mal so auf binär mappt.
Jan: Ja. Scheiterungspotenzial finde ich übrigens gut.
???: So. Das muss
Jan: man mal denken.
Stefan Priebsch: Wenn Du Domain Driven Design aus der Entwicklung heraus einführst, ist es exakt das Gleiche. Du wirst Domain Driven Design aus der Entwicklung heraus nicht einführen können. Du kannst es einführen, wenn Du 'n Buy in hast vom ganzen Unternehmen oder von oben oder von Stakeholdern oder von Pos und wenn die sagen, wir wollen insgesamt wollen wir irgendwie besser werden und unseren Entwicklungsprozess verbessern, ja, wir wollen irgendwie mehr Output haben und und vielleicht nachhaltigeren Output, wenn das so die Grundprämisse ist, dann kann man ansetzen und sagen, lasst uns mal die Organisation anschauen, lasst uns mal gucken, wo ihr quasi welche Fehler macht, wo ihr was verbaselt, wo ihr was falsch macht und dann lasst uns mal gucken, ob wir, was wir wo an welchen Stellen anders machen können. Da kann jetzt, da kann man Domain Driven Design drüber schreiben. Leider ist es ja ein bisschen wie Blockchain und AI immer so ein Ding, da muss DDD manchmal stehen, damit die Leute das einkaufen oder damit es vermittelbar ist und dann schreiben wir halt Domain driven Design, manchmal auch irgendwohin, wo wir sagen, na ja, also ist halt ja die Grundidee von besserer Kollaboration, okay, schreiben wir Domain driven Design drauf. Das ist halt auch, sagen wir mal, fragwürdig, aber auf der anderen Seite muss ich ja als Verkaufender in meinem Unternehmen auch den Leuten die Angebote machen, die sie irgendwie anfragen und die sie haben wollen. Oft ist es so, dass Unternehmen und gerade Entwicklungsabteilungen nach Domain Driven Design fragen und ich würde sagen, in achtzig Prozent der Fälle wollen die Entwickler dann nur die taktischen Patterns hören. Und wenn Du ihn mit Bounded Context anfängst und mit strategischen Design, sagen sie,
Fabi: das ist so theoretisch, das ist
Stefan Priebsch: so doof, komm, lass weg. Lass uns lieber wieder was am Code machen.
Jan: Und ja. Okay, dann dann Folgefrage dazu. Ja. Wenn Du jetzt in eine Firma, in ein Team reinkommst in deine Rolle und da gibt es schon ein bestehendes Produkt, eine bestehende Software.
Stefan Priebsch: Mhm.
Jan: Und da soll jetzt migriert werden. So, wir wir wollen jetzt ab sofort an dem selben Ding weiter. Wir haben hier eine Legacy Codebase, aber jetzt machen wir das DDD Style. Wie kann das denn vonstattengehen, weil so ein ein guter DD Flow setzt ja voraus, ne, wir haben da vorhin so am Anfang drüber gesprochen, dass es so eine gewisse Synchronität zwischen dem dem Kontext, dem formulierten Modell und der Software und der Architektur gibt. So, und wenn ich jetzt natürlich hier nicht auf der grünen Wiese anfange, sondern da schon meinen fünfundzwanzig Jahre alten Monolith irgendwie stehen hab, Wie fange ich denn da an? Weil alles, was ich mir dann an unbauended Kontext und Vokabular und sowas ausdenke, entbehrt ja der Realität meiner Softwarearchitektur.
Stefan Priebsch: Ja, das ist 'n Riesenproblem und das ist auch ein eine meines Erachtens nach, eine Lücke in Evans oder bei Evans, dass Ich sehe auch ganz oft das Problem, dass man sagt, ja, wir wollen eine eine Ubiquitus Language ausprägen. Das Problem ist, dass die Ubiquitice Language ist quasi schon vorhanden und ist aber die Sprache des der bestehenden Softwarelösung. Also so wie da halt die Buttons heißen und wie die Dinger halt heißen und die Screens heißen, so nennen die Leute Dinge und sind sich eigentlich alle einig, dass das nicht ganz richtig ist, weil Aber das ist halt historisch gewachsen. Eigentlich benutzen wir es jetzt ganz anders, aber es heißt halt in der UI so, deswegen nennt es jeder so. Und was überhaupt nicht funktioniert, zumindest nach meiner Erfahrung, vielleicht gibt's ja da draußen jemanden, der eine andere Erfahrung hat und die mit uns teilen mag, zu sagen, ja super, wir definieren jetzt hier mal 'n Wörterbuch und jetzt nennen wir mal alles weil das funktioniert einfach gar nicht. Also mit dem Disclaimer, dass es generell überhaupt kein Patentrezept gibt, wo man sagt, das ist die Lösung für alles und bloß, weil ich das jetzt so gesagt habe, funktioniert das. Was nach meiner Erfahrung relativ gut funktioniert oder lass es mich noch defensiver sagen, wo Du die größten Chancen auf Erfolg hast, ist, wenn Du sagst, okay, wir wollen irgendwas Neues machen in dem Unternehmen, ja. Wenn wir jetzt nicht nur von Maintenance reden, Du hast Migration gesagt, Migration ist ja oft Also wir haben den rein technischen Aspekt, das muss auf eine neue Technologieplattform oder so, den können wir jetzt weglassen, weil das ist 'n reines Technologieproblem. Wenn Du sagst Migration, weil wir auf eine neue Plattform umziehen, weil wir wollen mit dieser Lösung integrieren Wir haben jetzt SAP eingeführt oder irgend sowas, dann ist ja da auch immer funktional irgendwie, wir wollen was anders machen, wir wollen andere Prozesse abbilden. Und dann ist für mich der Einstieg, okay, ich suche mir jetzt was, was es in der alten Software nicht gibt. Und da gehen wir quasi von der Analyse her Greenfield mit Domain Driven Design Mentalität ran oder mit mehr Domain Driven Design Mentalität, als wir das bisher getan haben. Und da haben wir dann sozusagen eine freie, 'n freies Feld, wo wir das tun können. Was wir dann softwaretechnisch machen, ist, wir bauen ein neues Stück Software, wir bauen einen neuen Service und wir müssen uns überlegen, wie kriegen wir den mit dem, was wir haben, integriert? Weil irgendwie, wir bauen was Neues zwei, drei, fünf Jahre im stillen Kämmerlein und dann gibt's eine Big Bang Migration. Haben viele Leute ausprobiert, wie war das Wort, was ich vorhin erfunden hab, Scheiterungswahrscheinlichkeit hoch, ja? Also da kann man sich sauber die Finger verbrennen. Das heißt, für mich ist der Weg nach vorne meistens anzuerkennen, okay, die Software, die wir haben, die findet zwar keiner so richtig cool, weil sie halt so passiert ist, wie sie jetzt ist aus Gründen und vielleicht auch von Leuten, die jetzt gar nicht mehr da sind oder unter irgend 'nem riesigen Druck oder für einen ganz anderen Use Case gebaut ist, für einen ganz anderen Scale, aber sie läuft immer noch. Wir sind alle nicht wirklich glücklich damit, aber sie läuft noch und sie verdient Geld. Wir werden nicht hier, wenn es die Software nicht gäbe. Das muss man erst mal anerkennen. Und dann ist die wichtigste Erkenntnis zu sagen, okay, wenn wir Dinge anders machen wollen, dann müssen wir aufhören, unseren Monoliten weiter zu füttern. Ich für mich stell mir son Monoliten immer wie 'n schwarzes Loch vor. Da da kommt immer noch mehr Masse rein und dann wird die Gravitation noch höher. Also der der Monolit zieht immer noch mehr Software an und wird immer noch fetter. Und wenn wir schon nicht damit glücklich sind, dann sollten wir das vielleicht nicht weiter füttern. Also ist die einzige Möglichkeit, außer jetzt den unrealistischen Case, wir schmeißen die ganze Software weg und nehmen eine andere. In seltenen Fällen mag das funktionieren. Im Allgemeinen muss diese Software, wie sie da ist, weil da bestimmte Kunden drauf sind, Spezial Use Cases und so, die kriegen wir so schnell nicht abgelöst, muss die weiterlaufen? Ist also immer die gestellte Aufgabe. Wie kann ich neue Lösungen mit der bestehenden Software integrieren? Ob das jetzt dann gekaufte Lösungen sind, selber gebaute Lösungen, was auch immer, ist eine ganz andere Frage. Also wir bewegen uns eigentlich immer in sone Welt, wo wir mehr Komponenten, kleinere Komponenten haben hoffentlich, die wir miteinander integrieren müssen. Und jetzt kommen wir wieder zurück zum DDD. Da hätten wir son Modell von Bounded Contexts, ja? Wo wir 'n Bounded Context sagen, ja gut, zum Beispiel son son, weiß ich nicht, son Salesforce ist halt 'n Bounded Context, weil da drin ist halt mal eine eigene Sprache. Da gibt's halt Contacts und Leads und so und die haben halt eine bestimmte Bedeutung. Und in 'nem anderen System haben die Dinge vielleicht eine andere Bedeutung, also ist das 'n anderer bounded Kontext. Und jetzt habe ich schon eine sehr enge Kongruenz, glaube ich, zwischen eine Kontextmap zu machen und eine Software Architektur zu bauen. Und da bin ich 'n großer Freund von zu sagen, lass uns doch mal eine Zielarchitektur entwerfen, wo wir idealtypisch in, sagen wir's mal, fünf Jahren sein wollen. Ja, weil wir glauben, das Unternehmen möchte in fünf Jahren machen können oder erreicht haben. Was müssen wir da für eine Architektur haben? Lass uns das mal aufmalen, ja. Dann malen wir uns mal den Status quo auf, was übrigens manchmal erstaunlich schwierig ist. Und jetzt haben wir zwei Diagramme, wo wir sagen können, okay, wir haben jetzt links und rechts sone visualisierte Vorstellung. Wie können wir einen Weg von von hier nach hier finden?
Jan: Das finde ich eine coole Übung. Das habe ich auch schon mal mit 'nem Team gemacht und auch in anderen Situationen kann das mega hilfreich sein, weil Du dann ganz oft bei Technologieentscheidungen fragen kannst, na gut, ist es ein Schritt, der uns näher an diese Vision Brand bringt?
???: Mhm. Ist
Jan: es ein Schritt, der uns diese Migration zumindest nicht schwieriger macht oder ist es was, was uns in drei Jahren irgendwie auf die Füße fällt, ja? Und dann kannst Du zumindest sagen, na ja, alles, von dem wir dann wissen, dass es uns in 'n paar Jahren wehtun wird, das können wir schon mal nicht machen, so, ja? Es muss uns nicht unbedingt näher dahin bringen. Es kann uns auch quasi parallel dazu führen, aber es darf uns auf alle Fälle nicht weg davon führen.
???: Mhm.
Jan: So. Deswegen fände ich das immer ganz cool. Fabi, wie überzeugt bist Du jetzt von DDD?
Fabi: Na ja, ich glaub, im Endeffekt ist es ja, ist es ja der Pate und der, glaub ich, fehlt mir noch am Ende zur Überzeugung, ist, was wie setz ich's am Ende denn wirklich ne? Ich würd sagen, von den Grundprinzipien, was mir versprochen wird so und was es was es besser machen sollte, denke ich, das ist auf jeden Fall einen, erst mal eine interessante Idee so in der Praxis. Das Konzept ist, glaub ich, das ist auf jeden Fall noch mal was was ganz anderes, was wie gesagt, der Part, was für meinen Alltag bedeutet, wie ich da rangehe und wie wie ich es umsetze, ist ja noch etwas anderes, was auf jeden Fall für mich fehlt zur kompletten Überzeugung, so aus den aus den Grundfesten. Es verspricht mir die bessere Kommunikation, die bessere Wartbarkeit meines Codes, der der frühe Entscheidungspunkt, also muss ich's überhaupt bauen so. Sind auf jeden Fall erst mal alles Dinge, wie sollte ich das nicht gut finden können? So die Frage ist, ich glaub, das ist so die größte Frage für mich, ist es, es soll mir weniger Arbeit machen, aber wie viel Overhead ist es am Ende und also ist es, bringt es dieser dieser, das ist doch glaube ich, Fragezeichen so, steckt da nicht auch viel Overhead irgendwie mit drin?
Jan: Ich stell mal eine steile These auf, und zwar, ich behaupte, ihr macht schon DDD, ihr merkt es nur nicht. Weil also a arbeitet ja schon mal in 'nem multifunktionalen Team zusammen. Das heißt, ihr habt schon mal nicht so diese Falle, in die viele reinfahren so, wir sind hier das Entwicklungsteam und wir kriegen hier, ne, was Stefan vorhin gesagt hat, nur son Ticket hingeschmissen, was wir implementieren müssen und da geht schon mal viel Kontext und Problem Space verloren so. Das habt ihr schon mal nicht, so, ja. Dann arbeitet ihr mit 'nem Spiel natürlich auch an 'nem Produkt, was wenig an diesem Problem leidet von wir übersetzen ein eine reelle Domain, ein ein Problem Space und einen Solution Space hier irgendwie, sondern ihr denkt euch das ja selber explorativ aus so. Ihr erfindet, also das klingt 'n bisschen blöd, aber ihr ihr erfindet das ja, während ihr daran arbeitet, so ne, so. Und dadurch, dass ihr da so schon so kollaborativ dran arbeitet, schreibt ihr ja diese Domäne selbst am laufenden Band fort, so. Also abgesehen von dem ganzen Vokabular, was der Stefan da natürlich verwendet hat, ja, würde ich behaupten, ihr seid schon achtzig Prozent da.
Fabi: Ja, ich mein, ich hab auch probiert, mich 'n bisschen in die Situation reinzuversetzen, wenn ich grade nicht in der Spieleentwicklung mit 'nem kleinen Team und einem Team, was im Endeffekt die komplett ganzheitlich am Produkt arbeitet und diesen diesen Kommunikationsprozess schon etabliert hat und ich mir jetzt irgendwie überleg, ich bin in einem in einem Unternehmen, die vielleicht 'n bisschen mehr auch noch zu tun haben an der Stelle. Aber da würd ich mich würd ich mir trotzdem die Frage stellen sozusagen, die so wie viel, wie kriege ich's wirklich hin, diesen Prozess so zu implementieren, dass er mir am Ende nicht mehr Overhead bringt durch diese ganzen Kommunikations und Abstimmungen und Also müssen als mein Entwickler Herd fragen würde so, am Ende nicht mehr zum Code schreiben kommt. So, das hat ja Stefan ja schon 'n paarmal auch gesagt, dass sie die Angst dieser Kohle hat, aber ich sag mal so, die konnte ihr mir noch nicht komplett nehmen.
Jan: Aber das ist ja, Stefan, vielleicht auch eine interessante Frage, weil gerade so aus deiner Consultingbrille, ja? Also ich kann mir vorstellen, Du wirst ja oft auch angefragt, darüber zu sprechen, aber wahrscheinlich musst Du ja auch genauso oft Überzeugungsarbeit in in dieser Domäne leisten, weil ich kann mir vorstellen, dass viele Leute da draußen, so ähnlich wie Fabi, darüber denken, so ja, das klingt ja irgendwie alles ganz cool, aber oh mein Gott, dann verbringen ja meine Entwickler Zeit damit, mit Menschen zu reden und dann schreiben die keinen Code mehr. Das ist ja voll ineffizient. So, ich will ja die Zeit, die wo meine Entwickler Coden maximieren und die sollen ja nicht beim Kaffee beieinander sitzen und sich irgendein Vokabular ausdenken. So, was? Wie ist so dein, weiß ich nicht, dein dein sechzig Sekunden Sales Pitch für DDD für Businessmenschen?
Stefan Priebsch: Also erst mal jede Zeile Code, die nicht geschrieben wird, ist mir lieber als eine Zeile Code, die geschrieben wird.
Jan: Das ist richtig.
Stefan Priebsch: Also, wenn ich von der Analyse her ein Problem vermeiden kann, weil ich sag, hey, wir haben hier 'n ganz widerliches Problem und die technische Lösung, die wir gerade als Idee aufm Tisch haben, ist sauaufwendig. Wenn ich jetzt eine Strategie finden kann, dieses Problem zu vermeiden, was natürlich bedeutet, dass wir an einer anderen Stelle ein anderes Problem haben, das ist schon klar. Es ist nie for free, aber wenn wir dieses andere Problem vielleicht erst mal ignorieren können oder einfacher lösen können, dann ist es für mich 'n guter Trade off. Und es gibt so einen wunderbaren Satz, ich glaube, ich kriege jetzt nicht auf aufs Wort hin, aber Weeks of Writing Software,
Jan: Mhm.
Stefan Priebsch: Also da, wo die wo die Wahrnehmung ist, dass Entwickler möglichst viel und schnell Code produzieren sollen und ich unterstell das jetzt niemandem. Aber das schwingt da immer son bisschen mit, wenn man sagt, ja, wenn da meine Entwickler plötzlich miteinander reden, anstelle Code zu schreiben. Ich glaube nicht, dass die Aufgabe eines Entwicklers ist, Code zu schreiben sondern die Aufgabe eines Entwicklers ist es, ein Problem zu lösen. Und eine Möglichkeit, das Problem zu lösen, ist, Code zu schreiben. Ich kann viel und wenig Code schreiben, ein Problem zu lösen. Ich kann ein Problem vermeiden, dann muss ich gar keinen Code schreiben oder ich kann irgendwie fertigen Code verwenden, das Problem zu lösen. Das ist eigentlich der grundlegende Lösungsraum. Meistens geht das verloren, weil man sagt, hier und der Po sagt, bau mir Code und zwar die möglichst einfache Lösung ist, was der im Kopf hat. Und der Entwickler sagt, nein, ich will das besonders gut machen und ich muss ja hier die Edge Cases und wenn Venus und Mars in einer besonderen Konstellation stehen und und was weiß ich was. Und dann bauen wir da immer wunderbar die perfekte Software, weil wir es halt besonders gut machen wollen. Und das ist halt ein Missmatch. So. Ich behaupte außerdem, es sind mehr als sechzig Sekunden, ich weiß. Ich behaupte außerdem, dass die Entwickler miteinander reden. Also, wenn Du mal mitkriegst, was Entwickler miteinander aufm Gang, in der Kaffeepause oder in 'nem Meetingraum oder am Arbeitsplatz oder im Chat miteinander reden über warum wieso weshalb und ich hänge gerade und warum ist denn das so? Das ist viel Zeit, was da drauf geht. Diese Zeit ist schon da. Die Frage ist also nicht, schaffen wir neue Zeiten, wo die Entwickler noch zusätzlich quatschen zu all dem, was wir bisher haben, sondern die Frage ist, schaffen wir es, durch effiziente Kommunikation möglichst frühzeitig uns hinten raus weniger Arbeit zu machen. Und es Anekdotisch scheint das bewiesen zu sein. Es gibt son paar Studien oder nennen wir es mal Pseudostudien, weil ich sag ja immer, Du kannst es eigentlich nur wirklich beweisen, wenn Du 'n Paralleluniversum aufmachst und sagst einmal so, einmal so und jetzt unter sonst gleichen Bedingungen kommt einmal was Besseres, was heißt das nicht. Also Du kannst es ja nicht wirklich vergleichen. Aber jeder, der auf diesem Journey irgendwo gegangen ist, ein Stück weit, der sagt dir, es war danach besser. Es war danach weniger Kommunikation, weil und wenn sie effizienter ist. Natürlich hilft es nichts, wenn Du einen schlecht gelaunten Entwickler auf einen schüchternen Fachexperten loslässt, ja. Das ist dann keine Kommunikation auf Augenhöhe. Also man muss es schon richtig machen, dann stellt sich auch der Erfolg ein, das ist oft genug bewiesen worden. Was richtig machen jetzt im Einzelfall bedeutet und das ist, glaube ich, auch was ganz Wichtiges, es ist ja immer individuell. Es gibt kein Patentrezept. Es gibt keinen, so steht's im agilen Manifest oder so steht's im Scrum Playbook, so müssen wir das tun, sondern es gibt Dinge, die für euch in eurem Domain, in eurer Domain mit eurem Team, in eurer Marktsituation funktionieren, ja? Wenn ich Marktführer bin und meinen Konkurrenten zwei Jahre voraus bin, da kann ich rumeiern, 'n halbes Jahr, wie ich lustig bin. Das merkt keiner. Das hat keinen unmittelbar merkbaren negativen Effekt. Wenn ich aber als Wettbewerber versuche am Markt aufzuschließen und meinen
???: Marktführer irgendwie anzugreifen, dann kann ich
Stefan Priebsch: mir das nicht leisten. Also, aufzuschließen und meinen Marktführer irgendwie anzugreifen, dann kann ich mir das nicht leisten. Also, das sind Äpfel und Birnen verglichen, wenn man sagt, so wie die arbeiten, ist es super, so arbeiten wir auch, weil es kann sein und ist in den meisten Fällen so, dass das, was für eine Team und eine Firma funktioniert, möglicherweise auch nur für eine Abteilung, muss für andere Teams vielleicht auch nur zum jetzigen Zeitpunkt gerade gar nicht funktionieren. Also, da sind mir immer son bisschen Ich verstehe die Punkte, aber da sind eigentlich so absolute Aussagen drin und ich glaube, wir können es nicht so stark vereinfachen, dass wir sagen, ah, wenn Du DDD machst, dann läuft's besser, ja. Oder wenn Du nicht DDD machst, dann wirst Du in fünf Jahren 'n Problem haben. Sondern wir müssen schon genau die Situation angucken. Man sagt ja auch immer in der Informatik, Never Touch a running system. Ich hab das jetzt für IT Systeme, da hat's, das hat was für sich, ja, und don't fix it w wain it a n't broken. Also ich muss da jetzt auch nicht mit Gewalt was anders machen. Wenn Du sagst, wir haben bei uns im Unternehmen hier in meinem Bereich, in meiner Abteilung, da läuft's gerade gut. Ja, dann gibt's ja keinen Grund, dass da jetzt jemand kommt, Buzzword schwingt und sagt, hey, ihr müsst XYZ machen. Ja, wenn es gut läuft, läuft es gut. Wenn Du sagst, es gibt son paar Ecken, da bin ich nicht glücklich damit, dann kann man sich diese Ecken anschauen und sagen, mit welchen mentalen Bausteinen, mit welchen Methoden, mit welchem Mindset könnte ich denn da jetzt rangehen, da vielleicht mal was zu verändern? Ganz gezielt und punktuell. Und dann glaube ich, kann das auch funktionieren. Dann ist auch egal, ob man da jetzt agil, DDD oder was auch immer oben drauf schreibt.
Fabi: Ja. Ja. Aber ich glaub, deswegen vielleicht auch das mit meinem, was ich meinte, mit dem Part Overhead gar nicht, dass der Part. Ich will so alles, was Du grade ausgehörst, Stefan, würd ich eins zu eins unterschreiben. Ich mein, wie dafür haben wir auch alle zu viel schon Entwicklungsarbeit gemacht, dass ich den Satz unterschreiben will. Also auf jeden Fall jede Zeile Code, die man nicht schreibt, besser als eine, die schreiben muss und wir sehr viel mehr über Kommunikation lösen können und wenn wir nicht irgendwie in die falsche Richtung entwickeln so. Und auf jeden Fall hab ich verstanden, dass DD eine sehr gute Möglichkeit sein kann, diese Probleme zu fixen, so. Und deswegen im Endeffekt, glaube ich, muss man seine seine ersten Gehversuche da vielleicht damit vielleicht einfach mal gehen. Und vielleicht so als für mich noch Abschlussfrage so aus meinem Kopf so. Ich werd Ihnen mal ganz einfach ausgedrückt, ist DDD etwas, was ich erst mache, wenn ich schon schlechte Kommunikation habe oder bin ich jetzt, wenn ich jetzt mal unser Kontext so Startup mäßig, ist das erste, über was ich mir Gedanken mache, setz ich DDD ein oder nicht so? Also in welchem, ist das so ein, ist das wirklich ein Entwicklungsansatz, der komplett unabhängig von deinem von deinem Alter deines Unternehmens ist? So ist es etwas, was, wenn Du jetzt morgen ein Unternehmen gründen würdest so und würdest Du würde ich DDDD etwas, was Du direkt an die Tagesordnung auf die Tagesordnung setzen würdest?
Stefan Priebsch: Nein, also erst mal mechanisch schon gar nicht. Also Eric Evans sagt, und Eric Evans sagt, mach dir im Unternehmen ein Team mit den besten Entwicklern und mit denen machst Du Domain driven Design und zwar für deine Core Domain. Für das, was dein Unternehmen am Markt differenziert. Für das, was ihr besonders macht, was für euch speziell ist, das, was die Wettbewerber nicht haben. Das, was euch vom Wettbewerb unterscheidet. Das, was ihr nicht auf the shelf kaufen könnt, weil ihr es eben besonders und anders macht
???: oder innovativer macht als die anderen. Da machst Du Domain
Stefan Priebsch: Driven Design. Es macht und und untersteck und und da steckt im Prinzip die Idee drin, dass Du jetzt halt Es gibt halt 'n soften Team, die bauen halt eine Integration, sage ich mal, zwischen 'nem Webshop und 'nem Salesforce, wo irgendwelche Leads hin- und hergehen oder 'nem Webshop und 'nem PIM, da die Artikel reinzupusten. Und da verwenden die vielleicht irgendwelche klickybunty Services oder sie schreiben 'n Code oder sie machen's mit AI, völlig egal. Und da muss kein Domain Driving Design drin sein. Also Domain Driving Design ist ja nicht etwas, was Du jetzt bloß, weil müssen wir das überall anwenden, sondern und das ist ja auch tatsächlich eben im blauen Buch schon die Message, mach es in deiner Core Domain. Ja? Und in der Supporting Domain, da wirst Du damit leben müssen, dass die Software nicht so cool ist. Und in der Generic Sub Domain, ich parapasier es jetzt mal etwas sehr punktiert, wenn Du in der Generic Sub Domain Software schreibst, bist Du selber schuld. Also wenn Du das, also wenn Du jetzt quasi sagst, ey, ich bau mir jetzt irgendwie eine Software, die Mails passt oder oder my Mails zusammenbaut oder so, sorry, das macht man halt nicht. Ja, weil das gibt's halt schon. So, also da spielt Domain Driven Design nicht unbedingt eine Rolle. Ich persönlich bin son bisschen so Wellenbewegung. Ich habe so zwei, drei Jahre, da glaube ich, nee, das Mindset von Domain Driven Design ist für jeden sinnvoll und richtig und wichtig. Und dann schwingt es bei mir wieder so ein bisschen und ich denke, na, ich glaube, der Eric hat recht mit dem Domain Driven Design ist not for everyone. Ja. Also ich will es mal so sagen, vielleicht die gestellte Frage noch, der Versuch einer Antwort. Manchmal, also wenn ich in ein Team oder ein Unternehmen komme und ich gucke mir an, wie sehe ich die? Wie sehen die sich selbst? Und welche Probleme sehe ich? Dann ist manchmal irgendein Problem viel dringlicher als jetzt zu sagen, hey, lass uns Domain Driving Design einführen, ja. Insofern gibt es son Patentrezept nicht. Wie gesagt, ich finde im Grunde das Gedankengut, finde ich super schlau und auch nicht ausschließen, sondern sehr kompatibel mit Agilität und mit guter Software, nachhaltiger Software, Solid Prinzipien, was auch immer. Insofern fühlt sich das für mich gut an, diese Denkweisen überall mal mitzubringen und sage ich mal anzubieten. Wenn Du jetzt, wir sind wieder zurück bei dem Punkt, Du kannst Domain Driven Design nicht über die Entwicklung einführen. Also es kann Ich will damit nicht sagen, es wird nie funktionieren, aber es funktioniert nur dann, wenn der Rest des Unternehmens auch mitspielt. Wenn Du jetzt 'n Po hast, der sagt, interessiert mich nicht. Ich will mit dem ganzen Zeug nix zu tun haben. Ich schreib irgendwelche, ich hab irgendwelche Tickets entstehen. Also vielleicht mir schreibt ChatGPT meine Tickets aus irgendwelchen E-Mails, die ich von Fachanwendern bekommen habe und mehr interessiert mich nicht. Wann ist es fertig? Ja, da wirst Du kein DDD einführen können. So, da brauchen wir auch gar nicht drüber reden. Das
???: da
Stefan Priebsch: ist kein Ansatzpunkt. Da müssen schon alle wirklich eine Bereitschaft haben. Ich wollte noch eins sagen, weil Jan hat vorhin gesagt, dass dass ihr Spiele baut. Ich glaube, eine der Grundpfeiler von Domain Driven Design ist kollaboratives Modellieren, also eigentlich das, wo wir in der frühen Phase ein Modell entwerfen, ein Problem visualisieren oder 'n Prozess visualisieren und egal, mit welchem Tooling wir das tun, ob wir da jetzt Eventstorming machen oder Domain Storytelling oder Exempel Mapping oder User Story Mapping, whatever. Wichtig ist, dass wir es irgendwie visualisieren. Dass wir es greifbar machen, dass es nicht nur Worte sind, jemand, der toll erzählt, wie das alles sein soll. Es muss zwischen den Dingen im Kopf und der Software muss es sone Ebene geben. Manche Leute nennen das Dokumentation, ja, manche Leute kriegen gleich Angst, ich würde Big Design ab Front machen wollen, aber wir müssen irgendeine Form von Visualisierung, Darstellung haben, damit wir über etwas gemeinsam reden können und sagen, okay, ich sehe das Gleiche wie Du. Und wenn wir jetzt drüber reden und nicken, dann haben wir das gleiche Bild im Kopf, weil wenn wir nur über unsichtbare Dinge reden, dann haben wir unterschiedliche Bilder im Kopf und wir merken es nicht. So, das ist essenziell wichtig. Und ich glaube, dass 'n Computerspiel, Du würdest mir wahrscheinlich zustimmen, dass jedes gute Spiel, jetzt hoffe ich, dass ich mich nicht in Näesseln setze hier, das 'n gutes Spiel hat eine coole Story. Und was ist eine Story? Eine Story ist doch irgendwas, bevor wir Software geschrieben haben, existiert da etwas? Ob ich das jetzt aufgemalt habe oder noch nicht, aber es gibt da ein eine Idee, eine übergreifende Idee, die alle teilen und sagen, ja okay, wir wissen, worum es in dem Spiel geht, was die Story ist. Was ist die Journey? Was ist das Ziel? Was muss ich erreichen? Ja, und das ist für mich, glaube ich, schon was, was sehr nah an sonem Domain Driven Design Gedankengut ist, dass man sone Idee in Eric Evan nennt es in in der kondensierten Form System Matter vor. Was ist denn dein Elevator Pitch für das System, was wir hier bauen? Gib mir mal son Dreißig Sekunden Erklärung, was wir hier bauen. Und wenn Du es mir in dreißig Sekunden nicht erklären kannst, dann ist es offensichtlich etwas, was, na ja, wo man vielleicht mal noch näher drauf gucken muss. Ja. Und ich glaube, wenn Du so eine Story hier hast, dann bist Du schon sehr, sehr gut aufgestellt für dieses Thema Prolavouration, weil und wahrscheinlich auch Upicutous Language, weil welche Sprache benutzt ihr denn? Ihr redet doch von euren Spielfiguren, von euren Orten, von euren Gegenständen, die es da gibt. Diese Sprache wird ja von mehr oder weniger allen Beteiligten verwendet. Wunderschön wär's, wenn sich die auch noch 'n Code finden würde.
Jan: Ich glaub, das war 'n gutes Schlusswort. Auf jeden Fall. Wunderbar.
Stefan Priebsch: Aber Geht's vergeht.
Jan: Wir sind ja noch gar nicht am Schluss, weil wir haben ja hier noch Pixs of the day. Als Gast darf der Stefan natürlich anfangen. Stefan, was ist dein Pick of the day?
Stefan Priebsch: Mein Pick of the day? Ich habe vor Kurzem auf Netflix Chaos angeguckt, schreibt sich mit K.
???: Ja. Mhm.
Stefan Priebsch: Und das hat mich königlich amüsiert. Ich fand es großartig. Erstens mal Jeff Goldblum, den ja jeder Informatiker kennen muss als Schauspieler, ja, in der Hauptrolle als Zeus. Und diese Serie spielt im Prinzip mit dem Gedanken, dass die griechische Götterwelt Realität ist und zwar im Heute. Und was halt dann da so alles abgeht, ist, finde ich, super dargestellt, in in Supergeschichte verpackt, mit super Charakteren, saulustig, extrem unterhaltsam. Leider, Spoiler Alert, leider Also entweder gibt's eine zweite Staffel oder ich bin unglücklich, weil es leider nicht so endet, dass ich sag, yeah, jetzt hat 'n Abschluss, sondern es hat eher son Cliffhanger am Schluss.
Jan: Ja, son Netflixmodell.
???: Mal mal, wenn man
Stefan Priebsch: halt drauf einstellen, aber kann ich empfehlen, kann man sich anschauen, ist ist ein ist der Spaß.
Jan: Wunderbar. Cool. Danke. Hab ich auch schon viel Gutes von gehört. Ich hab's aber ehrlicherweise nur Ja, aber
Fabi: hab ich jetzt auf die Liste gepackt.
Jan: Wunderbar. Mein Pick of the day, ich hab ja hier sone Liste, wo ich immer, wenn ich über irgendwas im Internet stolper, schmeiß ich das da rein und immer, wenn ich 'n Pick of the day brauch, such ich da drin. Mhm. Und ich hab wollte nach Domain Drivn Design suchen, hab nur Design gesucht und hab einen bekommen, der schon länger in meiner Liste liegt, und zwar das Webdesignmuseum. Unter WWW Webdesignmuseum dot org, alles zusammen geschrieben, gibt es eine eine Liste von, also Hunderten irgendwie Webseiten von großen und bekannten Marken bis hin zu kleineren. Und man kann sich so anschauen, wie die so im Laufe der Jahre ausgesehen haben, die Webseiten. Ich hab hier einfach mal jetzt auf Google gedrückt. Das fängt an bei neunzehnhundertsiebenundneunzig, so kannte ich's ehrlicherweise noch nicht. Wenn man dann auf neunzehnhundertneunundneunzig drückt, so ja, das war auch mein erstes Google Erlebnis, da stand noch Beta unten drunter, da hat Google noch son Ausrufezeichen gehabt wie Yahoo. Da weiß man, wen sie so, ne, im Blick hatten und dann kann man sich so durch die Jahre da durchklicken und das, muss man sagen, da da hat man sich auch so son bisschen alt gefühlt.
???: Mhm.
Fabi: Und ich
Jan: hab mich ehrlicherweise, mein Papa ist son kompletter Autonerd und immer wenn wir so in 'nem Museum sind und irgendwie so die Autos zeigt so aus den Sechzigern und Siebzigern, ah, guck mal, guck mal, dieses Design und ne, so war das in meiner Jugend und bla, so hab ich mich das erste Mal gefühlt, als ich durch das Webdesignmuseum gekriegt hab, wo ich sagte, ah ja, früher die Tablels, ja, so war das hier auf diesen ganzen Webseiten und Du kannst dir nicht nur Webseiten angucken, wie es früher war, sondern Du kannst ja auch von von Apps haben sie das auch, allerdings 'n bisschen unvollständiger, weil's natürlich schwieriger ist, automatisch irgendwie alles mitzuverfassen. Du kannst ja auch alte Software angucken, so, ne, wie sah irgendwie Mozilla eins Punkt null aus, Visa Macromedia Flash, ja, früher aus. Ich hab
???: die cool.
Jan: Ich musste auch mal Flash programmieren früher, ja. Da war's noch nicht Adobe. So, wie wie sah Netzcape irgendwie früher aus? Wie sah irgendwie Frontpage aus? Oh Gott, jetzt Frontpages kennen unsere Zuhörer wahrscheinlich schon.
Stefan Priebsch: Das ist ja quasi jetzt, wo die Wayback Machine gerade down ist, ist das ja das perfekte Archiv von früher.
Jan: Ja, also als ich das erste Mal drüber gestolpert bin, war das wie so Wikipedia. Weißt Du, weißt Du, wenn Du anfängst einen Wikipedia Artikel zu lesen, auf einmal ist es vier Uhr nachts und Du bist bei dem Paarungsverhalten von südostasiatischen kleinen Pandas oder so was gelandet, ja, weil Du einfach von Artikel zu Artikel klickst.
Fabi: Ich mein, ist auch interessant, ich bin einfach mal eine Seite in der Historie durchzuklicken. Ich mach's grad bei der Apple Seiten, da hat man dann so das Gefühl so ab, also bis vor zweitausendsieben war's noch so, was, so sah das aus und ab zweitausendsieben sieht man eigentlich
Jan: Ihre Designsprache so, ja.
Fabi: Da ist, ist noch alles nur 'n bisschen moderner, aber davor war noch so, hä, was ist das? Und ab zweitausendsieben muss ich sagen, ja, so ist es eigentlich schon noch nur in Bizy Schöner.
???: Jetzt
Jan: müssen wir auf LinkedIn gucken.
Stefan Priebsch: Das wär jetzt interessant zu korrelieren, wann war Yoni Alfster? Ich glaube nämlich, das könnte ungefähr hinkommen, dass er da diese diese Designsprache, die er angeblich federführend mit entwickelt hat?
Fabi: Dass er da dazu kam. Ich weiß nicht, ich glaub, ich zwo achtzehn neunzehn ist er gegangen, ne, ist er zwanzig Uhr dazugekommen. Ich weiß gar nicht.
Jan: Ja, ja. Das, also Wie gesagt.
Stefan Priebsch: Muss ich mir angucken.
Fabi: Ja. Ist auch, also zwei sieben ist ja iPhone, ne, also da.
Jan: Ja. Ist mal ist mal 'n Klick wert auf jeden Fall. Fabi, was ist dein Pick?
Fabi: Ich hab eine Funktioniert vielleicht 'n bisschen, ist immer getrieben von dem, was man grade selbst son bisschen auf der Agenda hat. Ich hab plane noch mal 'n bisschen längeren Trip ins Ausland und hatte jetzt noch mal geguckt, okay, wie planen wir jetzt son bisschen für uns? Ist alles son bisschen loser geplant, wie planen wir eigentlich 'n Trip? Und da kam ich dann mal, die Funktion kann ich vorher gar nicht, kann Du vielleicht schon mit irgendwie auch mal im Camper ja unterwegs sein, Google My Maps.
???: Mhm.
Fabi: Also einfach eigene Maps auf Google anlegen, die man sozusagen wirklich dann auch sharen kann, einen Drive speichern kann, eigene Notiz speichern kann, eigene Notizen hinzufügen kann. Das Grundprinzip ist eine eigene Karte mit eigenen Pins, die die ist, mit eigenen Notizen hinzufügen kann, sodass dann von der Grundidee her, ich plane einfach, wo könnten wir potenziell hingehen, was sind alles irgendwie interessante Tipps? Hab alle auf einem Blick diese Informationen gesammelt, kann auch noch mit Fotos anreichern. Und fand das erst mal ganz cool, bin mal gespannt, ob ich's jetzt noch weiter sehr aktiv nutzen würde, aber ich kannte die Funktion voll gar nicht, dieses My Maps. Deswegen Google My Maps ist vielleicht für einige schon bekannt für mich noch sehr neu gewesen.
Stefan Priebsch: Das ist Wunderbar. Falls ich da noch was hinzufügen darf, so
???: nicht immer
Stefan Priebsch: ist, geht es auch bei Open Street Map.
???: Mhm.
Stefan Priebsch: Also wer sozusagen die freie Karte möchte, wo nicht Google drunter ist, kann man das glaube ich damit auch machen.
Fabi: Wunderbar. Eine gute Ergänzung.
Jan: Genau. Und damit sind wir auch schon fertig für heute. Eine Stunde, eine gute Stunde über Domain Driven Design. Die guten Seiten, die schlechten Seiten, die interessanten Seiten, die schwierigen Seiten. Alles dabei gewesen, glaube ich. Falls ihr noch Rückfragen, Anmerkungen, Kritik, Feedback, was auch immer habt, dann könnt ihr uns wie immer gerne unter Podcast at Programmier Punkt bar erreichen oder ihr schreibt uns auf Twitter, LinkedIn, Instagram, machst Du dann, Spotify, wo auch immer ihr uns grade findet und zuhört. Wir freuen uns immer, wann euch zu hören. Und ansonsten bleibt mir nur zu sagen, danke Fabi für die Zeit. Danke Stefan für die Zeit und den ganzen interessanten Input.
Stefan Priebsch: Danke für die Einladung.
Jan: Dann hören wir uns hier bald wieder. Tschau, tschau.
Fabi: Bis dann. Tschau. Tschau.

Domain-Driven Design mit Stefan Priebsch

Shownotes

Picks of the Day

Google Maps - My Maps

KAOS

Web Design Museum

Speaker Info

Stefan Priebsch

Verwandte Podcasts

Deep Dive 57 – DDD, Event Sourcing und CQRS mit Golo Roden von the native web