Transkript
Lucas:
Hallo und herzlich willkommen zu einer neuen Folge des INNOQ Podcast. Heute haben wir als Thema DDD und wie… ob es overrated ist oder nicht. Und dafür habe ich mir den Stefan eingeladen. Hallo Stefan!
Stefan:
Hallo Lucas!
Lucas:
Du hast ja vor einer Weile auf deinem persönlichen Blog einen Artikel geschrieben der hieß “DDD is overrated” und nachdem es da einige Reaktionen zu gab kam dann ein zweiter Blogpost: “Is Domain-driven Design overrated?”. Wie stehen denn diese zwei Blogposts in Verbindung?
Stefan:
Also eigentlich ist das der gleiche Blogpost. Nicht exakt der gleiche, aber fast der gleiche. In dem zweiten da gibt es ein paar zusätzliche Links und ein bisschen Ergänzungen. Vor allem hat sich aber der Titel geändert, wie du korrekt bemerkt hast. Ich hatte in dem ersten Blogpost “DDD is overrated” geschrieben, weil ich so ein bisschen natürlich auch weiß, dass sowas ein schöner clickbait title ist. Also Reaktionen auslöst und danach, als ich das gemacht habe, habe ich mich so ein bisschen geschämt. Eigentlich ist das ja blöd, weil das zu durchsichtig ist und jeder das auch merkt. Also wenn man den Blogpost liest, dann merkt man, dass das eigentlich nicht so richtig passt was im Titel steht, zu dem was dann im Text kommt. Weil ganz so negativ wie sich der Titel anhört sehe ich das gar nicht. Aber eben auch nicht uneingeschränkt positiv und deswegen habe ich es ein kleines bisschen entschärft. Und ich habe ganz schlimm Haue bekommen von unseren Marketing Kollegen, weil der Blogpost so populär war und ich den in meinem persönlichen Blog hatte: “Das ist echt blöd. Warum schreibst du das denn da?”. Und ehrlich gesagt weiß ich das gar nicht. Also normalerweise, wenn ich was in meinem persönlichen Blog schreibe, dann weil ich das Gefühl habe, das gehört nicht auf innoq.com. Aber der passt ja durchaus zu unseren sonstigen Themen und deswegen ist er jetzt eigentlich da, wo er hingehört, mit einem Titel, mit dem ich mich besser fühle und deswegen behaupte ich mal, dass das die kanonische Version des Blogposts ist.
Lucas:
Verstehe, alles klar! Ich meine DDD ist auf jeden Fall auch ein Thema, was INNOQ jetzt auch schon was länger relativ intensiv beschäftigt. Wir haben ja auch einige Kollegen und Kolleginnen, die da Schulungen zu geben beispielsweise und ja, im Allgemeinen auch dafür werben und das auch sehr intensiv einsetzen, würde ich jetzt mal sagen. Aber dein Blogpost ist ja auf Hacker News irgendwie sehr gut angekommen. Wahrscheinlich unter anderem wegen des clickbait titles und es ist ja sogar zu einer japanischen Übersetzung gekommen. Also irgendwie scheint das doch Resonanz ausgelöst zu haben. Warum denkst du spricht das so viele Leute an? Also ist das einfach, weil man ein Thema anspricht, was viele Leute gut finden und das dann kritisiert und das kommt bei vielen Leuten gut an? Oder siehst du da noch einen anderen Grund?
Stefan:
Also ich möchte ja glauben, also wer weiß, ob es stimmt oder nicht, aber ich möchte gerne glauben, dass es nicht nur der Titel ist, sondern eher der Inhalt, der die Leute anspricht. Und im Inhalt habe ich mich bemüht das schon ein bisschen ausgeglichener darzustellen. Weil die Kurzfassung wäre ja: Es ist viel Gutes am Domain-driven Design. Da sind viele gute Ideen drin, da sind viele Dinge, die man verfolgen sollte, aber man sollte das nicht religiös verklären. Es ist keinesfalls das Einzige was zum Ergebnis führt, es gibt viele andere Dinge. Es ist nichts aus dem Nichts entstanden, sondern baut auf vielen anderen Dingen auf. Und man kann auch erfolgreich Software entwerfen und umsetzen, wenn man gar nichts mit Domain-driven Design am Hut hat. Das ist eigentlich… Eigentlich sind es ja sehr, wie soll ich sagen…? Eigentlich sind das ja Allgemeinplätze. Aber trotzdem scheint es einen Nerv getroffen zu haben, weil es glaube ich tatsächlich ein Problem ist, nicht nur mit Domain-driven Design, können wir vielleicht am Ende nochmal drüber sprechen, aber eben auch da. Also es gibt so eine Bewegung, auch das ist immer gemein, wenn man sowas sagt, ohne spezifische Namen zu nennen. Ich habe aber das Gefühl, es gibt Leute, die das so uneingeschränkt toll finden und tatsächlich irgendwann auch das so verklären, dass das gar nichts mehr mit dem zu tun hat, was die Leute, die sich das ausgedacht haben, eigentlich damit bezweckt haben. Und das ist irgendwie schade. Es ist schade, wenn eine gute Idee dann auf einmal Gegenreaktion erzeugt, weil sie zu sehr gehypt wird. Das ist vielleicht so ein bisschen das, worauf es mir ankommt. Also ich finde viel gut dran, können wir sehr gerne drüber sprechen. Es gibt ein paar Dinge zu kritisieren, es gibt Dinge, die nicht immer gut sind, sondern nur manchmal und so sollte man bei allen Dingen eigentlich eine Bewertung anhand des Kontexts machen und nicht einfach irgendetwas nachplappern, was man irgendwo gelesen hat.
Lucas:
Ja, ich glaube das ist eigentlich eine ganz allgemeine Regel für gute Entscheidungsfindung. Auch ganz außerhalb vom DDD-Kontext. Okay, gut. Aber lass uns doch erstmal einen Schritt zurückgehen. Du hast bestimmt irgendwann das DDD-Buch gelesen. Wahrscheinlich auch schon etwas länger her. Was war denn da so dein Gedanke? Hast du gedacht: Eine revolutionäre Idee, das ändert alles! Oder was war deine Reaktion auf den Begriff?
Stefan:
Also, meine Reaktion als ich das ursprüngliche Buch gelesen habe war, ich glaube auf Englisch würde man sagen: “Duh!”. Also ja. Ich glaube ich war schon ein bisschen darauf vorbereitet. Also ich hatte von dem Buch vorher gehört, dann hatte ich es gelesen. Ich weiß gar nicht genau wann das war, aber ich glaube in den frühen 2000ern relativ kurz nachdem es rausgekommen ist. Und im Buch standen ganz, ganz viele Dinge drin, die ich, die meine Kolleginnen und Kollegen auch schon so praktiziert haben. Und dann wenn man so ein Buch liest und sich dann fragt: “Das ist doch alles so offensichtlich?”. Dann neigt man dazu das vielleicht abzuqualifizieren. Ich hatte das aber schon 1–2 Mal davor, deswegen hatte ich das schon verinnerlicht, dass das eigentlich ein gutes Zeichen ist. Also es ist gar nicht schlimm, wenn man ein Buch liest und das Gefühl hat: “Ja, das ist doch alles offensichtlich!”. Das ist oft ein Grund zu hinterfragen, ob das was man für offensichtlich hält, denn wirklich so offensichtlich ist oder ob man das nur, jetzt zum ersten Mal sozusagen externalisiert und formalisiert und verschriftlicht irgendwo wahrnimmt. Ich hatte das mit anderen Dingen auch, also… Was ist denn ein gutes Beispiel? Patterns of Enterprise Application Architecture von Martin Fowler ist so ein Ding, das fand ich eigentlich unendlich langweilig. Aber das ist ein wirklich gutes Buch! Also heute sind viele Dinge da drin vielleicht nicht mehr so relevant, aber zu dem Zeitpunkt war es ein wirklich gutes Buch. Weil er eben wirklich so aufgeschrieben hat, was so gängige Praxis ist, was wiederverwendbare Dinge sind. Genauso fand ich das bei Domain-driven Design auch. Und ich finde es ist immer eine gute Sache, wenn man Dinge, die vielleicht vermeintlich offensichtlich sind mit Namen belegt und in Kontext setzt und gegeneinander abgrenzt und relativ gut definiert. Und damit einfach eine gemeinsame Sprache findet, mit der man sich darüber unterhalten kann. Das empfinde ich als eine sehr positive Sache, einen positiven Beitrag und das hat Eric Evens find ich in dem Buch sehr gut gemacht und da habe ich überhaupt kein Problem mit. Also das finde ich eine gute Sache. Ich hatte mit einigen Facetten da drin, da war ich anderer Meinung oder hab die in ihrer Absolutheit nicht so gesehen. Aber das ist dann vielleicht eher so eine graduelle Geschichte. Ich hatte aber auch nicht das Gefühl und habe das auch heute bei vielen DDD-Practitionern, also bei vielen der Leute, unseren eigenen eingeschlossen, die damit unterwegs sind, habe ich auch gar nicht das Gefühl, dass die das so radikal und dogmatisch sehen. Das verwechselt man halt oft. Wenn jemand einen Vortrag hält und dabei eine bestimmte Sache erklärt, dann neigt man dazu diese Person mit diesen einen Ding zu assoziieren. Dann ist das eben oft so der “DDD-Mensch” oder… Und das ist oft gar nicht so. Also die Leute, die das machen, die erzählen ja in diesen Kontext gerade was da drüber, aber das ist ja nicht das Einzige auf der Welt, was sie tun. Und es ist insofern auch falsch anzunehmen, dass nur das richtig ist, was genau in diesen Kontext gesagt wurde. Gilt auch für ganz viele Dinge.
Lucas:
Ja. Auf jeden Fall! Ich meine es ist auch ein Vortrag, in dem man einfach alle zwei Minuten sagt “es kommt drauf an, es kommt drauf an”. Ist auch nicht so interessant, also…
Stefan:
Ist ein bisschen langweilig. Ja, genau.
Lucas:
Ja. Also stellt man es vielleicht ein bisschen anders da, als man es in der Praxis machen würde. Also würde man… In der Praxis würde man sagen: “Okay, an der Stelle weiche ich jetzt von diesem goldenen Pfad ab.” Und in einem Talk ist meistens einmal nicht die Zeit dafür auch immer auf jede Abweichung einzugehen und zum anderen versucht man ja auch irgendwie eine Nachricht zu transportieren und irgendwie etwas Klares zu präsentieren und nicht zu sehr das zu verwaschen. Und das ist natürlich ein Konflikt, in dem man immer ist als Vortragender, dass man versucht da irgendwie ein Balance zu finden zwischen zu viel “it depends” und zu wenig.
Stefan:
Ja. Das hat auch vielleicht ein bisschen was mit dem, ich glaube man nennt das das “Dreyfus model of learning”, das Dreyfus Lernmodell, aus dem sich auch ein Lehrmodell sozusagen ergibt, zu tun. Nämlich wenn man etwas lernt, wenn man gerade zum ersten Mal davon hört, wenn man sich zum ersten Mal damit beschäftigt oder man das erste Mal anwendet, dann ist es sehr gut sich relativ eng an die Regeln zu halten. Und je besser man etwas kennt und je mehr man damit versteht, umso mehr kann man Regeln auch mal ignorieren oder umgehen. Bis man irgendwann sozusagen verstanden hat, was die Intention des Ganzen ist und dann eben als Experte sozusagen nur noch das, als Expertin/Experte nur noch das anwendet, was eben im entsprechenden Kontext Sinn ergibt. Wenn man jetzt aber jemanden, der oder die gerade völlig am Anfang steht, wenn man die total verwirrt mit allen möglichen Expertenaussagen, dann bringt das auch keinen weiter. Also die Vereinfachung ist einfach ein Mittel des Lehrens, das ist total in Ordnung, muss man machen. Man muss sich halt auch irgendwann weiterentwickeln und weiter lernen, denke ich. Und das hat jeder bei anderen Themen, also ist nicht jeder Experte in allen. Ansonsten beobachtet man sich selbst ja auch bei ganz vielen Dingen.
Lucas:
Ja. Also bei mir war es so, ich habe das Buch so ungefähr so 2013 rum gelesen. Also schon so gute 10 Jahre nachdem es raus gekommen ist. Da war ich noch nicht bei INNOQ, da war ich bei meinem vorigen Arbeitgeber. Und mich hat damals das Buch, hat mir… Eigentlich die Sache, die in meinem Kopf vor allem hängen geblieben ist, ist die “Ubiquitous Language”. Also diese universelle Sprache oder allgegenwärtige Sprache. Und die hat mich damals auch dazu bewogen dazu einen Talk zu halten, weil das was ich auch mit daraus gelesen hatte, damals, war: Ich möchte irgendwie eine Sprache haben, die alle verstehen. Nicht nur die ITler, sondern auch die Fachleute. Und gerade das, betrifft das auch solche Sachen wie jetzt Datenbanktabellen und Joins und so weiter. Das sind so Sachen mit denen Fachleute, habe ich zumindest damals gedacht, wenig anfangen können und deswegen hatte ich da einen Talk darüber gehalten, dass ich glaube, dass Graphendatenbanken einem dabei helfen, eine Sprache zu finden, die alle tatsächlich verstehen. Weil das einfach ein Modell ist, was jeder irgendwie auf die Tafel malen kann und relativ einfach versteht. Und für mich war damals das wirklich das große Ding, was ich aus dem Buch mitgenommen habe. Hast du irgendwas, wo du sagst so, neben den Sachen, wo du sagst: “Ja, das wusste ich schon.” Irgendwas wo du gesagt hast: “Ja, das habe ich auch mitgenommen aus dem Buch.” Oder war da wirklich dann mehr so die…
Stefan:
Also für mich waren es so 2–3 Dinge. Das eine war ein starkes Gewicht auf Code als Mittel zum Ausdruck von Fachlichkeit. Das klingt total banal und offensichtlich, aber es war eben zu einer Zeit, wo ich auch sehr, sehr viel mit zum Beispiel modellgetriebener Softwareentwicklung gemacht habe. Da war das ein bisschen wie so ein frischer Wind, der sagte: “Ja, das ist alles nett mit Modellen zu arbeiten, aber Modelle müssen sich nicht in Diagrammen wiederspiegeln, müssen sich nicht in irgendwelchen externen Notationen wiederspiegeln, Modelle können sich und sollten sich auch direkt im Code wiederspiegeln.” Denn Code sollte nicht nur ein rein technisches Artefakt sein, das nur Entwickler/Entwicklerinnen angucken, verstehen können. Im Idealfall ist der Code in einer Sprache geschrieben, so dass man… so dass Fachanwender den nicht schreiben, aber zumindest darüber reflektieren können, wenn man ihnen das erklärt oder wenn sie das lesen und so. Das was man da hat in gewisser Weise nah an dem fachlichen Vokabular… Vokabular der fachlichen Domäne dran ist. Wie gesagt, eigentlich ein offensichtliches Ding und ich glaube das ist so etwas, was zum Beispiel in bestimmten Communities, wie zum Beispiel in der Smalltalk Community immer ein Teil des Denkens war. Ich baue im Prinzip meine Klassen, meine Objektstrukturen so auf, dass wenn ich Code mit Hilfe dieser Objektstruktur hinschreibe, der sich so liest als hätte ich ein Statement, eine Aussage über die fachliche Domäne getroffen. Das ist insofern auch nicht was Neues, aber es hat das sozusagen wieder so ein bisschen was in den Mittelpunkt gerückt in einer Community, die zu diesem… gerade spezifisch in der Java Community, die zu diesem Zeitpunkt sich sehr, sehr viel mit Boilerplate beschäftigt hat und sehr, sehr viel mit Code, der ganz viel Komplexität in einer technischen Dimension hatte und Fachlichkeit vielleicht so ein bisschen unterrepräsentiert hatte. Also diejenigen die sich so an eine J2EE Zeit erinnern, die wissen wahrscheinlich worauf ich da anspiele. Und das war für mich so ein Aha-Erlebnis, wir haben immer versucht die Fachlichkeit in Modellen außerhalb des Codes oder sehr viel in Modellen außerhalb des Codes abzubilden und dann viel über Codegenerierung den technischen Code zu erzeugen. Und hier kam sozusagen, wie eigentlich die alte offensichtliche Idee nochmal stark betont nochmal raus, wir machen das lieber direkt im Code auf den es uns ankommt, damit es eben wirklich ein Modell ist, das im Code ausdrückt, was die Domäne wiederspiegelt. Also das war eben wirklich diese fachliche Sprache hat, also Nummer eins. Nummer zwei war etwas, was wir sehr, sehr lang, auch in diesen Kontext schon sehr lange auch betrieben haben. Oder ein Punkt, der gleich zu einer meiner Kritikpunkte dann wird. Das war die Idee von Stereotypisierung. Das heißt nicht so im Buch, aber eigentlich ist es die Idee dieser taktischen Patterns, die da drin sind. Also da gibt es zum Beispiel Dinge wie Entities und Aggregates und Services und Value Objects und all solche… Das sind im Prinzip Namen für Muster, die nützlich sind, die sinnvoll sind, die zu dem Zeitpunkt zum Teil bekannt waren, zum Teil hat man vielleicht einen anderen Namen verwendet. Zum Beispiel Aggregate habe ich glaube ich vorher noch nicht gesehen, das kenne ich aus dem Buch. Und das sind gültige und sinnvolle Muster. Und die Idee, dass man solche Dinge benennt damit man in der Beschreibung der Architektur mit diesen Begriffen arbeiten kann, das halte ich für eine außerordentlich gute Idee und hielt ich auch damals schon für eine gute Idee. Passt auch wieder zu dieser modellbetriebenen Software, muss nicht zwingend damit etwas zu tun haben, aber passt halt damit auch ganz gut. Weil ich dann sagen konnte: Für diese Art von Muster… Also wenn ich folgende Sache im Modell ausdrücke, ja, ich habe hier drei Entitäten und davor sitzt ein Service und dazwischen werden Value Objects ausgetauscht, dann habe ich damit praktisch in meinem Modell, habe ich sozusagen Typen benutzt und kann dann eben in der Codegenerierung einen spezifischen Code für Entities, Value Objects und Services generieren. Das war so damals immer unsere Motivation, aber auch wenn man keinen Code generiert, weil man das doof findet, ist es trotzdem gut, wenn man darüber sprechen kann. Wenn wir beide uns unterhalten, und ich sage dir: “Ja, ich habe mir das angeguckt. Das sind drei Services, fünf Entities, die ich da bauen muss.” Dann hast du ein Gefühl von Komplexität, die da drinsteckt und weißt auch, was ich meine. Weil wir sozusagen Jargon, eine Pattern Language entwickeln, in der wir uns unterhalten können. Das fand ich…
Lucas:
Ja, ich glaube… bei Eric Evans waren das glaube ich die Building Blocks.
Stefan:
Building Blocks, ja. Genau, was mir gut gefällt, das ist jetzt vielleicht ein bisschen esoterisch. Was mir extrem gut gefällt ist dieser Gedanke, also sowas zu machen. Ich finde auch die Muster, die da drin sind, die Building Blocks, die da drin sind, total okay. Was mich unendlich nervt ist, wenn Leute glauben das ist die vollständige Liste. Also: “Das sind die richtigen Building Blocks. Die Building Blocks musst du benutzen, um Software zu bauen.” Quatsch! Das ist ein Startpunkt, damit kannst du loslegen, wenn du nichts hast. Die sind vielleicht auch okay, die reichen dir vielleicht auch aus, aber das ist total okay fünf andere Building Blocks oder Stereotypes zu entwickeln. Oder drei davon zu ignorieren oder Aggregates bescheuert finden und was anderes zu machen. Das kommt doch auf die konkrete Architektur an von der ich da spreche. Und ehrlich gesagt bin ich mir sicher, dass Eric Evans das ganz genau so sieht. Das ist überhaupt nicht so, dass der glaubt, dass das die einzig richtigen Patterns sind, aber manche Leute, die das zu wörtlich interpretieren glauben das und glauben eine richtig gute Architektur ist es nur, wenn es Aggregates benutzt. Dann wird lange darüber diskutiert, wann ein Aggregate ein gutes Aggregate ist und wann nicht. Das… Also es gibt nicht richtig und falsch in dieser Sicht. Es gibt das, was für mich funktioniert und das für dich funktioniert. Das muss nicht das gleiche sein. Wir können uns darüber austauschen, dann kann ich dir von meinen positiven Erfahrungen berichten mit meiner Art und Weise sowas zu bauen. Dann kannst du das annehmen oder auch nicht, aber es gibt keinen Anspruch auf Wahrheit. Weder bei Eric Evans noch bei irgendwem, weil das immer Kontext abhängig ist. Das ist also sozusagen der zweite Teil. Also da habe ich schon das eine oder andere Problem. Das dritte ist, was ich eigentlich das Interessante am Buch finde, das ist der strategische Teil. Der kommt ja blöderweise als zweites und nicht als erstes im Buch. Das hat Eric Evans ja auch immer gesagt, dass er das im Nachhinein bereut, dass er das so rum gemacht hat und nicht andersrum. Ich finde das auch, weil ich glaube, dass das strategische viel, viel langlebiger ist als dieses taktische. Und das strategische ist auch aus meiner Sicht das, was dem Buch zu so einer Popularitätsrenaissance verholfen hat. Es ist wie gesagt ein altes Buch, für unsere Zeit ist es ja quasi antik und auf einmal ist das immer in aller Munde, poppt doch noch immer auf. Und der Grund dafür waren aus meiner Sicht Microservice-Architekturen bei denen alle händeringend nach Hilfeleistungen, nach Hilfestellungen zum Thema Modularisierung gesucht haben und sie haben sie da drin gefunden. Also im Domain-driven Design gibt es dieses Konzept von Bounded Contexts, ganz vereinfacht gesagt: Von der Idee von Geltungsbereichen, also abgegrenzten Geltungsbereichen für Teile dieser Ubiquitous Language. Vereinfacht gesagt ein Konto. Der Begriff Konto bedeutet vielleicht im Abrechnungskontext etwas anderes, als der Begriff Konto im Pensionierungskontext oder Logistikkontext bedeutet. Ist das gleiche Wort, bedeutet aber unterschiedliche Dinge. Und sich darüber klar zu werden, zu modularisieren und diese autonomen abgegrenzten Geltungsbereiche zu haben, ist einfach ein extrem guter Gedanke. Den hat Eric Evans auch nicht erfunden, der hat auch vorher schon so Software designed. Aber ich fand es ganz toll, dass es da jetzt einen schönen Begriff für gab, worauf man verweisen konnte und das erklären konnte. Und das ist für mich der größte Beitrag von Domain-driven Design. Dabei geholfen zu haben diese Diskussion hoffähig zu machen sozusagen. Also das hätten wir auch ohne Domain-driven Design gekonnt, wir hätten es nicht Bounded Contexts nennen müssen, aber es ist positiv und da nützt der Hype einen sozusagen, ja. Also man kann das positiv Instrumentalisieren, um diese gute Sache zu machen und dann nennen wir das von mir aus auch gerne Bounded Contexts. Es gibt auch ganz viele ganz kluge Leute, die sich in dieser Domain-driven Design Community bewegen und sich genau damit beschäftigen. Wie strukturiere ich Software im Großen? Wie strukturiere ich große Softwaresysteme so, dass zum Beispiel Teams parallel daran entwickeln können? Das finde ich eine tolle Sache an Domain-driven Design und da habe ich eigentlich gar kein Problem mit. Außer vielleicht manchmal, ich war auch schon in Diskussionen, es gibt in Domain-driven Design dieses Patterns, um darzustellen wie Bounded Contexts voneinander abhängen und Strategien um die Kopplung zu verringen und zu mangen und so diese… Also wenn verschiedene Teams miteinander kollaborieren, dann gibt es so Strategien und auch da war ich schon in relativ unsäglichen Diskussionen, wo ich das Gefühl hatte, es wird nicht über eine gute Lösung diskutiert, sondern es wird darüber diskutiert, ob das Muster X aus dem Domain-driven Design Buch nun das bedeutet oder das bedeutet. Das ist so ein bisschen für mich wie Bibelverse interpretieren. Das kann man schon machen, also wenn man das als Berufszweig gewählt hat, dann ist das total okay, wenn man sich darüber… wenn man sich gegenseitig darüber zu belegen versucht, ob das oder das die Bedeutung eines Wortes in diesem Kontext ist. Aber ehrlich gesagt für das Bauen von Systemen ist das vollständig irrelevant. Die kann man auch führen, aber ich finde das nicht die wichtige Diskussion. Ich finde es wichtiger zu diskutieren: Was machen wir denn in welcher Situation? Was funktioniert wann gut? Was sind die Einflussfaktoren? Also ich bin für ordentliche Terminologie, ich bin aber auch für begrenzten Zeitaufwand für Terminologie-Diskussionen.
Lucas:
Ich glaube das ist ja auch so eine Sache, also ich finde, du hast ja eben auch Martin Fowler erwähnt mit seinem Buch Pattern of Enterprise Application Architecture. Das ist ja meiner Beobachtung nach immer eigentlich die Stärke von beispielsweise Martin Fowler gewesen, einfach herauszuarbeiten was gibt es und lass uns diesen Dingen mal einen Namen geben, damit wir nicht so viel Zeit darauf verwenden das immer wieder neu zu definieren. Was in der Praxis leider immer wieder zu dem Problem führt, dass man sehr viel darüber streitet, was jetzt genau die Definition war und ob es jetzt ein X oder ein Y ist. Weil in dem Buch hat er doch das und das gesagt und so weiter. Und was uns dann ja eigentlich schlussendlich wieder nicht so richtig weiterhilft. Aber ein anderes Beispiel wären jetzt zum Beispiel diese Refactoring Begriffe, also jedes Refactoring hat irgendwie einen Namen. Das ist ja auch sehr hilfreich, aber ich meine das dahinterstehende Konzept, dass es kleine Änderungen am Code gibt, die nichts an der Semantik ändern, aber uns zu einem bestimmten Ziel führen können, das ist ja das wertvolle daran. Und diese Wortklauberei ist ja meistens doch eher eine Zeitverschwendung irgendwie im Projektalltag.
Stefan:
Ja. Also ich würde das… Ich glaube es gibt gute und schlechte Beispiele dafür. Ich glaube Refactoring ist tatsächlich ein sehr positives Beispiel, weil… Also erstens finde ich das Konzept gut. Also ich finde das ist eine coole Idee. Also ich möchte mich sozusagen fokussieren, entweder ich mache Refactoring oder ich mache eine funktionale Ergänzung. Wenn ich Refactoring mache, dann müssen die Tests danach immer noch durchlaufen. Also das finde ich eine nette Idee, so ein bisschen wie Hüte aufsetzen zu verschiedenen Zeiten. Diesen Sachen einen Namen zu geben ist auch eine gute Idee, ich finde auch, dass das zum richtigen Zeitpunkt passiert ist. Und bestehende nützliche Dinge sozusagen, also die man schon kannte, aber irgendwie denen einen Namen gegeben hat, was dann wiederum dazu führte, dass Tools… also gab es auch vorher, es gab auch vorher schon Refactoring Browser in SmallTalk. Kommt glaube ich die Idee auch her, aber es wurde danach Mainstream. Ich meine IntelliJ wäre das erste in der Java Welt gewesen, das sowas gemacht hätte. Hat mittlerweile aber glaube ich jede IDE für jede Sprache in jeder Plattform. Außer vielleicht Go, ich glaube da gibt es sowas nicht. Wie auch immer. Das war jetzt unter uns. Aber egal. Die Tools haben dann sozusagen einfach diesen Katalog gehabt und hatten sozusagen ein gut gefülltes Backlog von coolen Ideen, die man nehmen kann, um sowas umzusetzen. Was dann wieder dazu geführt hat, dass es weitere gab. Das fand ich ein positives Ding. Da hat das dazu geführt, dass man diese Begriffe nutzt und dass das die Tools verbessert hat und dass wir heute sowas haben, finde ich gut. Es gibt andere Stellen, da bin ich mir nicht so ganz sicher. Es gibt zum Beispiel von Martin Fowler, gibt es einen sehr populären Microservices Artikel, der finde ich so ein bisschen aus der Art springt, weil er nicht so exakt definiert, wie man sich das wünschen würde finde ich. Dann ist die Frage, ob das so viel nützt. Weil der führt, genau zu dem was du gesagt hast, der führt zu diesen vielen Interpretationen: Was ist denn jetzt ein Microservice und was nicht? Muss der klein sein oder nicht? Und wie klein? Und das sind so, auch so relativ mühselige Diskussionen, die man da führen kann. Können wir bei Gelegenheit auch mal diskutieren, aber ja. Vom Grundsatz her, wir sind ja beim Thema Domain-driven Design und dem Wert da gestartet und meine positive Assoziation und zu der stehe ich weiterhin, es hat nützliche Dinge dazu beigetragen, es sind gute Sachen drinnen. Es ist halt, gerade wenn man es zu wörtlich interpretiert und auch den Konzepten da drin zu, ja, zu engstirnig folgt, das kann einen echt wehtun.
Lucas:
Ja, da stimme ich dir zu! Also du hast ja auch schon so als einen Bereich, der dir gut gefällt, so dass es halt so was wie einen Geltungsbereich für Begriffe gibt. Das finde ich auch sehr positiv und eine Sache, die ich auch als ein sehr wertvolles Konzept sehe ist diese Art von Contextmapping. Also welche Beziehungen bestehen zwischen Geltungsbereichen? Das finde ich auch tatsächlich etwas nützliches in der Systemmodellierung. Und auch da gibt es ja sonst verschiedene Muster, wie jetzt irgendwie upstream, downstream, mutual dependence und so weiter. Und ich glaube auch da stimmt es wieder, dass es gut ist, dass es Begriffe dafür gibt, damit man einfach mal schauen kann: Passt einer der Begriffe? Aber auch da würde ich das so sehen wie du, zu sagen: Ist das die vollständige Liste oder gibt es vielleicht noch mehr? Und sich nicht auf diese Liste zu beschränken, sondern vielleicht auch zu sagen: Das ist unser Start-Set und eventuell gibt es einfach noch mehr Arten von Beziehungen zwischen Bounded Contexts oder Geltungsbereichen oder wie auch immer man das sagen möchte.
Stefan:
Sehr guter Punkt, weil ich glaube gerade da, da muss es einfach… Es muss in jeder Organisation mehr als diese geben. Also zumindest in jeder Organisation mit relevanter Größe. Weil es so viele unterschiedliche komplizierte Arten von Beziehungen gibt, mit denen man da umgeht. Klar, guter Startpunkt, man kann damit anfangen und Dinge visualisieren. Mann muss sich sehr genau überlegen, visualisiert man gerade “ist”-Zustand oder “soll”-Zustand? Das ist auch immer so eine längliche Diskussion. Und genau, also bin ich völlig deiner Meinung, da ist das ein guter Startpunkt. Ist eine gute Sache, dass man überhaupt darüber diskutiert, dass man das thematisiert, dass man überhaupt Begriffe hat, mit denen man anfangen kann. Und auch da würde ich mich nicht künstlich begrenzen auf das was drinsteht. Ich würde auf der anderen Seite auch nicht wild neuerfinden, weil dann reduziert das ja auch wieder den Wert. Wenn ich also diese Begriffe… Wenn ich der Einzige auf der Welt bin, der diese Begriffe benutzt, dann hilft mir das auch nicht, dass ich die gerade erfunden haben. Also dann muss ich zumindest andere Leute haben, die die Begriffe auch verstehen, wenigstens innerhalb meines Kontexts. Aber das ist ja immer so eine Gradwanderung, dazwischen bestehendes zu verwenden oder neues zu erfinden.
Lucas:
Definitiv! Ich meine, ich glaube, dass man in einer guten Dokumentation auch die Teile von den Beziehungen, die schon von Eric Evans oder.. wie heißt der andere noch? Vaughn Vernon, definiert sind, dass man die dann trotzdem auch nochmal in eigenen Worten beschreiben sollte. Einfach damit man nicht sagt so: Hier sprechen wir jetzt über upstream/downstream, da weiß ja jeder was gemeint ist. Sondern einfach, dass in das Vokabular einzubringen, dass wir das in der Architektur unseres Systems verwenden. Und weil sonst ist das ja keine ubiquitous language, wenn wir es nicht schaffen solche Begriffe auch in unseren Kontext einfach zu etablieren, meiner Meinung nach.
Stefan:
Ist schon ganz schon Meta jetzt. Weil jetzt sprechen wir von ubiquitous language der Designer, nicht der ubiquitous language der Fachdomäne. Also auf die Metaebene gewechselt.
Lucas:
Das stimmt.
Stefan:
Ja, das ist immer das schöne, wenn man auf Metaebene gleich noch anfängt.
Lucas:
Genau. Aber ich wollte… Ja?
Stefan:
Sorry, einen Punkt wollte ich noch aufnehmen, weil du den gerade so schön gesagt hast. Ich wollte den auch nochmal unterstreichen mit der ubiquitous language. Du hattest ja gesagt, dass war für dich so eine Erkenntnis. Das finde ich auch nochmal einen ganz wichtigen Punkt, würde ich auch nochmal zustimmen wollen explizit. Weil das glaube ich auch vielen Leuten die Augen geöffnet hat zu unterschiedlichen Zeitpunkten, dass es keine gute Idee ist diese künstlichen Grenzen da einzubauen. Also so künstliche eigene Begriffe zu erfinden, gerade um sich abzukapseln. Das finde ich ist so eine typische Jugendsünde, die man macht, wenn man noch relativ unerfahren ist. Dann erfinde man irgendwie eigene Abstraktionen, eigene Dinge, weil man irgendwie glaubt, dass man das in ein besseres konzeptionelles Modell reinbekommt als die Fachseite, womit man oft falsch liegt. Zumindest wenn man das nicht mit der Fachseite diskutiert. Also sich ein eigenes Modell auszudenken und das dann mit der Fachseite zu reflektieren. Also sagen wir mal: Stimmt das? Ist das nicht vielleicht so? Das kann eine sehr gute Idee sein. Aber sich was Eigenes auszudenken und dann nicht zu teilen ist keine gute Idee und… Genau.
Lucas:
Ja, für mich war das auch auf jeden Fall so ein Punkt, einfach festzustellen, dass auch ein Algorithmus ja von jemanden definiert werden kann, der kein IT-Mensch ist, sondern das ein Algorithmus ja eigentlich auch eine Fachlichkeit abbildet und dass man, wenn man das gemeinsam durchspricht wahrscheinlich auch zu einer besseren Implementierung kommt. Wenn man die Implementierung gemeinsam durchgesprochen hat, weil wir ein gemeinsames Verständnis davon haben, was es für Dinge im System gibt. Zumindest jetzt mal die fachlichen Dinge und nicht für die… keine Ahnung jetzt irgendwelche Caching-Strategien oder was auch immer. Obwohl die ja auch fachlich sind, aber sonst kommen wir ganz vom Thema ab. Ich wollte nochmal ganz kurz auf die Building Blocks eingehen. Was ich damals kurios fand als ich das Buch gelesen habe war, wenn ich mich richtig erinnere, gibt es glaube ich sechs Stück in dem Buch: Aggregates, Repositories, Entities, Aggregates und Value Objects, also hatte ich in meinem Kopf als eine Gruppe gesehen. Und dann gibt es irgendwie noch die Repositories und Factories und Services. Ich persönlich hatte relativ viel Wert daraus gezogen, dass es Entities und Value Objects gibt, weil ich das in der Datenmodellierung tatsächlich sehr praktisch fand. Ich habe mich damals damit beschäftigt wie, wenn ich jetzt eine Datenbank habe, bei der ich eben nicht mehr Tabellen habe, sondern Dokumente in denen ich auch Nesting haben kann, wie entscheide ich ob ich etwas einbinde oder wie ich etwas… ob ich tatsächlich eine Referenz zu den anderen Objekt mache? Und mir hat das da tatsächlich die Augen geöffnet zu sagen: "Ah, okay! Die Value Objects, die darf ich in meine Entity einbetten. Dann wird es vielleicht zu einem Aggregate, aber das war mir tatsächlich relativ egal. Aber wenn das andere eine Entity ist, dann darf ich sie eben nicht einbetten, sondern ich muss sie referenzieren. Und was mich damals total irritiert hat war, dass dann noch über Repositories und Factories und so gesprochen wurde, die für mich irgendwie, ja das… Gut, das sind halt so Pattern, die sind manchmal praktisch, manchmal nicht. Aber dass die irgendwie auf die selbe Ebene gezogen wurden, das hat mich glaube ich damals sehr irritiert an dem Buch. Das die zusammen in einem Kapitel standen. Ich weiß auch nicht.
Stefan:
Also ich hatte das Gefühl… Also wir haben damals in verschiedenen Projekten, verschiedene solche… jetzt sage ich doch das Wort, “Metamodelle” gehabt. Also da gab es zum Beispiel Projekte, da gab es irgendwie… da gab es Business Objects und die sind dann… kennen vielleicht, alte IBMler kennen das noch “EGO, PGO, AGO”, Entity-Geschäftsobjekte, Prozess-Geschäftsobjekte und Aktivitäts-Geschäftsobjekte.
Lucas:
Also ich kenne es nicht.
Stefan:
Das ist nur für ganz, ganz alte Zuhörer und Zuhörerinnen dieses Podcast, die sich an das noch erinnern. Aber das zum Beispiel findest du im deutschsprachigen Raum in ganz vielen Projekten aus dem Ende der 90er, Anfang der 2000er, weil da irgendwie dieselben Consultants von einem Projekt zum nächsten gezogen sind und diese Idee mitgenommen haben. Und sie ist immer etwas anders ausgeprägt, da gibt es immer noch andere Layering-Strukturen und noch ein paar andere extra Stereotypen dazu. Und das hat sich zum Teil weiterentwickelt. Man hat in einem Projekt was ausprobiert, hat gemerkt: Okay, war in der Beziehung gut, in der Beziehung war es bescheuert. Aber in dem Projekt konnte man es nicht mehr ändern. Also konnte man im nächsten Projekt das nächste ausprobieren und dann im übernächsten das übernächste und wo weiter. Und ich habe das Gefühl bei Eric Evans, das ist auch ein Consultant, zumindest war er damals ein Consultant, der Software entwickelt hat, wie wir alle in Projekten und der hat einfach das was in dem Moment gerade das war, was sein zu diesem Zeitpunkt bester Snapshot war, das hat er da reingeschrieben. Das ein bisschen zufällig und willkürlich. Das ist gar nicht schlimm, das ist ganz okay. Das bringt mich wieder zurück zu dem Punkt, das ist aber nicht okay das jetzt irgendwie zum Gospel, zum Evangelium zu erheben. Das ist es eben nicht. Und das ist vermute ich einfach der Grund, warum diese Dinge da drin sind. Also in der spezifischen Architektur, aus der das stammt, da gab es dann eben Repositories und Factories, um die Entities von der Datenbank abzukapseln, beziehungsweise deren Erzeugung zu steuern. Das war eben so und deswegen steht das da alles flat in dieser einen Liste drinnen. In einer anderen Architektur wären es vielleicht andere Sachen gewesen, da hätte es noch ein paar Dinge mehr gegeben. Irgendwelche Fassaden oder Cluster oder Repository Manager oder was weiß ich was für Dinge. Ja, das ist alle in Ordnung. Das ist halt dann eben das, womit vielleicht die 30, 50, 100 Entwickler und Entwicklerinnen in diesem Projekt sich darüber verständigt haben, was ihre Architektur ist.
Lucas:
Ja, ich meine das unterstreicht ja eigentlich nur den Punkt, dass man das irgendwie als ein Starts-Set sehen kann. Aber für mich wie gesagt waren halt diese Value… Also das Konzept von Value Objects und Entities, das fand ich tatsächlich wichtig für meine Datenmodellierung. Das hat mir weitergeholfen. Aber wir sind ja auch schon so ein bisschen an dem Punkt, wo… Ich habe ja keinen Blogpost geschrieben, aber wenn ich einen schreiben würde über DDD, dann würde ich vermutlichen einen darüber schreiben was mich daran stört. Und zwar dass es diesen Fokus gibt, darauf die Geschäftslogik von allen anderen zu trennen. Das ist irgendwie sowas was vielen von den Leuten, die sich damit beschäftigen, sagen das. Also beispielsweise auch in unserem Primer dazu steht drin: “Isoliere die Umsetzung des Domainmodels und der Geschäftslogik und eliminiere alle Abhängigkeiten zur Infrastruktur, Benutzeroberfläche und Anwendungslogik, die keine Geschäftslogik ist.” Und ich frage mich bis heute, ob das eine gute Idee ist. Ich verstehe warum man das tut und ich verstehe auch, dass zum Beispiel die Repositories ein Weg sind das zu tun für die Datenbank beispielsweise, aber ich weiß nicht, ob das eine gute Idee ist. Wie stehst du denn zu diesem Satz?
Stefan:
Also die Kernidee, die da drinsteckt, ist ja, dass diese Implementierung dieses Modells eben auch genau das sein soll. Die soll ein Domainmodell implementieren und nicht sich mit Infrastrukturzeug beschäftigen. Und ich glaube die Idee dahinter, die Begründung dafür ist, dass das das ist, was langfristigen Wert hat. Andere Dinge kommen und gehen, ändern sich, aber das bleibt eben. Das ist meine ubiquitous language, das kapselt letztendlich ja das was in meinem Geschäft, was die Essenz meines Geschäfts ist. Und deswegen, wenn ich das von dem anderen Zeug isoliert habe, dann kann es eben lange leben, an vielen Stellen wiederverwendet werden, es ist in Prinzip… ich habe sozusagen technischen Code und fachlichen Code nicht miteinander vermixt und damit auch nicht deren Lebenszyklen miteinander vermixt. Das ist glaube ich die Motivation von dem Ganzen. Und ich glaube die Frage, ob das eine gute Idee ist oder eine schlechte Idee ist lässt sich so nicht beantworten, weil dafür die Standard-Consultant-Aussage gilt: “Kommt halt drauf an.” Also ich glaube das ergibt Sinn, wenn das komplexe Fachlogik ist, die auch wirklich zum größten Teil da drin besteht. Also wenn ich das… Wenn ich vielleicht ein Rechenmodell, einen komplexen Tarifrechner oder so, also wirklich echte, interessante, spannende, komplexe Fachlogik, wenn ich die darin umsetzte, dann ist das für mich ein gutes Modell. Wenn das selbst so anämisch ist, dass da gar nichts interessantes drinsteht, dann habe ich mir keinen Gefallen getan. Also wenn sozusagen alles was interessant ist sich im UI-Teil davor oder in der Datenbank direkt dahinter oder in der Integration der Umsysteme befindet, dann ist das was für mein Domainmodell dann noch übrig bleibt total öde und langweilig. Und es kann auf der anderen Seite ja, das haben wir beide auch schonmal diskutiert, das kann auch zu unangenehmen Performanceproblemen führen. Also wenn ich jetzt sklavisch dieser Regel folge und sage: Ich muss das immer so machen. Dann nutze ich vielleicht auch Features außen rum nicht so wie ich sie nutzen könnte. Ich nutze vielleicht mein HTTP-Caching nicht, das ich für mein RESTful Web Service verwenden könnte oder ich nutze meine Joins in meiner relationalen Datenbank nicht mit denen ich alles hunderttausendmal schneller erledigen könnte in Memory mit meinen Java Objekten oder meinen .NET Objekten zu machen. Das ist auch nicht immer wahr oder falsch, es kommt halt ganz drauf an. Und eigentlich glaube ich, dass die richtigere Interpretation von Domain-driven Design wäre, wenn das richtig rum geschrieben… ja, ich gehe nochmal einen Schritt zurück. Wie ich mir gewünscht hätte, wie er das Buch geschrieben hätte, jetzt mit Hindsight ist das ja immer leicht. Dann hätte er erst den strategischen Teil vorgeschoben und dann hätte er diesen taktischen Teil als ein Beispiel genommen. Also strategischer Teil ist, wir teilen das auf, wir machen diese Bounded Contexts, wir machen diese Einzelteile. Und hier ist eine Art und Weise wie man in so einen Teilbereich Dinge umsetzen könnte und es kann auch viele kluge andere Arten geben, wie man sowas macht. Aber hier ist mal ein Beispiel, falls ihr einen Startpunkt braucht. Das hätte mir gut gefallen. Weil das was er vorschlägt, passt manchmal. Aber wenn ich mir jetzt vorstelle ich habe so einen komplexen Systemkontext, dann gibt es vielleicht auch einen Teil, den setzt ich am besten um, indem ich ganz, ganz viel hardcore Datenbankprogrammierung mache. Und einen anderen Teil setzte ich um indem ich ganz, ganz viel Frontend Geschichten mache, weil das Datenmodell ist banal, die Geschäftslogik auf dem Server ist banal, die eigentliche Musik spielt im Frontend, in einer nativen App oder fancy Web App, was weiß ich. Diese Entscheidung, die lässt sich eben nicht ohne Kontext treffen und die lässt sich sozusagen nicht ohne Bounded Context treffen. Die lässt sich nicht treffen, ohne zu wissen über welchen Teilbereich ich hier gerade spreche. Ein Beispiel wäre sowas wie, ein großes E-Commerce System hat vielleicht einen Teil in dem baue ich die… da ist ein Bounded Context, da wird Produktlogik gebaut und da geht es um ein User Interface für das Backoffice und die Geschäftslogik an dieser Stelle. Und in einem anderen Teil des Systems geht es darum möglichst schnell irgendwelche Suchergebnisse auszuliefern. Und das sind extrem unterschiedliche Dinge, für die man wahrscheinlich völlig andere Architekturen nimmt und ob für eins von beiden jetzt so ein Domainmodell sinnvoll ist oder nicht bleibt den geneigten Zuhörer, der geneigten Zuhörerin überlassen. Auf jeden Fall ist für mich der Punkt, dass das nicht immer das gleiche sein muss. Ich weiß nicht, ob ich deine Frage beantwortet oder klug abgelenkt habe.
Lucas:
Ne, ich glaube du hast die Frage richtig beantwortet. Weil ich glaube, dass es für mich einfach so ist, dass in den Projekten in den ich bisher war, meistens… Also der Großteil der Komplexität in der UI und in der Datenbank steckte. In den Datenbank queries, wie… Also keine Ahnung, wenn man, jetzt ein rein fiktionales Beispiel, eine Suche baut für eine Ferienhausseite und man möchte jetzt das suchen, dann muss man halt gute SQL-queries schreiben. Man muss dafür sorgen, dass die Datenbank richtig strukturiert ist, damit man bestimmte queries sehr schnell beantworten kann. Und diese Art von Komplexität, die ist halt sehr hoch, aber danach irgendwie daraus Objekte zu bauen, die man dann an die View weitergibt, die ist halt relativ klein und nachher ist dann die Komplexität in der UI wieder relativ groß. Da muss man halt gucken, wie sorgt man dafür, dass die Darstellung für verschiedene Leute gut funktioniert und so weiter. Und vielleicht ist das einfach meine beschränkte Sicht auf verschiedene Arten von Projekten, aber diese Projekte, die ich bisher kenne, da ist es fast immer so, dass da an diesen zwei Orten die Komplexität liegt. Und dieses Herausheben von diesem Kernteil ist einfach vielleicht etwas, was in anderen Projekten, in anderen Kontexten viel wichtiger ist, weil das viel, viel mehr Komplexität ist, aber ich habe es halt einfach selber noch nicht so viel erlebt.
Stefan:
Also ich glaube es gibt… in Prinzip diesen Standard: “Es kommt ganz drauf an”, gilt natürlich immer. Können wir jetzt immer jeden Satz automatisch als Prefix damit betrachten. Ich glaube, dass es manchmal so ist, dass die beste Art und Weise sowas zu lösen einfach eine sehr datenbanknahe Art und Weise ist, weil da an Geschäftslogik, die man jetzt in Java oder Ruby oder C-Sharp oder Go oder was auch immer umsetzten müsste, gibt es einfach nicht so wahnsinnig viel. Die Anwendung macht im Wesentlichen, hat die irgendwelche Inhalte die liegen in der Datenbank da rum, müssen irgendwie visuell nach außen gereicht und hauptsächlich CRUD-mäßig irgendwie aktualisiert werden. Das gibt es bestimmt ganz oft. Dafür mag eine Architektur sehr gut sein, die da nicht so viel drauf gibt da jetzt Sache großartig gegeneinander zu isolieren. Es mag andere Stellen geben an denen es hauptsächlich um algorithmische Komplexität geht und die Datenhaltung absolut trivial gibt und es wirklich theoretisch alles was du da speicherst in einen zehntel des Hauptspeicher deines Laptops passt und da ein Fall um sich vielleicht darum Gedanken machen. Wieder anderer, du baust, was weiß ich, so ein kollaboratives Whiteboard Tool oder so, wo mehrere Leute gemeinsam ein Diagramm diktieren. Da liegt die gesamte Komplexität im Frontend, da ist die Datenbanklogik auch relativ irrelevant, weil du so einen ganzen Blob da irgendwie ablegst. Also es gibt eine riesige Bandbreite. Es gibt vielleicht so Stellen wo so ein CQRS-Ansatz gut passt, der auch aus der Domain-driven Design Ecke kommt übrigens, aber der im Prinzip sagt: Es gibt auf diesen einen Strang, diesen einen Weg… also CQRS heißt ja Command-Query-Responsibility-Segregation. Ein super fancy Akronym. Das bedeutet im Prinzip, dass du diesen Schreibstrang, also die Aktivtäten, die Kommandos, die machst du eigentlich so richtig schön Eric Evans mäßig mit commands, mit all diesen Zeug was da drin ist. Und da kommen irgendwelche Events raus und dann gibt es irgendwo einen event handler, der all diese Events nimmt und damit ein wunderbares read model befüllt, dass du dann super effizient mit direkten Datenbankzugriffen auslesen und ausliefern kannst. Also da hat das sozusagen beides. Du hast einmal die Fachlogik, das fachliche Modell mit all den Zeug ohne Abhängigkeiten auf Datenbank auf dem schreibenden, auf dem Aktionsstrang und da hast das hochoptimierte, dass dann eigentlich gar keinen tollen Domain-Layer mehr braucht in der Leseecke. Auch das ist nicht immer eine gute Idee, das ist manchmal völlig bescheuerte Komplexität, die niemand braucht. Kommt halt ganz darauf an.
Lucas:
Okay. Gut, ich glaube, wir haben das jetzt glaube ich sehr oft gesagt: Es kommt drauf an. Liegt dir noch etwas auf der Seele? Möchtest du noch etwas zu dem Thema DDD und overratedness oder nicht sagen? Oder…?
Stefan:
Also vielleicht kann man das Ganze nochmal versuchen zu verallgemeinern. Also diese… auf Englisch sagt man glaube ich Hot Take, ja, wenn jemand so ein Hot Take hat. Und hier kommt die völlig überraschende Aussage: “X, Y, Z ist gar nicht so geil.” Das ist so ein bisschen… das ist schon ein bisschen berechenbar und langweilig. Und eigentlich, also ich bin da komplett mit Schuld an diesem Ding, was ich offen zugebe. Eigentlich, auch wenn es sich wieder wie ein Allgemeinsatz anhört, ist sowohl das eine, wie auch das andere Extrem ist falsch. Also es ist falsch einen Hype komplett hinterherzulaufen und alle immer super zu finden, nur weil das gerade Konferenzthema ist. Weil natürlich nichts uneingeschränkt immer gut ist und es ist falsch so zu tun als wäre es das. Das gilt für Programmiersprachen, für UI-Frameworks, für Datenbanken, für… keine Ahnung, Container-Scheduler, für Cloud Plattformen… was auch immer, völlig wurscht. Was auch immer das ist, jedes dieser Dinge hat Stärken und hat Schwächen. Meistens ist es so, dass die Leute, die darüber erzählen und berichten und die das bauen, das auch wissen und auch so sagen. Und das ist ein Zeichen von Qualität. Also wenn irgendjemand sich dahin stellt und etwas preist als: “Das löst jetzt alle Probleme der Welt!”. Dann ist das meistens Quatsch und machen die meisten ja aber gar nicht. Die meisten…
Lucas:
Dann sind das meistens irgendwelche Vendor, die etwas verkaufen.
Stefan:
Ja, genau. Und das gleiche was ich gerade gesagt habe gilt sozusagen mit minus eins multipliziert auch in die Gegenrichtung. Es ist auch total bescheuert, meistens zumindest, wenn irgendjemand sagt, dass überhaupt nichts gutes dran ist. “Totaler Unsinn, kann man nie benutzten!”. Das ist auch nur langweilig, das ist auch nur befriedigen von irgendwelchen Leuten, die genau das hören wollen. Und also das ist… Also weder macht es glücklich diese Vendor-Sales-Perspektive einzunehmen, wo einfach immer alles super ist, noch dieses curmudgeon, was sagt man auf Deutsch? Griesgrämige, diese griesgrämige Sicht: “Hatten wir alles schon. Ist alles schon da, hatten wir schon vor 20 Jahren gemacht. War da auch schon Mist!”. Stimmt meistens nicht, meistens ist was neues dabei. Also ist so langweilig sich das anhört, so ein differenziertes abwägen zwischen den Vorteilen und den Nachteilen. Nicht gleich alles abqualifizieren, auch nicht ohne Nachdenken hinterherrennen. So wenn wir halt schauen: “Ah, guck mal! Das ist das Neue, das ist das Interessante daran, das kann ich mir so und so nützlich machen, das kenne ich schon, das kenne ich noch nicht.” Das ist eigentlich das einzig verantwortungsvolle, was man da machen kann.
Lucas:
Super! Das war doch ein gutes Schlusswort. Gut, Stefan, dann danke ich dir für deine Zeit!
Stefan:
Ich danke dir Lucas!
Lucas:
Und ja, wir freuen uns auch über Feedback jeder Art. Gerne auch per Mail, bei Twitter, was euch lieber ist. Und ja, dann sage ich mal einen schönen Tag noch und bis zum nächsten Mal!
Stefan:
Bis zum nächsten Mal! Ciao!
Lucas:
Tschüss!