Und ich finde, da sieht man wahrscheinlich relativ schnell, dass Domain driven Design jetzt eher sich. Kkw Maschinenhersteller finden. Da sieht man bei meinen. Begriffen hier Coding Buddies Dein Podcast rund um Softwareentwicklung und aktueller Tech News. Herzlich Willkommen. Herzlich Willkommen zur neuen Folge des Calling Bodys Podcast. Schön, dass du wieder
eingeschaltet hast. Und wie soll's anders sein, deine Gastgeber, meine Wenigkeit, der Tino und der fantastische Fabi. Er grinst mich wie jeden Donnerstag hier an, er ist bereit für ne neue Folge herzlich willkommen, fabi, was geht? Ab was geht ab, Mann, ich find's, ich weiß nicht was bei dir grinsen ist, aber ich zieh die heftigsten Grimassen.
Ja, das sind für mich ich ja, weißt du, ich bin ja immer sehr positiv, so weißt du und ich denk mir dann nenn ich das einfach mal grinsen, das klingt halt so schön, weißt du und alle so, oh ja, der grinst vor sich hin, muss ja keiner wissen, dass du total die. Grimassen ziehst. Das Ding ist ganz am Anfang vom Podcast.
Weißt du noch, es war so übertrieben aufgeregt, weißt du, der erste, die 1. Folge ja und jetzt ist halt so, machst du halt Grimassen. Also so Auflockerungsübungen für die Gesichtsmuskeln genau genau, genau vorher sing ich immer noch n bisschen weißt du, damit es ja ja klar na versteh ich versteh ich ja, es ist ja auch schon ne n bisschen Zeit ins Land gegangen also ja wir haben ja schon n paar folgen gemacht, ist so, da kommt dann irgendwann auch so n bisschen Routine rein,
aber ich hab trotzdem jede Woche Bock ne Folge mit dir aufzunehmen und ich freu mich auch auf das heutige Thema aber. Lasst uns erstmal über ne andere Sache reden, die die Woche abgegangen ist. Ja, am Dienstag, also wir haben es quasi gerade erst verdaut, hat ja unser For connect extreme Turnier stattgefunden, live auf Twitch.
Die Bots sind angereist, die Zuschauer auch, es war n absolutes Spektakel und ich muss sagen, also n bisschen verarbeiten tu ich es ja immer noch ne also es war es war krass, es war einfach krass. Ja, das fand ich auch krass.
Vor allen Dingen das, was ich auch, also was für mich krass war, war, dass ich das Gefühl, also wir sind, wir haben ja nicht ganz so lange gestreamt wie sonst immer, es war ja quasi relativ, also eher früher vorbei als normaler Twitchstream ne, aber nichtsdestotrotz boah ich komplett fertig danach, ich glaub, weil ich so aufgeregt muss und Bock hatte und es hat Spaß gemacht, wir haben das ja wieder so richtig schön
moderiert und. Es war auf jeden Fall n richtig geiles Event. Auch alle die dabei waren ne Riesen Dank für den tollen Abend war richtig cool, hat Mega Spaß
gemacht. Auf jeden Fall. Man muss natürlich fairerweise sagen, wir haben n bisschen früher angefangen, also vielleicht war der Stream gar nicht wirklich kürzer, wenn ich so jetzt so, also ich dachte auch mal krass, war ja eigentlich n kürzerer Stream und trotzdem völlig fertig gewesen danach, aber eigentlich ging ja fast ansatzweise gleich lang wie sonst. Wir haben nur früher angefangen. Aber ich hab länger. Geschlafen, drüber, nachdenkst, weißt du?
Und das trotzdem war ich müde danach, weil es halt einfach weißt, hat ausgelaugt, zweimal so aufregend. Ja, das stimmt, das stimmt, das stimmt. Ich war auch richtig angespannt, muss ich sagen. Ja, man muss ja auch sagen, dass die die Bots, die eingereicht wurden, ne, die hatten ja auch schon n gutes Niveau, also da ging schon einiges ab, deswegen waren es halt auch super spannende Matches. Absolut.
Also wir hatten ja insgesamt 16 Bots, das heißt, es gab ne Gruppenphase, also richtig, wieso so n geilen Turnier und danach ne n Playoffs quasi ne KO runde.
Oh, das war ja also die Spannung war ja, das war ja der Hammer, also gerade wenn so n Spiel richtig knapp war zwischen den Bots und dann so n Gewinner ermittelt wurde absolut geil also auch an dem Punkt noch mal Herzlichen Glückwunsch an alle Gewinner an die ersten 4 Plätze und noch mal n riesen Dankeschön an alle die teilgenommen haben ich hoffe ihr hattet Spaß beim Implementieren also das Feedback war auf jeden Fall super noch mal vielen vielen Dank an unseren Hauptsponsor Jet Brains
an der Stelle die auch Gewinne mit beigesteuert haben. Und an alle, die sich jetzt denken, weil sie jetzt vielleicht gerade hier zuhören und sich denken, ah, da hätte ich auch gern mitgebracht, ich hab es vielleicht nicht mitgekriegt oder hatte nicht so Zeit.
Keine Sorge, es wird auch ne dritte Auflage von dem Turnier geben, also von dem For connect Extreme und natürlich auch von den anderen Turnieren, wir hatten ja bisschen früher im Jahr das Flappy Buddy Turnier zum Beispiel, das ist ja n anderes Spiel, da wird es auch ne weitere Auflage geben und.
Ich sag mal so Spoilerwarnung. Wir haben ja auch schon die Idee für ein weiteres Spiel, was so gerade in der Community auch so ein bisschen entwickelt wird, wie das so sein soll und davon wird es dann natürlich auch Turniere geben, also hier auch noch mal ganz offiziell die Einladung, Liebe zuhören, lieber zuhören, falls du noch nicht auf unserem Discord bist und dir denkst, die Community klingt wirklich cool, jetzt mache ich den Schritt, ich gehe da mit rein und möchte mit planen an
dem nächsten Turnier und an dem Spiel, du bist herzlich eingeladen die Links wie immer in den Shownotes. Nach dem Turnier ist vor dem Turnier. Genauso sagt man genauso wie bei Podcast folgen nach einer Podcast Folge ist vor der Podcast Folge ich weiß gerade gar nicht wo wir sind nach oder vor aber auf jeden Fall mittendrin. Ja und dann lass uns doch auf jeden Fall mal das Thema Reinstarten und zwar ist es auch n Thema was auch tatsächlich, weil du es gerade gesagt hast.
Community aus der Community kommt zwar n Wunsch und es geht um Domain driven Design in dieser Folge. OK. Und also, wenn wir jetzt da mit reinstarten, möchte ich dir eigentlich mal so ne Frage stellen, ne, um um jetzt reinzukommen in diese Folge und zwar hattest du das schon mal irgendwann so in deiner Laufbahn als Softwareentwickler, als in deinem Dasein, dass es irgendwann mal dazu gekommen ist, dass irgendwie auf technischer und fachlicher Ebene aneinander vorbeigeredet wurde.
Also ist jetzt die Frage jetzt, ob es mal vorgekommen ist oder ob es irgendwann mal nicht vorgekommen ist. Ich glaube so kann man das schneller beantworten. Nein, es ist noch nicht nicht vorgekommen, sozusagen. Ja, das ist gang und gäbe. Ne.
Also gerade wenn Projekte größer werden und mehr Parteien da drin sind und das vielleicht nicht alles die absoluten Coder und coderin sind und man sich quasi auf low Level Ebene technisch unterhält, sondern übergeordnet fachlich, dann sind Missverständnisse sehr oft der Fall. Ja das geht ja dahin, dass du irgendwann Begriffe verwendest, wo beide Seiten. Bild von Harm aber es nicht das
Gleiche ist. Und das ist Realität, dass sowas passieren kann, weil du hast ja je nachdem in welcher Branche oder was nicht, Branche in welchem Bereich, auf welchem Level du dich bewegst, gibt es ja, so sag ich mal, allgemeine Begriffe ja, also das Wort an sich ist n allgemeiner Begriff, aber es steht für was spezifisches in deinem Kontext und. In einem anderen Kontext für was anderes spezifisches und bis man da merkt, dass man aneinander vorbei redet, ist absolut keine Seltenheit.
Ja, ich mein, das fängt ja auch teilweise schon an, wenn du keine Ahnung, irgendwer kommt von draußen rein, ne als irgendwie einfach fiktiv und sagt erst hast du gesehen was da draußen los ist. Also nee, meinst du das?
Nein, wieso glaubst du das? Nein ich mein das ne, also dass man direkt also die Assoziation, also allein schon das worauf jemand irgendwie wert legt, was was im Fokus von einer bestimmten Person steht ist ja schon mal was ganz anderes, ne also der eine denkt sich dann zum Beispiel ja okay draußen, da hab ich zum Beispiel das und das gesehen, weil es mir irgendwie aufgefallen ist, weil was weiß ich, da steht auf einmal irgendwie n verlassenes verlassene Pflanze draußen, die
irgendwer nicht mit reingenommen hat, der andere meint aber, dass jemand falsch geparkt hat, ne? Ist es halt der Fokus, der berühmte. Blickwinkel dann ne genau worauf
man achtet. Und ich finde, das ist halt, wenn wenn so ne Kleinigkeiten schon vorkommen, dann ist es ja eigentlich relativ einfach, auch gerade in solchen komplexeren Bereichen auch in diesem Modus zu kommen, dass man halt vielleicht ne andere Sichtweise auf bestimmte Dinge hat, ne und weil du ja auch jetzt gesagt hast, fachliche Ebene. Oder Fachlichkeit hatten wir auch gesagt.
So, ich hab mich irgendwann, da hatte ich mich auch mal mit jemandem unterhalten und da ging es dann auch immer so um beim Programmieren, da war ich noch relativ frisch, auch so Einsteiger im in in der Softwareentwicklung beziehungsweise als als Berufseinsteiger ne das mein Ich und da wurde dann auch mal hab ich mich mit jemandem leicht zusammen per Programming gemacht mit jemandem der dann auch.
Ja, sagen wir mal viel mehr Erfahrung hat und dann noch mal meinte, so, wenn ich dann irgendwie Vorschläge gemacht hab, meinte er so ja gute Idee, aber das ist wir müssen genau uns überlegen was eigentlich die Fachlichkeit ist. Ne also wir dürfen das jetzt nicht so technisch betrachten, also er war quasi schon in diesem Mindset Domain driven design drin ne und ich hab es aber irgendwie überhaupt nicht, ich dachte mal was will er denn mit seiner Fachlichkeit, ne?
Und da gehen wir auf jeden Fall noch mal genauer drauf ein, was jetzt wirklich ne Fachlichkeit ist, weil wir gesagt haben, OK, es gibt natürlich ne, man kann von der technischen Seite das ganze betrachten und von der fachlichen Seite, dass diese Unterscheidung noch mal n bisschen genauer klar wird, das kommt auf jeden Fall in Erfolge dran, das wird auf jeden Fall auch das Ziel dann am Ende sein und halt zu gucken, was ist Domain driven Design eigentlich ne, also es ist ja oft so, dass
es so bestimmte ich sag malideen gibt, die so rumgeistern oder so annahmen sowas wie. Domain driven Design ist n Architektur pattern oder wenn von Domain driven Design gesprochen wird, dann nutzt du Microservices, solche Sachen, aber das entspricht nicht unbedingt der Wahrheit, jedenfalls nicht genauso diese Gleichstellung sozusagen ne ja und da würd ich sagen, dass wir uns das einfach mal so angucken, was es damit alles auf sich hat, oder?
Ja, absolut. Und ich glaub das ist schon der erste Wichtige. Punkt, den man hier am Anfang der Folge direkt mal nennen sollte, bevor wir tiefgreifender darauf eingehen. Dass also Test, Test, das Test driven das ist bei mir einfach drin, immer domain driven Design ist für mich halt auch vom großen Prozentsatz aus ne Mindset frage oder n oder ne Herangehensweise die im. In der Einstellung startet sozusagen, und daraus können Architekturentscheidung resultieren oder sollten daraus
resultieren. Aber wie du schon meintest, es ist kein kein Architektur Pattern oder irgendwas was du direkt dann so umsetzt ne weil dann bist du ja schon wieder auch sehr stark technisch unterwegs und das ist ja gar nicht das worum es gehen soll, ne oder wie du meintest.
Was DDD ja, Microservices alles klar los geht es, wir legen los, darum geht es ja gar nicht ne, sondern man muss sich halt bei also wenn man über dieses Thema spricht mal n bisschen wirklich auch frei machen davon und das fällt halt manchen Leuten, gerade auch einsteigerinnen und Einsteigern, weil du das ja gerade erwähnt hattest, weil mir ging es genauso.
Schwer, sich davon n bisschen frei zu machen, weil man neigt dazu, immer sehr schnell ins technische zu gehen und sich zu überlegen, wie implementiere ich das jetzt? Ah na warte mal, warte mal jetzt jetzt braucht Datenbank hier dann anbinden Oh nee, da in dem Fall müssen wir aber auf das und das achten, weißt du also kennst du das wenn so die Gedanken abdriften und man sofort im technischen ist und damit mit diesem Designansatz ja über den wir jetzt sprechen werden.
Das Domain driven zu betrachten versuche ich bewusst davon wegzukommen und hab halt, wie du auch schon meintest, das Ziel, dass ich auf einer Ebene mit allen Beteiligten sprechen kann. Diese berühmte bekannte gemeinsame Sprache in Anführungszeichen, ne, dass wirklich jeder vom gleichen
redet und nicht wie du meintest. Hast du das gesehen da draußen und der eine keine Ahnung sieht wie du meintest, der parkt falsch oder was auch immer und der andere sie guckt ganz woanders hin, dann hab ich ja nichts gewonnen. Ich find das so geil, weil du sagst, diese gemeinsame gemeinsame Sprache, ne, da hab ich n Begriff gehört.
Also als ich das noch mal so n bisschen da drüber mir auch noch mal jetzt in im Zuge der Folge auch noch mal n bisschen so paar Sachen so quergelesen hab wahrscheinlich. Den gleichen, die ich auch gesehen hab. Ich kann ihn nur nicht aussprechen, so richtig. You you big, it is oder sowas language ne, das ist im Endeffekt so diese allgemeine Sprache, das wird wohl so genannt, hab ich vorher orderlich also den Begriff hab ich noch nie gehört, vorher ganz komisches Wort also.
Mich würd mal interessieren ob das so n so n geläufiges ja ist so n Ding vielleicht im Englischen? Ich weiß es nicht genau, es ist ja ist ja quasi englischen, aber vielleicht wird das da viel öfter verwendet.
Ich hab keine Ahnung, aber ich kann es halt wirklich wahrstellen so n alltagswort so weißt du so in jedem zweiten Satz, sprich bitte so nee, aber ich find es auf jeden Fall gut, dass weil du meintest, so dass man da relativ schnell abdriftet, ne und sagt so OK, ich bin so relativ technisch direkt unterwegs, ne und ich find das, aber eigentlich ist es ja komisch, dass es passiert so ne, weil wenn du jetzt zum Beispiel mal dir überlegst, ne so als kleine Analogie, ja stell
dir mal vor, meine Kaffeemaschine ist kaputt und du denkst dir ne ja pass auf wirklich doof das Fabian mag gerne Kaffee ne ich bring ihm einfach mal also du bringst mir jetzt ne Kaffeemaschine mit weil du noch eine übrig hast und denkst dir so Mensch Junge. Komm, du darfst hier nicht out of Kaffee laufen. Ne, das ist das ist n no go, das
dürfen wir nicht machen. So also bringst du mir eine mit, stellst du mir n Flur so ne und jetzt ist die Frage ne weil angenommen ich kenne diese Kaffeemaschine nicht ne du ich hab vielleicht weiß ich nicht bin auch n bisschen blöd in diesem Moment keine Ahnung du musst mir jetzt erklären wie ich diese Kaffeemaschine einschalte oder wie ich die überhaupt generell jetzt einsatzbereit bekomme wie würdest du das
machen? Also was würdest du sagen was ich machen müsste damit ich mir Kaffee damit kaufe kochen kann. Na ja, ich würde erst mal sagen, dass du ausrechnen musst, wieviel Kraft du aufwenden musst, um diese Kaffeemaschine hochzuheben. Das würde man erst mal berechnen. Ja dann die Distanz berechnen zum finalen Punkt, der auch ermittelt werden muss, ganz klar OK, mit dir kann man das nicht machen, genau genau das soll ja
nicht sein, ne? Du sagst ja auch nicht keine Ahnung. Und ja, so wie ich das gerade meinte, ne Wende jetzt bitte Kraft XY auf um diese Kaffeemaschine anzuheben, sondern. Kinetische Energie um die Kaffeemaschine in die Küche zu bringen und leite 230 Volt in die Kaffeemaschine, so das würde ja auch keiner machen, da würdest du sagen, Nimm die Kaffeemaschine, Pack die in die Küche, Steck Stecker rein und drück auf an, so nach dem Mut, das ist ja. Ist n Schalter on. Genau.
So, aber das ist halt genau der Punkt, weil in solchen Momenten ist, fängt man ja nicht an, technisch darüber zu reden, so, man ist ja auf einer fachlichen Ebene, man überlegt sich, OK, wie funktioniert das, was ich ja eigentlich machen soll, ne, wie erkläre ich das ganze fachlich, dann mach die Kaffeemaschine an, indem du auf Andrückst. Es ist halt so.
Das klingt jetzt so n bisschen witzig, aber es ist halt eigentlich n ganz gutes Beispiel, weil wir würden uns ja auf einer fachlichen Ebene. Wenn man das jetzt fachliche Ebene nennen kann bei einer Kaffeemaschine, da aber unterhalten, weil wir reden vom gleichen und du weißt, wenn ich dir sage, Steck bitte den Stecker rein, dass du auch bitte dann den Stromanschluss da bereitstellst sozusagen ne und genau darum geht es halt auch, dass man genau auf so einer
Ebene dann kommunizieren kann und man sich um die eigentliche Fachlichkeit der Kaffeemaschine. Unterhält und wie man das umsetzen kann und nicht darum, wie es intern sag ich mal elektronisch umgesetzt ist, weil das interessiert dich als Kunde zum Beispiel oder als als ja doch nehmen wir mal den Kunden im Sinne von dem Kaffeetrinker. Interessiert dich das ja nicht.
Ja, richtig, und da kann halt auch n Rechtsanwalt mit einem Elektriker sprechen und dann wissen trotzdem alle wie das Ganze funktioniert, auch wenn der Elektriker vielleicht genau weiß wie das da mit dem Strom funktioniert, ne?
Genau. Deswegen wollte ich erst sagen, so der der Maschinenhersteller, aber da gibt es natürlich Leute gut, doch nehmen wir mal das Beispiel, kann man auch ganz gut daran erklären, dass du sagst, aber auch bei einem bei dem Hersteller ne in dem Unternehmen die diese Maschinen herstellen, gibt es ja auch unterschiedliche Leute, da gibt es den Produktdesigner, dem ist halt wichtig wie die Knöpfe angeordnet sind, wie vielleicht die User Experience ist und den
interessiert auch nicht wie die interne elektrische Schaltung aussieht, damit das so funktioniert wie er sich das
vorstellt und trotzdem. Müssen ja die Entwickler ja, also sagen wir mal auch die, die wirklich das auf Elektroebene machen kommunizieren können die Produktdesigner und dann muss klar sein, wenn von dem Knopf geredet wird was passiert oder keine Ahnung weiß ich nicht irgendwelche Siebe, einläufe was auch immer man dann da besprechen kann, ja oder das Malwerk von mir aus auch da muss ja trotzdem jeder wissen worum es geht so ne. Genau.
Und ich find da sieht man doch wahrscheinlich relativ schnell, dass. Domain driven design jetzt. Eher sich kein Kaffeemaschinenhersteller finden. Da sieht. Man bei meinen Begriffen hier. Ein Sieb sieb ist schon mal gut. Das kann man bestimmtes Hunderpro dabei und Mahlwerk gibt es auch. Erzähl mir doch nichts. Wir reden ja hier von Vollautomaten oder wir reden doch hier von Vollautomaten. Nein, ich beite gerade. Ne Filtermaschine ist doch logisch.
OK, gut, dann bin ich raus. Nein, aber siehst du da? Haben wir schon wieder n? Nein, nein, aber also man, man sieht halt, dass deshalb zum Beispiel ist ja Domain driven Design keine kein Architektur Pattern oder so, das ist ja etwas, was im Kopf beginnt, ne also dass man sich wirklich überlegt, wie kann ich die Kommunikation maximal verbessern. Und dafür halt dann am Ende auch Sorgen, dass der Code halt eben auch besser ist.
Dass alle am Ende über das gleiche reden, aber dass es halt eben nicht im Code anfängt, sondern halt in der Kommunikation ne und demzufolge halt logischerweise im Kopf. Demzufolge ist es halt eben auch nicht einfach nur irgendwie n Pattern wo man sagt, OK, gestalte deine Software so auch unter anderem, aber es geht vielleicht auch n bisschen
darüber hinaus, ne? Wenn wir uns das ganze jetzt noch mal n bisschen technischer angucken, ne und sagen, OK, wir nehmen jetzt zum Beispiel das Kaffeebeispiel und unsere Kaffeefirma, keine Ahnung, die hat jetzt n bestellsystem ne und wir jetzt mal überlegen OK was ist jetzt eigentlich die Fachlichkeit bei diesem Bestellsystem, dann ist es ja so, dass im Großen und Ganzen die Fachlichkeit selber oder diese Domain, das kannst du gleichsetzen, die Fachlichkeit
sozusagen die Domain an der Stelle und du möchtest jetzt etwas bestellen, das heißt du hast irgendwie n irgendwas mit Order ne Order. Das ganze Ordering ne, das ist sozusagen eine Domain die dahinter steht und da wird halt im Endeffekt mit dieser Fachlichkeit wird beschrieben was eigentlich passiert. Also es geht wirklich um die Abläufe oder so gewisse Regeln aus der Business Sicht.
Ne wenn du jetzt zum Beispiel sagst du hast n Kunde der jetzt ne Bestellung aufgibt sag ich möchte jetzt gerne n Kilo Kaffee kaufen, beispielsweise in diesem Onlineshop oder was auch immer.
Dann darf natürlich nur diese. Besteht diese Bestellung getätigt werden, wenn auch Kaffee verfügbar ist, beispielsweise, und wenn nicht, dann wird dem Kunden halt angezeigt, ey pass auf, das geht gerade nicht, du kannst das nicht bestellen, weil es nicht da oder so und zum Beispiel gibt es dann auch noch die weiß ich, die Regel, dass es erst losgeschickt wird, wenn es bezahlt wurde oder sowas in die Richtung, das heißt es wird ja. Einfach nur beschrieben, wie
diese Domain ja in dem also dieses Geschäft in Anführungsstrichen, je nachdem wie groß du deine Domain siehst, aber zumindest diese diese online diese online Bestellung, diese Domain, diese Fachlichkeit wird einfach beschrieben.
Wie funktioniert das, was für Regeln gibt es da ne auf der technischen Seite ist es halt anders, da bist du halt eher an einer technischen Lösung orientiert wie du ja auch schon meintest, dass man da relativ schnell hin abdriftet und sich dann sagt, wenn dir jemand zu dir kommt und sagt ich mein, das kennen wir ja glaub ich selber ganz gut ne.
Kommt jemand zu dir hin und sagt Implementier Mal n Onlineshop, dann denkst du dir wahrscheinlich ehrlich, OK ramara, dann brauch ich irgendwie ne Datenbank wo meine ganzen Produkte drin sind. Wenn jetzt ne Bestellung kommt, wo wird die Bestellung gespeichert? Ah da nehmen wir vielleicht ne SQL oder ne Mongo DB. Das ganze packen wir in Kybernetes Cluster und wir implementieren es in in in Kotlin so ne und wenn jetzt aber zu viel Traffic kommt müssen wir das System skalieren das sind ja
alles dann im Endeffekt diese. Ganze Technik, Performance, Infrastruktur, Datenhaltung. Was für Implementierungsdetails wollen wir dafür nehmen? Also das wie ne wie wird es umgesetzt und das ist ja sozusagen dieser kleine Unterschied zwischen die Fachlichkeit die du hast und halt eben diese technische Seite, ne? Ja, und wenn man das ganze jetzt sag ich mal domain driven macht. Du hast ja jetzt Ordering zum Beispiel genommen, dann.
Ist es ja so, dass hier auch mal die Anmerkung, dass dein gesamtes Produkt oder deine Applikation, wie man es auch jetzt nennen möchte, auf welchem Schnitt ne. Besteht ja aus mehreren Domainen, sozusagen ne.
Also es gibt dann verschiedene Abstufungen sozusagen, aber du kannst ja jetzt sagen, dieser ganze Bestellprozess ist ne Domain, geh ich mit ja und dann gibt es verschiedene Entitäten, wie jetzt der Kunde das Produkt ja also was du jetzt so genannt hattest, um das noch mal so n bisschen einzuordnen, genauso gibt es ja aber auch weitere Domain, dass Du sagen kannst OK, aber payment ist auch noch mal ne eigene Domaine, weil der
Kunde oder der. Projekt Verantwortliche sagt, Ich möchte oder wir müssen dafür sorgen, dass man das Produkt auch bezahlen kann. Ja, er kommt ja nicht um die Ecke und sagt, wir müssen übrigens hier Payment Service XY anbinden, dafür müssen wir folgenden Request machen und das Mitsenden und hier damit wird er ja nicht um die Ecke kommen, das sind Themen die beschäftigen dich nachher wenn du quasi Dinge implementieren möchtest, aber auf Domain ebene diskutierst du
ja nicht. Auf diesem Level sozusagen, sondern du sagst vielleicht, wir müssen gewährleisten, dass wir verschiedene Bezahlmöglichkeiten anbieten. In genau dieser Payment Domain. Ne, wenn wir uns da also mit dem Blick auf diesen Punkt gucken sozusagen, und so geht das ja immer weiter, ja, also kannst du denn halt dein, dein ganze, dein ganzes Projekt strukturieren, mit dem richtigen Blickwinkel sozusagen. Ich find das gut, dass du sagst, dass dass man es halt theoretisch unterschiedlich.
Ich sag mal trennen kann oder eingliedern kann oder splitten kann wie du es nennen möchtest. Also die einzelnen Domains, weil ich finde ich weiß nicht wieso dein deine Gedankengänge normalerweise funktionieren, also ein bisschen weiß ich es, weil wir kennen uns ganz gut, aber bei mir ist es oft so, dass ich mir zum Beispiel denke ja hier domains ne so mach domain driven design, da musst du das in Domains teilen, dann denke ich mir oder ne wenn ich anfange mit einem neuen Thema.
Und vielleicht geht es ja auch irgendwie. Jetzt zum Beispiel Dir Liebe zur lieber Zurer, so dass du denkst, OK, domains, aber was sind denn jetzt meine Domains, ne? Und ich find das ist halt immer schwierig, weil für mich ist es
gerne. Also ich hab gerne sowas wie, ja das ist halt also das sind die Regeln, dann ist es ne Domain, aber es ist halt schon n bisschen floating ne weil du musst ja überlegen, OK was ist denn jetzt wirklich eine Fachlichkeit ist eine Fachlichkeit die komplette Bestellung ne dass du einfach sagst OK Bestellung umfasst
sowas wie. Den Warenkorb, den die Bezahlung, das ordern, weißt du dieses Ganze, weil weil du ja auch meintest, es gibt ja Payment zum Beispiel, es gibt es gibt Ordering was auch immer und es ist halt genau die Frage und das kann man nicht pauschal beantworten, was eine Domain
ist. Es ist immer die Fachlichkeit und das liegt im Auge des Betrachters und da ist es halt auch wichtig, wenn man gerade so nach Domain driven Design arbeiten möchte, dass man genauso was abklärt, ne also zwischen dem Team. Und ich sag mal dem Fachbereich, mit dem dann sozusagen diese Anwendung oder dieses Produkt oder was auch immer entwickelt wird, dass man auch wirklich mal klipp und klar absteckt, was ist denn jetzt eigentlich zum
Beispiel eine Domain, was ist eine Fachlichkeit, ne, was gehört zusammen, weil ich finde, und da, da geht es auch wieder um den Punkt Kommunikation, weil oft werden einfach Dinge angenommen, manchmal denken ja oder denkt so n Fachbereich gar nicht darüber nach oder so Fachexperten. Was es eigentlich bedeutet, weil es für die Leute so unglaublich klar ist. Aber kennst du das, wenn du dir
etwas total klar ist? Aber du kannst es trotzdem eigentlich nicht richtig beschreiben, weil es einfach nur so n Gefühl ist und das passt. Das passt zusammen, das ist eine Sache, das ist eine Sache, aber du kannst es nicht explizit beschreiben. Ja, also das ist halt gerade wenn man sich lange in ein Thema reingräbt und sich da auskennt und da quasi zu Hause ist, dass genau diese Momente auftreten, dass du sagst. Ja, ist doch logisch, oder?
Oder beziehungsweise dass du verknüpfen kannst, dass gewisse Dinge einfach immer zusammenhängen, was aber von außen und ich sag bewusst außen ne für Leute, die jetzt vielleicht auf eher auf fachlicher Ebene da unterwegs sind, das gar nicht bewusst ist, dass Dinge immer zusammenhängen und dass man vielleicht an der Stelle. Ganz andere Domain hat, als man gerade vom Mindset her, also als, als dass man gerade annimmt, sozusagen ne da.
Deswegen gibt es ja auch zum Beispiel den Begriff von Aggregates, dass du sagst, es gibt Verbünde, die immer zusammenhängen und nur zusammen funktionieren. Und wenn du dir über sowas Gedanken machst, kannst du halt auch besser Domain bilden. Ja, ja, beispielsweise weil du meintest, der Bestellprozess, das wird halt keinen Bestellprozess ohne einen Kunden geben. Ja, also irgendwer muss es ja bestellen genauso.
Ja, ich will mich jetzt nicht zu weit aus dem Fenster lehnen, aber sagen wir mal so n Warenkorb, weil du den gerade genannt hast. Der muss halt auch irgendwo im Bestellprozess irgendwie ne Rolle spielen, weil wo brauch ich n Warenkorb außerhalb sozusagen. Ja, genau, definitiv. Und so kann man denn halt quasi auch anhand dieser Entitäten, die da involviert sind, auch Domains dann irgendwie gliedern, sag ich mal.
Beziehungsweise du, du Meißelst das ja nicht in Stein und sagst, so sieht das aus, sondern es ist deswegen am Anfang dieser Aussage, es ist irgendwo auch Mindset 80% Mindset, würd ich mal sagen ne, weil du halt immer mit diesem Gedanken da rangehen musst sozusagen. Ja, auf jeden Fall. Und wenn wir jetzt, also wir haben jetzt.
Ich ich denke so so was jetzt ne Fachlichkeit, das haben wir eigentlich ganz gut abgeklärt und gerade bei Domain driven Design geht es ja auch vor allem darum zu sagen, ich möchte nicht die Fachlichkeit mit der technischen Seite vermischen, da hab ich mich zum Beispiel auch als ich das erste Mal oder als ich überhaupt so generell so n bisschen auf Domain driven Design mal gestoßen bin, dachte ich mir mal so, aber du brauchst ja irgendwann technisch das technische, muss ja mit rein,
also wie kann es sein, dass sozusagen, dass man diese diese Technik da ich sag mal also für mich war es dann so OK soll die soll diese technische Seite dann ausgeklammert werden oder so ne aber das ist es ja nicht, sondern es ist ja wirklich so, dass du sagst man muss es trennen, damit man eben damit die Software halt dann am Ende auch schöner wird ne also so n kleines Beispiel ne, wenn du jetzt mal wenn du jetzt sagst. Ne Bestellung darf nicht getätigt werden, wenn das nicht
auf Lager ist. Wenn wenn du davon nichts mehr hast. Also du kannst kein Kilo Kaffee bestellen, wenn es kein Kilo Kaffee mehr gibt. Von dieser Sorte beispielsweise ne technisch sagt man OK, wir müssen also die Menge in der Tabelle Inventory überprüfen mit einer SQL Curry mal als Beispiel ne das wäre jetzt sozusagen das technische und wenn du das ganze jetzt aber nicht trennst voneinander hast du vielleicht irgendwie diesen diesen technischen Aspekt wo dann irgendwo?
Ich sag mal in deinem in deinem ganzen Konstrukt, wo du da bestimmte SQL Queries abfeuerst. Also du hast irgendwo n Pfeil wo SQL Queries gebastelt werden und irgendwo innerhalb deiner SQL query wird aber gesagt so aber nur wenn Stock größer 0 ist. Ne nur dann können wir das zum Beispiel verarbeiten und dann ist diese Fachlichkeit die die dir eigentlich sagt. Du darfst gar nicht erst eine Bestellung ausführen, wenn der
Stock gar nicht vorhanden ist. Es ist ja eigentlich relativ einfach zu sagen, NE IF Inventory ist sozusagen für das Produkt ist 0. Dann kannst du halt nicht bestellen, dann wirf ne Exception oder irgendwie sowas. Ne, das ist ja eigentlich relativ einfach zu sag ich mal fachlich zu greifen, aber wenn das irgendwo tief im Code verankert ist, wo du. Vielleicht als Entwickler oder Entwicklerin auch noch mal ewig nachgucken muss.
Ne jemand sagt dir zum Beispiel sowas wie ja dein der User der bestellt, der muss aber verifiziert sein oder n Konto haben oder sowas ne und dann und das musst du jetzt einbauen, das heißt da müsstest du irgendwo gucken tief in diesen Code reingucken bis du irgendwann an der Stelle bist wo dann diese Bedingung kommt und wo du dir dann sagen kannst OK wart mal, aber hier will ich ja eigentlich das überhaupt erst machen wenn der User wart mal wo hab ich den User also du.
Du bist irgendwo ganz tief im Code drin und musst dann irgendwie frickelst da was rein, ne im im worst case und wenn du aber jetzt sagst ich trenne diesen technischen Bereich, also zum Beispiel den Datenbankzugriff ne von der fachlichen Seite, also irgendeiner übergeordneten Ebene wo einfach nur drin steht ne ganz, also ganz einfache Regel ne wenn das Inventory gefüllt ist und wenn der User zum Beispiel auch wirklich weiß nicht registriert ist, dann
darfst du überhaupt diesen Zugriff machen. Das ist sozusagen wieso ne, wie sagt man wieso n wieso n wieso n Buch so n Regelbuch weißt du wo du nachgucken kannst? Ja wonach etwas passiert und dann ist es viel einfacher so ne Zusatzbedingung noch hinzuzufügen, weil du eine Ebene hast in deinem Code, die einfach die überhaupt nicht technisch ist, sondern wo nur fachlich, sag ich jetzt mal regeln stehen,
die dir irgendwie zeigen. Nach diesem Prinzip funktioniert hier irgendwas, diese Domain ne. Ja. Ja, so kannst du ja auch abbilden, quasi wie die Funktionsweise aussieht. Und das ist ja der Punkt, dass du sagst, auf fachlichen fachlicher Ebene komme ich ja nicht dahin zu sagen, Na ja, da müssen wir in der Datenbank da und da abfragen, weil das interessiert auf fachlicher Ebene nicht, sondern es ist ja eher sowas wie ist der Artikel
noch auf Lager? Ja, wir müssen feststellen, ist der noch auf Lager, haben wir noch, ist er vorrätig oder so, das wär die fachliche Ebene. Und dann, ob dahinter ne Datenbankabfrage ist oder jemand guckt auf einen Zettel ob das da drauf steht. Wie auch immer erfasst wird ob noch dieses dieser Artikel vorhanden ist.
Also auf Lager ist oder nicht spielt ja also auf der fachlichen Ebene keine Rolle, genau auf der Domain jetzt ne klar jetzt kann ich in ne andere reingucken und dann sieht das vielleicht schon anders aus je tiefer ich gehe je technischer wird es zwangsläufig irgendwann ne. Aber wir sind ja quasi, und das ist wichtig, ja, auf einer Ebene, wo alle miteinander kommunizieren sollen, und dann gehst du ja nicht zum ja, keine Ahnung, nehmen wir das Beispiel
noch mal. Ich find, das ist n ganz gutes Beispiel zu sagen, wir haben jetzt n Designer, der sagt, so und so sieht der Job aus, ne und? Sagt, dann möchte ich da anzeigen, wenn der Artikel auf Lager ist, dass da n grüner Text ist auf Lager sofort lieferbar. Wenn das der Fall ist, möchte ich, dass die Lieferzeit so und so ist oder so weiter ne, also er betrachtet das ja ins Aus seiner Perspektive, das Design so, aber wenn er sagt auf Lager ne dann. Wissen alle, was damit gemeint
ist? Genau. Und er sagt ja nicht, wenn diese Query sagt, das Ergebnis größer 0 ist so nach dem Motto ne, weil du das so schön gesagt hast. Klar, auf technischer Sicht muss es so umgesetzt werden, um auf Lager entscheiden zu können, sozusagen ob es auf Lager ist oder nicht. Aber genauso wie du es schon angemerkt hast, das ermöglicht mir überhaupt den Spielraum zu
sagen. Ganz ehrlich, wir haben am Anfang ne technische Entscheidung getroffen, die sah erstmal gut aus, dass wir jetzt zum Beispiel die und die Datenbank nehmen, aber wir stellen das jetzt oben auf das
und das. Wenn ich aber das ganze Domain driven betrachtet hab, fällt es mir im Nachhinein viel einfacher diese Änderung sag ich mal auf Architekturebene durchzuführen beziehungsweise anders gesagt, meine Architektur resultiert aus einem Domain driven Ansatz und ich bin überhaupt in der Lage diese Adaption machen zu können, ohne dass. Alles den Bach runter geht so ne. Ja, du kannst halt einfach diese.
Du kannst halt einfach. Du kannst den technischen Teil austauschen ohne die Fachlichkeit halt im Endeffekt anzufassen. Ne, das ist halt genau der Vorteil an der Stelle. Also es wird immer noch grün angezeigt auf Lager, dann am Ende wie jetzt überprüft wird, ob das der Fall ist oder nicht. Ne, das ist halt der große Vorteil dabei. Ja, genau, und das ist halt finde ich auch genau die, die also genau die Frage, die man sich dann im Endeffekt auch gut stellen muss, weil.
Das hilft einfach, um wenn du in den Code guckst ne und du bist irgendein Entwickler, ne oder ne Entwicklerin und guckst in diesen Code und möchtest etwas erweitern und da steht irgendwas drin, wo du vielleicht nicht so richtig weißt. OK, was bedeutet das denn eigentlich? Ne? Also jetzt noch mal dieser Punkt, dass wirklich die Fachlichkeit eben abgebildet wird, aber nicht nur in ich sag mal Funktionen in Regeln
Abläufen, sondern halt auch. Im Naming von Funktionen oder von, von Klassen oder so ne. Und es gibt ja nichts Schlimmeres, als wenn du irgendwie in den Code guckst und irgendwen fragst und sagst, was ist denn das jetzt hier eigentlich genau, was bildet das in der realen Welt in Anführungsstrichen ab ne und dann kommt sowas wie ja, das heißt, das heißt zwar user, aber eigentlich ist es nur n Account ne so und dann denkst du dir so OK, also was ist denn das jetzt
genau also. Du musst, du brauchst dann transferleistung im im Worst case. Wenn du es nicht gut quasi gemacht hast. Wenn du diese diese einheitliche Sprache im Code und in der echten Welt in Anführungsstrichen nicht richtig vereinheitlicht hast, dann brauchst du ne transferleistung irgendwie so ne Art Übersetzer, der dir sagt, das bedeutet aber eigentlich das und ich finde das ist auch so n so n Red Flag, wenn es um Software geht, mehr oder weniger, dass man sich
sagt. Wenn du hörst, eigentlich bedeutet es aber das und das oder eigentlich ist damit das und das gemeint, dann weißt du schon, OK, hier gibt es ne Diskrepanz zwischen dem Code und der wieder in Anführungsstrichen echten Welt, ne zwischen dieser Fachlichkeit, die eigentlich irgendwie abgebildet werden soll und ich hatte das selber auch schon mal, dass ich mir mit einem Kollegen angeguckt hatte n Code und gesagt hab, so ey, verdammt noch mal was was, was
soll das sein, was bedeutet das eigentlich ne und dann? War auch die Antwort. Ja, das ist eigentlich, weil dann kam jemand, der das kannte oder das entwickelt hat beziehungsweise da schon länger im Produkt war und meinte so, ja, das ist jetzt zwar so und so benahmt, aber eigentlich gehört
das gar nicht. Man könnte zwar denken, dass das sozusagen zu a gehört, aber eigentlich ist es b so und du denkst dir so wie soll man das zur Hölle wissen, wenn ich jetzt mich mit irgendwem unterhalte aus dem Fachbereich über genau diese diesen Punkt denk ich mir so. Nee, aber also das passiert aber im Code nicht so wie du sagst.
Also dann, da müssen wir es umbauen, aber eigentlich war es eigentlich genauso gemacht, nur dass halt eben ne ich dieses Wissen dafür nicht hatte und dafür ist es halt super gut einfach zu sagen, OK wenn du gut nach Domain driven Design arbeitest, dann. Ist der Code quasi mit der eigentlichen Fachlichkeit eigentlich sehr gut erklärt, weil du sehr gut verstehst, was eigentlich wirklich passieren soll. Das ist halt n Riesenvorteil ne, weil du ja gerade n Beispiel gebracht hast.
Das ist wirklich nicht selten, ich hatte das auch in einem, ist schon ne Weile her in einem Projekt, das war im Prinzip ziemlich Hardware nah oder es war Hardware nah und es gibt halt einfach so Begriffe, das hatte ich ja am Anfang gesagt, die sind so. Allgemein, dass jeder mit seinem Blickwinkel weiß, was dahinter steckt, aber das sich nicht
deckt. Ne einfaches Beispiel, da ging es halt darum in diesem Projekt quasi verschiedene Stände Releases zu bauen sag ich mal ne und oder auszuliefern gehen wir mal ganz allgemein davon ne wir hatten n Produkt, das lief auf Mikrocontroller und das musste ausgeliefert werden und.
Im Endeffekt das Wort Target. Ja, jeder verbindet da wahrscheinlich was anderes mit ne, aber du konntest so wunderbar sehen, dass am Ende jede Person, die auf einer anderen Ebene unterwegs war, für diese Person war. Wenn das Wort Target fällt. Etwas Unterschiedliches, das fand ich stark, weil für mich zum Beispiel der sich viel auch mit der Bildumgebung beschäftigt hat, war ein Target einfach, dass wir etwas gewisses Bauen, kompilieren und Linken
sozusagen. Ja, also wir haben ein Target, und das ist das Ziel, was da am Ende rausfallen soll, war in dem Fall keine Ahnung, sagen wir jetzt einfach eine Executable oder eine Library oder so, ja, und für andere war das aber zum Beispiel direkt das, was du auf Mikrocontroller Flasht am Ende. Ja, das ist n Target sozusagen ne und für den Dritten war das wieder übergeordnet noch was anderes. Ja, es steigert halt am Ende dann die Komplexität.
Ne, weil du genau dieses Verständnis, dieses einheitliche Verständnis nicht hast. Und es ist halt viel, viel einfacher. Wirklich den exakten Begriff also am besten du hast noch sowas wie ja ich pack da n Entity rein, so ne, aber dann weißt du ja gar nicht. Also es ist doch viel einfacher, wenn wirklich das da steht worum es geht als wenn du irgendwas hinschreibst was allgemeines und irgendwie auf einer Metaebene funktioniert und du dann halt eben dir überlegen musst. OK.
Warte mal, das war das. Das war also, das ist ja, wieso Vokabeln lernen, die du noch zusätzlich machen musst, ne und wir wissen alle, dass es durchaus komplex sein kann, Software zu entwickeln, je nachdem gerade in bestimmten Bereichen, wo vielleicht auch noch mehrere, ich sag mal fachlichkeiten aufeinandertreffen, ne wo vielleicht mehrere Fachlichkeiten innerhalb einer Software aus verschiedenen Bereichen sogar noch kombiniert werden müssen, dann ist es natürlich viel viel einfacher,
wenn du dann nicht zusätzlich noch. Dir diese Komplexitätsstufe noch mit reinholst ne ja. Jetzt fragt sich vielleicht der eine oder andere, OK gut, hab ich verstanden, fachliche Sicht da drauf, domain driven ja gemeinsame Sprache das andere Wort hab ich schon wieder vergessen was du gesagt hast kann ich es nicht aussprechen. Und aber was, was ist ja genau, was ist denn jetzt so der Punkt, dass man sagt, deswegen sollte man das so machen?
Was sind die Vorteile, was sind die Nachteile, weil es gibt nicht, also wenn ne Sache nur Vorteile hat, würde es ja jeder machen, da ist es mal so als Spoilerwarnung ne also es gibt ja Gründe die dagegen sprechen und gerade Domain driven Design geistert doch jetzt bestimmt. 20 Jahre schon durch die IT Welt gerade in der Softwareentwicklung.
Ich meine, das ist ich krieg es nicht genau zusammen, das hätte man vielleicht recherchieren soll Schaden über mein Haupt, aber so Anfang der Zweitausender gab es so die erst ist das somit das erste Mal gefallen würd ich sagen wenn ich das so richtig verknüpfe kann sein dass es auch viel früher ist. Dann gerne ne Nachricht an uns aber ich meine so Anfang der Zweitausender ist das so n bisschen aufgekommen das ganze ne oder? Man hat es, sag ich mal, in
Begriffe gepackt. Ja, weil diese Gedanken dahinter sind wahrscheinlich schon älter, aber dass man den ganzen Namen gibt, sozusagen ne. Ja, die Grund. Die was sind jetzt? Was würdest du sagen, sind jetzt so die ganz klaren Vorteile dahinter, weil oder wo wo du sagst. Deswegen verwende ich das Prinzip auch oder dieses Mindset.
Mhm, also erstmal ist es natürlich ne klare ne bessere Kommunikation die stattfinden kann über auch das Entwicklerteam hinweg würde ich sagen, weil das ist halt sehr wichtig, bedeutet aber finde ich auch um jetzt ganz kurz das noch mal einzugrenzen wann es überhaupt sinnvoll ist oder wann es wirklich Vorteile bringt, wenn du halt auch in einem, ich sag mal relativ komplexen Umfeld dich bewegst.
Dann macht das eben halt auch Sinn ne, weil dann hast du ne weil komplexeres Umfeld bedeutet mehr Kommunikation und die kann dann halt eben eben besser werden. Ne, du kriegst halt n super klares Modell wenn du möchtest. Für deine Fachlichkeiten, für deine Domains, für Deinen, für das was für deine Regeln deiner Software was da passieren soll sozusagen ne und ich finde es ist halt auch relativ gut testbar, weil du halt relativ. Einfach siehst, was in Deiner
Software passiert. Also du hast halt ne Ebene, in der du das halt gut sehen kannst und demzufolge halt gut auch deine entsprechenden. Ich sag es jetzt wieder, ich weiß es geht wahrscheinlich irgendwann auf n auf n Keks, weil diese entsprechenden Fachlichkeiten halt eben auch gut abgebildet werden können, weil du das Halt verstehen kannst was da los sein soll überhaupt weißt du.
Ja, ich glaub du kannst das relativ da auch streichen, weil in dem Moment, wenn ich mir die Gedanken darüber mache, hatten wir ja gesagt, resultiert ja auch eine Architektur dementsprechend daraus. Und die ist testbarer ja, weil ich halt Entscheidungen treffe, weil ich es fachlich und technisch sauber auch trenne, dass ich einfach ne testbarere Software hab, weil ich zum Beispiel, wie wir vorhin gesagt haben, die unterste Ebene denn auch austauschen kann.
Ja, weil es nicht mehr ne Rolle spielt, welche Datenbank hängt da dran, sondern ich möchte testen, ob da jetzt steht auf Lager ne und das kann ich ja denn. Testbar gestalten, indem ich dann auch Dinge austausche und das simulieren kann beispielsweise.
Also da geh ich auf jeden Fall ganz klar mit und ich find es auch gut, dass du gesagt hast, also diese gemeinsame Sprache ist auf jeden Fall ja n Vorteil und diese komplexitätsabbildung ich finde mit Domain driven schafft man es einfach näher an die Realität zu kommen, Mhm. Ja, also du hast ja Modelle
gesagt. Klar, es sind am Ende Modelle, ja du kannst nicht die Realität, dafür gibt es Modelle, du kannst es ja nicht 1 zu 1 abbilden, aber du versuchst dich auf die Dinge zu konzentrieren in deinem Modell, die von Bedeutung sind für die Applikation und die werden halt besser und realitätsnaher und dementsprechend hast du auch ne bessere Struktur am Ende die daraus resultiert ja.
Ja. Ein Punkt, den du ganz eingangs erwähnt hattest, fand ich ganz witzig, weil du hast gesagt, Domain driven ja, Microservices, so dass das Mindset so Rumgeistert, geh ich mit denken viele dran, hat aber halt auch n Grund, weil dieser Domain driven Design Ansatz auch ne starke Basis für ne Microservices Struktur oder Architektur bildet. Ja weil du halt genau das halt schon so betrachtest, dass das überhaupt technisch möglich ist.
So zu differenzieren. Ich glaube, in der Folge Microservices, Monolithen, das hatten wir so mal in der Folge verglichen, da hab ich auch glaub ich sogar den Begriff Fachlichkeit verwendet, weil du n Microservice für eine
Fachlichkeit abnimmst. Als du lebst, ist einfach nein nein, weil also ist mir gerade eingefallen, weil du hast ja recht, es ist es ist halt möglich, dass also da domain driven Design, wenn du dieses wie gesagt im Kopf hast, ne dieses Mindset mehr oder weniger ne, dann ist Microservices eine mögliche Architektur dafür. So ne, genau so kann man das, weil du halt wie gesagt diese bounded contexts hast.
Ne und diese Aggregates durch diese Betrachtung bündelst du halt Dinge die einfach zusammengehören und kannst daraus halt Architekturen ableiten wie zum Beispiel Oh Mensch, das ist so n astreiner Microservice. Jetzt ja. Der daraus resultiert.
Genau, ja, und natürlich gute Designentscheidung, resultierende gute Architekturen und das ist wie bei jeder guten Architektur, dass ich natürlich dadurch schaffe, langlebig das Ganze zu gestalten, ohne dass ich es komplett neu implementieren muss oder mir das ganze wieso n Kartenhaus zusammenfällt. Das ist natürlich klar, dass das daraus resultiert, deswegen würde ich es fast schon
spannender finden. Welche Nachteile siehst du da drin beziehungsweise wann würdest du sagen er heißt n bisschen over the top das ganze ich wollt Grad sagen klingt doch alles gut, warum sollte man das jetzt einfach so gibt es nicht Folge beendet aber. Es es ist halt so oftmals einfach genau, es sind halt ähnliche Gründe oft nicht. Ich meine das ist halt logischerweise, du musst dir ne gemeinsame Sprache bilden, ne was wir gesagt haben, diese UB.
Wie geht es Language? Nein, aber das sind alle alle das Gleiche verstehen, sagt jeder zehnmal dieses Wort oder aber damit damit alle das gleiche verstehen, und das ist ja genau wieder n Punkt, der ist halt anstrengend, das ist halt, es ist natürlich irgendwie ne gewisse Art von Investment, das dauert du, du musst halt irgendwie Zeit investieren um dir zu sagen, OK wir schaffen aber dieses gleiche Verständnis und das ist natürlich einfach nun mal am Anfang erstmal n
bisschen zeitintensiver, das bedeutet das ist halt teurer beispielsweise. Du brauchst sowas nicht zu machen, wenn du NMBP machen möchtest, wo du einfach nur mal irgendwas austesten willst. Im Proof of Concept Hinballern möchtest, dann brauchst du sowas erstmal nicht zu tun.
Ne, dafür ist es halt einfach nicht gedacht, ne oder zum Beispiel sowas wie irgendwas einfaches crat, mäßiges ne ne API wo einfach nur irgendwas erstellt, gespeichert, verändert, gelöscht werden soll, was auch immer, dann brauchst du auch keine extrem krasse Architektur, das ist im Normalfall relativ klar was da passiert dann ne.
Es geht um wirklich komplexe Sachen und wenn die Sachen nicht komplex sind, dann muss man nicht unbedingt Domain driven Design nehmen, dann ist es teilweise sogar einfach zu viel. Ja, das das neigt dann ganz klar zum Over Engineering, auch ne. Also wenn ich ne so ne kleine Applikation hab, dass ich einfach eine Domain hab und da ist einfach alles drin und ich kann da 1000 Stunden drüber nachdenken, es bleibt diese eine Domain weil es halt einfach wie du meintest so ne simple
Anwendung ist dann. Wozu den Aufwand betreiben? Dann macht das keinen Sinn, dann brauch ich das nicht, dann wird da auch nicht ne bessere Architektur draus resultieren, weil die Architektur eh schon nur simpel sein kann, sozusagen ne oder gar nicht komplexer werden kann, dass ich in irgendwelche Bredouillen komme, sozusagen. Da hab ich. Da da würd ich ja auch sagen und ich finde wegen dieser gemeinsamen Sprache, ich will also das, das ist jetzt kein, wie soll ich sagen.
Kein Angriff oder so gegen Junior Developer, sondern einfach nur meine eigene Erfahrung. Ich als Junior Developer, wo ich frisch ins Arbeitsleben eingestiegen bin, hätte man mir das so dermaßen um die Ohren geworfen, dass ich mich da hätte, also so nach dem Motto Domain dürfen ist klar oder so neues Projekt, jetzt geht es los
hier. Ich finde man, da muss man halt auch n bisschen reinwachsen, dann ist es vielleicht nicht unbedingt Junior developer abhängig, sondern eher erfahrungsabhängig ne, weil ich denke es gibt auch Senior Developer, die da nicht ewig viel mit zu tun gehabt hatten, weil sie vielleicht einfach auf ganz anderen Projekten unterwegs waren. Ja und man muss da reinwachsen und das ganze muss Reifen so das ist der Punkt. Das muss einem klar sein, dass es das funktioniert in der Regel
nicht so einfach. Out of the Box, habe ich
festgestellt. Ja, finde ich auch gut und da würde ich auch einfach so n Tipp mitgeben, weil für mich war es immer ganz am Anfang als ich so Domain driven Design gehört hab, war für mich immer so OK irgendwie, du musst es hat irgendwas mit Ordnerstruktur zu tun ne für mich war es immer so, da muss ich irgendwie die Files und so weiter muss ich dann irgendwie so das das muss irgendwie das muss passen du hast irgendwie so Ordner und da kommt alles rein.
Sowas war für mich am Anfang immer so Domain driven Design, aber eigentlich, wenn man jetzt mal wirklich das ganze ganz abstrakt betrachtet, ist es klar, kann man mich jetzt gerne werfen, Stein was auch immer, aber es ist eigentlich scheißegal. Ich. Hab schon eine in der Hand hier. Aber es ist scheißegal, mehr oder weniger ne wo die Files jetzt liegen, weil in erster Linie geht es um die Idee zu sagen.
Löst dich mal n bisschen von dem ganzen technischen Gedanken, wie du irgendwas umsetzt, sondern geh doch erstmal wirklich auf der obersten Ebene ganz fachlich, was jeder versteht ran und versuche deine Regeln in den Code zu fassen und danach kannst du alles implementieren, so und dann kommt man ganz von alleine dahin, dass du sagst OK warte mal, das ist ne Fachlichkeit, das würde ja vielleicht Sinn machen, dass man diese Fachlichkeit auch in n eigenen Ordner zum Beispiel
Zusammenpackt. Ne, dass man zum Beispiel sagt, Ja, und die ist da und die ist da. Und wenn du jetzt aber zum Beispiel irgendwelche Hilfsfunktionen hast, die aber überhaupt nicht fachlich sind, ne, weil ich find das ist so n relativ schneller Gedanke der mir aufkommt sowas wie du willst, Redundanzen vermeiden irgendwelche Hilfsfunktionen, die du nicht zweimal implementieren willst und die ist überhaupt nicht fachlich, sie hat nichts mit der Fachlichkeit zu tun.
Ja dann pack dir n shared Ordner so nach dem Motto und dann ist es OK, dann kannst du sie überall benutzen. Wenn es aber sehr sehr fachlich ist, wiederum dann ist es natürlich wichtig, dass es in die entsprechende Domain kommt, was? Eventuell n gleicher Ordner ist ne, aber das ist find ich das Wichtige sich einfach mal zu
überlegen. OK wie mach ich mich denn frei von dieser ganzen technischen Implementierung immer gleich komplett technisch zu denken und das ist find ich das Wichtigste was man jetzt so mitgeben könnte zu sagen ey domain driven Design denk mal n bisschen anders so nach dem Motto ich. Find es auch gut. Es ist auch n wichtiger Punkt zu sagen die Ordnerstruktur ist gar nicht so entscheidend dabei, klar. Das sollte aufgeräumt sein.
Das Projekt von der Ordnerstruktur her, und da gibt es auch Präferenzen, ganz klar, jeder baut sich das so n bisschen anders zusammen, aber wie du schon meintest. Domain Driven ist ja nicht die Ordnerstruktur, sondern zum Beispiel die Abhängigkeiten unter, also unter den Klassen ja oder wie Kapsel ich das ganze, welche bound it Kontext habe ich, wie gruppiere ich das ganze?
Das sind die entscheidenden Fragen, die mich dann in der Entwicklung begleiten und gute Entscheidungen treffen lassen und nicht die Ordnerstruktur, aber natürlich räumt eure Projekte auf Leute, andere Entwicklerinnen und Entwickler werden es euch danken, ja. Da würd ich sagen, haben wir es. Cooles Thema, ich find es halt auch geil, dass Domain driven Design halt wirklich viel übergeordnet ist.
Ja, also es ist jetzt nicht, dass man über Code quatscht, sondern einfach die Ebene da drüber und es fördert halt auch einfach ne gute Zusammenarbeit und gutes Projektgeschehen, das muss man sagen und es resultieren auch oft daraus gute Architektur architekturentscheidung richtig.
Und damit würde ich sagen, vielen Dank erstmal für das Gespräch. Tino über DDD wie man das so schon nennt und Liebe zuhören, lieber zuhören, wenn du jetzt sagst Ey, das war echt ganz cool, manche Sachen sind mir noch nicht so ganz klar oder könnt ihr da noch mal bei der einen oder anderen Sache in die Tiefe gehen oder vielleicht mal ne bestimmte Architektur beleuchten, die irgendwie vielleicht aus Domain driven Design resultiert?
Dann schreibt uns auf jeden Fall wie gesagt, Tino meint ja schon Discord beispielsweise Podcast Mail geht auch einfach auf uns zukommen, irgendwo auf den Plattformen eurer Wahl, links dazu gibt es auf jeden Fall den Shownotes zu einem Plattform und dann können wir da auf jeden Fall was machen, ne mit und auf jeden Fall ansonsten ich freu mich drauf. Ja ansonsten würd ich sagen war es das hier an dieser Stelle
auch. Vergesst nicht, wenn euch die Folge gefallen hat, einfach mal ne Bewertung da zu lassen oder
den Podcast zu empfehlen. Es würde uns mega freuen, wenn ihr sagt Ey ganz cool, es hat mir mal wieder was gebracht die Podcast Folge generell der Podcast und ihr sagt ey ich hab Grad n bisschen was übrig und möchte dem was Gutes tun sozusagen dann gibt es auch n kleinen Spendenlink in den Shownotes aber nichtsdestotrotz wünsch ich jetzt dir Tino und dir liebe Zura lieber Zura einen schönen Tag noch. Und bis zur nächsten Folge Deine Collin Balls.
Gemeinsam. Besser sag, wie geht es language, du kriegst es und sag mir you, wie geht es, bist du sicher, dass es ausgesprochen wird? Das klingt total falsch, ich habe keine Ahnung, ob das ausgesprochen wird.