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.