Du setzt dich ja als Kind auch nicht aufs Fahrrad, fährst
einmal los, fällst hin und denkst dir so Alter was ne
Kacke, ich bin raus. Coating Buddies Dein Podcast
rund um Softwareentwicklung und aktueller Tech News herzlich
Willkommen. Halli Hallo und herzlich
Willkommen zur neuen Folge des Coding Vadis Podcasts.
Schön, dass du wieder eingeschaltet hast.
Wir sind neu ins Jahr gestartet 2.
Folge des Jahres Es geht weiter und ich möchte dafür meinen
Partner begrüßen, meinen lieben Kollegen Fabi, was geht ab, was
geht ab Tino Grüße dich und wie findest du neue Ansprache neues
Jahr es ändert sich alles jetzt ja, es ist abgefahren.
Oder aber was geht ab? Bleibt also das das kann ich dir
versprechen, ich hab mich schon mal gefragt so wenn du
angenommen du hörst so mehrere Folgen hintereinander, dann geht
es immer los mit ja neue Folge, neue Folge neue Folge was geht
ab, was geht ab? Na ja, aber die Leute wissen
dann einfach direkt, was abgeht. Halt ne.
Ja, was geht denn so ab? Ja, noch nicht viel.
Also ich bin ziemlich entspannt ins neue Jahr gestartet, muss
ich sagen und du schön bei dir ist.
Ja, doch, ich auch, ich auch all die Zeiten mit fetten, Riesen,
Partys sind vorbei bei mir ja ja, dieses Jahr ist alles anders
oder wie ich mein ich werd alt weißt du das hast du dir zur
Jahreswende überlegt, das ist das Jahr wo ich alt werde nee
cool weiß ich nicht, ich find es, ich find es wirklich immer
relativ entspannt wenn man einfach so, also beim
Reinfeiern. Irgendwie in so einer kleinen,
entspannten Gruppe ist. Weißt du so, die Leute kennt man
alle, man es fühlt sich irgendwie so zu Hause weißt du
das das das gefällt mir das mag ich find ich gut ja ja muss
nicht mehr die große Riesenparty sein ich find.
Ich bin auch ehrlich, dass Silvester einfach so n bisschen
überbewertet ist. Aber na ja, was soll es, was
soll es immer so, also ist nicht so das Highlight des Jahres was
viele erwarten sag ich mal. Ich hab also ich versteh auch
gar nicht wieso das so n Ding eigentlich immer generell.
Ist wahr. Wie auch immer.
Also dieses weißt du ja jetzt Silvester richtig, der Hammer,
weißt du ich mir mal. Denke so es wird genauso viel
der Hammer wie alles andere wenn du jetzt zum Beispiel ne Party
veranstaltest wird es wahrscheinlich.
Ja genau so ne normale Party die da.
Na die Wahrscheinlichkeit ist hoch, aber ich sag mal es ist ja
der positive Effekt dabei ist, dass wir ja auch die 1.
Folge des Jahres dann sehr entspannt aufnehmen konnten,
nicht völlig im Arsch waren sag ich mal ne muss man einfach mal
ganz klar so sagen und genauso geht es uns jetzt ja, wir haben
Bock, ich hab Bock. Auf ne neue Folge.
Genau, der Podcast ist schuld, dass wir nicht mehr feiern.
Nein, so ist es auch nicht gut okay gut, kommen wir mal.
Zum Thema heute, weil ich glaub wir brauchen heute n bisschen
Zeit ist n spannendes Thema ist n umfangreiches Thema und
deswegen werden wir heute mal keine Zeit mit Geplauder
verschwenden. Fabi und deswegen werd ich jetzt
noch n bisschen plaudern Nein starten wir mal rein, was haben
wir heute vorbereitet komm hau mal raus du hast n Thema
mitgebracht ich find das Thema Klasse, es ist sogar n Community
Wunsch Thema gewesen und ich denk mal das hat dich inspiriert
sei ehrlich na klar aber krass hab ich Bock hau mal raus.
Ja, ich glaube, wir hatten das schon n bisschen auf den Schirm.
Und dann kam noch der Wunsch und dann hat es einfach gepasst.
Also bevor ich das jetzt einfach so nenne, ne und sage was es
ist, möchte ich mal, dass du dir so ne kleine Situation
vorstellst und vielleicht gucken kannst, ob du sagst kenne ich
oder ist mir komplett fremd, habe ich noch nie erlebt.
Ja gucken wir mal. Also stell dir mal vor, ja
kriegst n Ticket. Ne ganz harmlos, da steht drin
sowas wie also Arbeit ist jetzt in einem, also hättest du jetzt
n arbeitsticket arbeitsticket ja also du kriegst kein Ticket
irgendwie beim Auto weil du falsch.
Geparkt hast, weil ich hab gerade.
Rausgeguckt vor Panik, aber nee, alles gut.
Ach so, übrigens du hast n Ticket, du wirst gerade
abgeschleppt. Nein, also stell dir vor du du
bekommst ein Ticket feature ne sowas.
Ganz harmlos steht drauf. OK, wir müssen den
Überweisungsprozess unserer Software leicht anpassen.
Ne, das heißt wir sind so Thema Bankbereich einfach mal
unterwegs und du sagst OK entspannt müssen den
Überweisungsprozess anpassen. Ja überleg dir jetzt was für
Anforderungen dahinter stehen, die sind auf jeden Fall
beschrieben und du öffnest aber den Code und merkst dann so na
OK warte mal es geht ja hier um ne fachliche Änderung.
Der Überweisungsprozess hat nur was mit Business, mit der
Business Logik zu tun und jetzt guckst du dir das an und denkst
dir so, jetzt muss ich irgendwie was am Rest Controller ändern.
Ich muss NDTO ändern damit das funktioniert.
Ich muss irgendwie noch an einem Repo was basteln und im Worst
case noch ne mittelschwere Datenbank Migration machen ne
und? Du bist halt da repo.
Meinst du jetzt n Datenbank Repository nehm ich mal an oder
OK gut. Und du?
Bist dabei, guckst dir das an, Programmierst auch schon und
mittendrin fragst du dich dann so was soll eigentlich der
Scheiß, also weißt du ob man es kennt?
Ne, jetzt hast du nämlich die Situation kenn ich nein, aber
die Frage an der Stelle ne die man sich dann stellen kann oder
die man sich vielleicht auch öfter mal stellt ist warum muss
ich eigentlich so viel Technik anpassen?
Also weil ich ja auch von Rest gesprochen hab irgendwie die TO
ändern repo und so weiter. Obwohl eigentlich sich nur die
Business Logik ändert. Ne, also eigentlich soll ja nur
quasi in dem in der Logik des Kerns sag ich mal deiner
Software soll irgendwie was verändert werden, was aber
eigentlich mit dieser ganzen technischen Geschichte drumherum
nichts zu tun hat. Und wenn dir das was sagt, ja
dieser eine Punkt sagt dir was, aber der Rest ich weiß nicht
hast du sowas schon mal gehabt? Ist dir das schon mal über den
Weg gelaufen? Ja, ja, ja, ja, ja.
Vor allem auch Tickets. Wo drin steht n bisschen was
anpassen. So also von der von der von dem
Grad der Genauigkeit der Tickets.
Ja OK das versteh ich auch, aber wir sind jetzt wirklich bei das
Ticket ist das Ticket ist top ja können wir mal davon ausgehen
Ticket alles super ja gut dann würd ich sagen kenn ich die
Situation trotzdem weil es zeigt einfach wenn ich unglaublich
viel an verschiedenen Stellen anpassen muss, dass ich schon ne
harte Kopplung hab am Ende und alles irgendwie vielleicht ein.
Etwas viel zu sehr ineinander greift, sage ich mal.
Und das technische von der von der Business Logik wie Du
meintest, vielleicht einfach nicht genug getrennt ist.
Echt ja würde ich da würden die Refactoring Alarmglocken
angehen, die man ja gekonnt ignoriert.
Dann nein sollte man nicht, aber ja doch kenne ich kenne ich zu
gut, gerade in größeren Projekten die schon ne Weile
leben. Ja, also größere Projekte sind
da auch schon irgendwie Stichwort, aber das Ding ist
auch wenn man sich jetzt vielleicht gedacht hat, OK, doch
so ne Situation kommt mir bekannt vor, wie du ja auch
schon meintest Kino, dann hilft da oder kann etwas helfen.
Ja, das heißt ja nicht immer, dass es auf jeden Fall hilft,
aber es ist auf jeden Fall möglich, dass es helfen könnte
und zwar seine Architektur, seine Softwarearchitektur
anzupassen, zum Beispiel mit der hexagonalen Architektur ne und?
Das ist eigentlich auch so das Thema.
Wir hatten ja in der letzten Folge angefangen mit
Softwarearchitekturen so ganz allgemein und auch schon
angeteasert, dass wir auch hexagonale Architekturen mal
betrachten wollen und genau das wollen wir heute mal machen, um
zu gucken, wie funktioniert das eigentlich, was ist hexagonale
Architektur und warum heißt das überhaupt hexagonale
Architektur, hab ich mich zum Beispiel früher mal gefragt.
Ja, ich guck jetzt mal noch fancy klingen.
Ja, von so 6 ne ich keine Ahnung.
Das gucken wir uns alles mal in dieser Folge an.
Finde. Ich gut, also Kern der Folge
ist, wie schaffe ich es quasi meine Businesslogik ins Zentrum
zu packen und die ganze Technik die du beschrieben hast
austauschbar zu machen? Das ist so n bisschen das
Kernelement um genau nicht mehr in diesen Pain zu kommen, dass
alles ineinander verwurstelt ist und man alles anpassen muss,
quasi nur weil man n bisschen die Businesslogik ändert, genau.
Ja, sehr, sehr cooles Thema. Hab ich Bock drauf Fabi wegen
diesem Thema oder dem Titel sag ich mal, dass man es hexagonale
Architektur nennt. Interessanterweise ist es ja
wirklich darunter Mehrgeläufig als unter dem Alternativnamen,
weil man kann auch sagen, dass es so n Ports and Adapter
Architecture ist. Also so Ports and Adapter
Architektur so und. Trotzdem muss ich sagen, kannte
ich es immer nur unter hexagonale Architektur.
Aber du hast schon recht, klar, Hexa steht jetzt irgendwo für 6,
ne für so n Sechseck sag ich mal.
Aber eigentlich heißt das jetzt nicht, dass man jetzt genauso
viel Schnittstellen haben muss oder so viel weiß ich was haben
soll, sondern es ist geht schon um ne beliebige Anzahl, aber um
sich das ganze vielleicht optisch besser vorstellen zu
können, hat man das vielleicht gewählt.
Liebe, zuhören, Liebe zuhören. Falls du weißt, warum es exakt
genauso auch genannt wird, dann lass es uns gerne wissen.
Es interessiert uns es vielleicht auch so, so coole
sind so coole Sidefacts, die man wissen kann.
Ja, auf jeden Fall. Wie gesagt, soll es darum gehen,
dass man die Fachlogik in den Kern setzt und die technischen
Details, die du jetzt zum Beispiel genannt hattest, ne,
wie zum Beispiel, wie binden wir uns denn an?
Ja, wir nehmen Rest. Ja OK, wir haben ne Rest
Controller auf einmal. Wo legen wir unsere Daten ab, na
wir haben Datenbank XY ne Post Rest beispielsweise OK gut
wieder n technisches Detail was alles wichtig für unsere
Anwendung ist. Aber und das ist der
entscheidende Punkt, austauschbar weil.
Man kann verschiedene Datenbanken anbinden, je
nachdem, was man gerade für sein Projekt, sag ich mal als besser
beachtet erachtet. Ja oder auch
kommunikationsschnittstellen, ja nach außen muss nicht Rest sein,
gibt es auch verschiedene Möglichkeiten und das sind halt
alles so technische Details, die auch gerade wir hatten ja auch
mal über Domain driven Design gesprochen und jetzt sind wir
hier quasi auf Architekturebene. Aber trotzdem hilft diese
Betrachtungsweise greift hier halt auch.
Und dieses fachliche von dem Technischen zu trennen hilft
natürlich auch ungemein in der Projektkommunikation.
Leute, die eher auf die Business Logik schauen und Leute die eher
sagen ich versuch das Ganze umzusetzen und sind mehr im
technischen Aspekt unterwegs und wenn die Architektur da schon
vorgibt, dass man das klar trennen kann, hilft das auch
ungemein in der Entwicklung und auch in der Kommunikation halt
ja. Genau.
Also im Endeffekt haben wir ja diese Grundidee, dass man so n
zentralen Kern hat, und dieser Kern bildet dann im Endeffekt
die Domain ab. Ne, weil du jetzt Domain driven
development gesagt hast beziehungsweise Domain driven
Design Design ja ja, so viel weißt du BDDDDDTDD manchmal
Design, manchmal Development, in dem Fall Design ja genau, aber.
Das das heißt, du hast irgendwo deine Domain beziehungsweise wie
gesagt Deine Business Logik die irgendwo im Kern sitzt und dann
hast du und weil du ja meintest so Ports und Adapter hast du so
verschiedene Ports, ne die dann an die zentrale Logik die
Schnittstelle zu nach außen da bieten ne also du hast dann
quasi so bestimmte Ports die als Schnittstellen gelten und da
können dann Adapter von von draußen andocken und die Idee
ist halt zu sagen. Innerhalb deines Kerns ne gibt
es halt nur ne Logik und keine Technik, keine Datenbanken.
Es wird quasi keine Datenbank erwähnt, es wird keine
Kommunikationsart erwähnt. Sag ich jetzt mal, sondern ja
oder oder keine UI irgendwas Definition die da irgendwie
darauf schließen lassen könnten, dass irgendwie ne gewisse UI da
irgendwie mit drin ist oder dass irgendwas passiert an dieser
Stelle. Sondern wirklich, dass du nur
sagst, OK, wir haben unsere reine Business Logik, die da
drin verankert ist. Ne und wir gehen da natürlich
auch noch mal logischerweise mit einer kleinen Analogie drauf ein
später, dass man sich das vielleicht auch noch n bisschen
besser vorstellen kann. Aber und diese du meinst ja
hexagonal, also mein Wissensstand ist, dass das
wirklich nur so ne Art, ich sag mal Darstellung ist, ne.
Ne, dass du sagst, du hast so diese, also diese so n Hexagon
kann man sich ja vorstellen und an jede Seite kann dann so n
Adapter andocken und jede Seite ist n Port ne und rein
theoretisch ne kann du könntest auch 8 Seiten da dran packen
oder 3 oder was auch immer ne also dieses.
Und es ist halt einfach ne gute Darstellungs.
Dann ne. Aber ich find es auch.
Lustig hat sich das auch so n bisschen.
Durchgesetzt ne, ich find es aber auch lustig wieso
hexagonal, weil ganz am Anfang als ich es immer gehört hab,
dachte ich mir so alter hexagonal was.
Was soll ich mir da drunter vorstellen?
Gar keinen Plan gehabt ne, ich dacht mir immer so was was ist
muss man da irgendwie seine Logik in 6 Teile auf also sein
seine Software in 6 Teile aufteilen aber was was passiert
hier auf jeden Fall also das hat mich auf jeden Fall am Anfang
mal n bisschen bisschen verwirrt.
Genau. Aber wie du ja schon meintest,
man kann sich das Halt gut vorstellen, wenn du jetzt die
Business Logik quasi in der Mitte als Kern sitzt.
Ich zieh dann quasi so n Hexagon Außenrum ne und hab in der Mitte
meinen Kern und dann. Stell ich halt oder definier ich
halt Ports an den Seiten, an dem man sich andocken kann sozusagen
oder verbinden kann ja um quasi mit der Business Logik zu
kommunizieren zu interagieren sag ich mal.
Je nachdem was ich da jetzt anbinde und das ist halt
eigentlich nur im Kern von Grundgedanken her ne richtig
richtig coole Sache. Ja, natürlich.
Der Teufel steckt im Detail. Es ist immer die Frage, wie kann
man das umsetzen, es ist nicht easy umzusetzen, es ist
aufwendig, es umzusetzen, aber im Kern erstmal muss ich sagen,
ist das ne sehr coole architekturweise ne, also
architekturart quasi eine Software zu gestalten oder so
ein System. Ich finde mal, ich glaub man
muss also weil du sagst es ist schwierig.
Ich weiß nicht, ob es schwierig umzusetzen ist, aber ich finde,
dass es ne ne. Schwierig ist, so diszipliniert
zu sein, es dann auch wirklich. Ja OK, das wirklich so
durchzuziehen ne, weil genauso wie es genauso bei TDD ne ich
finde TDD an sich ne um n kleinen noch mal n kleinen
Sidequest hier anzufangen ist ist ja nicht schwer, aber die
Denkweise dahinter und das zu verstehen und zu verinnerlichen,
das ist halt genau der Punkt und hier ist es halt eben würde ich
sagen auch. Ja, es ist halt wieder klassisch
Theorie und Praxis. Ne, in der Theorie klingt es
einfach, aber jetzt mit einem Team es langfristig in einem
großen Projekt umzusetzen. Bedarf, Erfahrung, einfach.
Da können wir vielleicht auch später noch mal.
Auf jeden Fall. Kommen, wenn wir sagen, so pro
Contra wann eignet es sich, wann nicht?
Aber das jetzt halt nur schon mal als Ausblick, weil wir
gerade sagen, OK es ist auf dem Papier ziemlich cool, aber es
bringt natürlich seine Schwierigkeiten mit ne das ist
jetzt kein Free Lunch, dass ich sage so jedes jedes
Softwareprojekt mach ich jetzt so.
Ja, definitiv. Aber wenn ich das jetzt noch
mal, ich fass noch mal kurz zusammen, ne wieso wie man sich
so jetzt das vorstellen kann. Du hast also quasi den Kern, ne
das wie gesagt Business regeln sind da drin irgendwelche Use
Cases die sich da drin abbilden oder du hast halt da bestimmte
Entitäten drin. Zu deiner Business Logik eben
die ganze Logik im Kern kennt keine technischen Details,
hatten wir ja schon gesagt und. Hat auch eigentlich nichts mit
irgendeinem Framework in dem Sinne zu tun.
Ne die Ports an sich sind Schnittstellen, ne diese Ränder
an den hexagonalen Architekturen sozusagen.
Oder am Hexagon. Und das können Inbound und
outbound Ports sein. Im Endeffekt eigentlich nur,
dass definiert wird. OK, das System hat ja
prinzipiell also diese Business Logik ist da, dieser Kern ist da
und es ist diesem Kern völlig egal wie der von außen
angesprochen wird oder also was ihn von außen anspricht oder was
er oder an wen er Daten nach draußen gibt, sozusagen ne und
diese diese Ports, diese Schnittstellen definieren
einfach nur OK, das ist so. Ich nenn es jetzt mal so n
bisschen salopp gesagt, so ne Art Protokoll wo du sagst Ey
pass auf, du bekommst das von mir und ich krieg das von dir so
und egal was jetzt von außen kommt ne das sind dann diese
Adapter die da andocken können. Es können halt auch in und
outbound Adapter sein, weil du kannst ja irgendwas zum Beispiel
bekommen ne oder irgendwas rausschicken zum Beispiel über
Rest ne und da hast du dann im Endeffekt eigentlich diese
diesen Kern, diese diese Schnittstellen und diese Adapter
von draußen und. Diese beiden Dinge sind
unabhängig voneinander und das ist genau der Punkt innen drin.
Business Logik außen dran, außen dran Technik weil wie du gesagt
hast, Rest kann auch angepasst werden durch was weiß ich ne Web
socket oder durch Soap oder frag mich nicht so verschiedene
Technologien ne. Aber noch mal kurz zu den Ports.
Ja, sie definieren im Prinzip nur was rein und raus geht, aber
es ist halt n unfassbar. Entscheidender.in der
Architektur diese Ports richtig zu definieren und auch zu
entscheiden, was es Inbound und outbound und dass man halt auch
die Unterscheidung trifft und nicht sagt, das sind jetzt
Ports, da definiere ich jetzt mal irgendwie Daten und mal geht
es rein, mal schreibt der eine drauf, mal schreibt der andere
drauf, mal liest der eine, Mal der andere, sondern damit kann
ich halt dadurch, dass ich sie quasi definiere als Inbound und
Outbound. Schaffe ich halt auch meine
Dependencies zu regeln. Ne, ob die jetzt quasi von außen
nach innen gehen oder von innen nach außen, das heißt es gibt
mir halt auch Kontrolle darüber, wie der Informationsfluss quasi
aussieht und ich finde das ist zum Beispiel auch so ein tricky
Part, dass man das halt richtig sauber definiert und einhält,
auch ne. Weil jede Architektur ist halt
wie du meintest auch abhängig vom Team.
Wie gut wird es umgesetzt? Ja, wenn ich jetzt anfange die
ersten 5 Ports sauber zu machen und danach frickel ich mir so n
Port zusammen wo jeder drauf schreibt und liest oder noch
besser ich geh dann doch wieder direkt irgendwie an die Business
Logik ran, dann ist das Kind im Boden gefallen schon wieder und
das ist halt so die Schwierigkeit ne also man muss
da halt klar definierte Ports haben und sich überlegen.
Wie sehen meine Dependencies aus und in welche Richtung wird
kommuniziert? Ja, definitiv.
Das ist n guter Punkt. Das das ist auf jeden Fall
wichtig, gerade weil du ja auch, sagen wir mal du hast ne
Datenbank und ne Datenbank, also wenn du es jetzt mal mit so
einem Schichtenmodell vergleichst, hast du
wahrscheinlich so n Schichtenmodell immer ganz
unten, das heißt du kommst halt irgendwie von oben rein, kommst
durch die Schichten und bist unten an der Datenbank irgendwie
angekommen beim. Bei so einem Hexagonal, bei
dieser hexagonalen Architektur ist es ja nicht so, dass du
irgendwie ne Art Schicht hast, sondern du hast ja wirklich
diese Datenbank, auch die von außen irgendwo andockt.
Ne, das heißt, du hast ja mehr oder weniger so n externes
System und da musst du dann natürlich auch gucken, OK, wie
hast du denn, welche Flüsse hast du denn innerhalb deiner
Architektur überhaupt, weil. So ne Datenbank sendet
normalerweise eigentlich eher weniger von alleine an die
Business Logik, sondern es wird immer angefragt, so als als
vielleicht kann man sich das so dann n bisschen mehr vorstellen,
weißt du? Ja genau, gutes Beispiel.
Genau das sind halt so die Sachen, ne, also wie wie muss
die Kommunikation denn halt einfach aussehen am Ende
speziell für diesen Port ja. Weil ich kann jetzt sagen, ja
gut, das ist ich bin jetzt eine Datenbank an, da ist mir klar,
wie das funktioniert, aber es geht ja genau darum, nicht zu
sagen, wie es technisch funktioniert, sondern über einen
Port zu definieren, wie erwarte ich meine Kommunikation und dann
muss das mit dem Adapter zur Datenbank matchen, sozusagen ne.
Ja genau, um sich das jetzt vielleicht.
Vielleicht können wir uns das jetzt noch mal mit einer kleinen
Analogie ein bisschen vertrauter machen, ne, ich hatte ja am
Anfang schon mal so ein bisschen diese.
So eingeleitet mit dem Beispiel eine Analogie mitgebracht habe
ich geil, ich habe am Anfang ja schon mal ein bisschen
eingeleitet mit dieser, mit diesem Ticket, wo wir gesagt
haben, okay, wir müssen irgendwie die Überweisungslogik
ändern oder was das war, ich habe es jetzt schon wieder
vergessen, ne, du kannst dich noch erinnern, das heißt stell
dir mal vor, wir sind irgendwie im Bankwesen unterwegs, ne, ich
habe jetzt mal bewusst Banken gewählt, weil ich glaube.
Wir sollten mal einmal jetzt auf Essen verzichten.
Was verzeih ich den dir? Ich hab noch nicht.
Ich hab noch nicht gefrühstückt, OK, nee, aber das heißt ne Bank
kann man kann man sich ja vorstellen, jeder hat irgendwie
mit Banken zu tun und muss vielleicht ab und an mal Geld
abheben oder irgendwas bei der Bank machen und ne Bank hat ja
an sich immer irgendwelche Schalter ne also du kannst ja
irgendwie zum Beispiel an den Schalter gehen, ne in der Bank
gehst du rein, da sitzt jemand, du kannst mit dieser Person
reden, ne? Und wenn du jetzt aber zum
Beispiel sagst, was ist denn jetzt ne Bank, ne, also wo zum
Beispiel sitzt der Kern, was sind die Ports und was ist jetzt
zum Beispiel so ein Adapter? Ne um das mal so ein bisschen
klar voneinander zu trennen und sich vorstellen zu können, wenn
wir sagen der Kern sind Bankenregeln ne, das sind
wirklich feste Regeln, die Regeln legen zum Beispiel fest,
wie darf man Geld überweisen, ne reicht das Guthaben aus, welche
Gebühren fallen aus, so was, das sind Sachen.
Die werden einfach innerhalb dieser Bank so gehandelt, wie
sie sind. Das heißt, es sind regeln, die
ändern sich im Normalfall selten, ja, vielleicht keine
Ahnung, kommt irgend n neues Gesetz und das heißt ja, die
Gebühren fallen da und dafür weg, das ist jetzt n neues
Gesetz, dann muss das angepasst werden, aber prinzipiell sind es
eigentlich Dinge die selten geändert werden und sie gelten
halt auch immer gleich ne, also unabhängig davon wie der Kunde
jetzt zu dieser Bank kommt ne so das ist also unsere wie wir es
ja schon so schön genannt haben, unsere Business Logik.
Und wenn du jetzt sagst, OK, der Kunde kommt zur Bank, wie kann
er denn zur Bank kommen, ne, dann gibt es ja verschiedene
Möglichkeiten. Ne der kann zum Beispiel sagen,
ey ich komm vielleicht über n Schalter, also wirklich wie ich
meinte du gehst in die Bank. Redest mit einer Person.
Du machst das über die App ne, also du kannst ja so richtig all
School Style, du gehst in die Bank und machst ne Überweisung
ne so wie vielleicht noch, ich glaub es geht noch also ich
glaub meine Oma die macht das noch manchmal so ne dass sie die
hat sich glaub ich mal tierisch darüber aufgeregt, dass man das
bald oder ich weiß nicht vielleicht mittlerweile nicht
mehr, aber sie hatte sich auf jeden Fall mal drüber aufgeregt,
dass es dieses Online Banking gibt, wo man ja irgendwie online
was machen kann und sie möchte das immer nur beim Schalter
machen. So nach dem Motto.
Und ich glaub, dann wurde irgendwann mal das Portemonnaie
in der Bank geklaut. Aber ist ne andere Geschichte,
also vielleicht doch lieber online Banking Oma, aber du
kannst es, aber das ist genau der nächste Punkt, ne online
Banking, du kannst es über ne App machen, du kannst aber auch
an den Geldautomaten gehen und am Geldautomaten diese
Überweisung ausführen. Also du kannst ja du hast
verschiedene Möglichkeiten irgendwie an diese Bank
ranzukommen, das heißt du hast ne wie kommt der Kunde zur Bank,
das ist ja dann wieder der Adapter und damit aber auch.
Der Schalter, damit die App damit n Geldautomat auch immer
quasi die gleiche Möglichkeit hat diese Regeln anzusprechen
gibt es halt eben diese Ports. Ne das ist im Endeffekt die
Festlegung wie kommuniziert wird ne also wie ist zum Beispiel ein
ich nenn es jetzt mal Schalter bei der Bank definiert weißt du
also n Schalter im Allgemeinen sind nicht jetzt n Schalter wo
jetzt ne Person drin sitzt sondern ganz allgemein das
heißt? Wie muss n Auftrag aussehen,
damit die Bank ihn bearbeiten kann?
So rum ne und OK, dann ist es halt egal ob du jetzt zum
Beispiel am also beim Adapter ne wenn der Schalter sagt OK der
Mitarbeiter spricht mit dem Kunden oder ne App nimmt
irgendwelche Klicks entgegen oder n Geldautomaten hat zeigt
dir überm Bildschirm was an, du hast diese Tasten, da unten ist
es du hast unterschiedliche Eingaben ist es irgendwie das
ist die Technik, ne die Technikseite diese Adapter und
dann. Wird ja irgendwie gesagt.
OK du ich brauch aber diese und diese und diese Daten und dann
kriegst du das was du brauchst für ne Überweisung.
Das können wir dann in unserer Business Logik umsetzen und
genau so. Heißt am Ende.
Wird das alles irgendwie nen Auftrag, dass Geld transferiert
wird? Überwiesen wird zum Beispiel
genau, genau, genau und ja, also im Endeffekt ist der Ausgang
dann von dem was du reingibst immer der gleiche ne also die
Logik läuft, läuft im Kern halt eben gleich ab, brauchst halt
die richtigen Daten. So und mehr nicht.
Ne und ich hab mal so n lustigen was heißt lustig bisschen lustig
vielleicht n bisschen ernsthaftig gemeint, die also
die Logik im Kern, die muss richtig schön sauber sein, ne
das das muss geil sein und draußen an den Adaptern ne da
kannst du n bisschen frickeln das.
Kann so n bisschen dreckig sein, das ist in Ordnung.
Wie kannst du sowas sagen, das ist nicht mehr dein Problem,
dann ne du arbeitest nur an der Business Logik und dann.
Stellst die Ports zur Verfügung. Draußen müssen sie zusehen, in
der harten Außenwelt weißt du da, wo es ums Eingemachte geht?
Nein, aber ich, ich versteh dein Beispiel, das ist ja auch n
gutes Beispiel, weil wie gesagt am Ende, wenn du jetzt zum
Beispiel verschiedene Eingaben hast, weil du meintest, so ich
kann das über ne App machen, ja und da kann ich die Daten
ausfüllen, dann hab ich vielleicht noch ne UI da drin
und weiß ich was alles ne aber am Ende.
Kommt ne Anfrage an die Business Logik bitte eine Überweisung
durchzuführen. Genauso gehe ich in die Bank wie
du meintest Füll den Zettel aus, die Mitarbeiterin nimmt, das
wird vielleicht eingescannt, eingelesen, automatisiert oder
jemand tippt das vielleicht noch in seine sein Interface ein,
aber am Ende ist es wieder der gleiche Auftrag der sagt Bitte
Geld von A nach B. So.
Und das gleiche auch wenn ich noch an irgendeinen Automaten
gehe. Genau, und das ist halt n gutes
Beispiel, weil jetzt kann ich halt sagen, so im Kern sieht es
halt immer gleich aus und die Außenwelt kann ich jetzt
beliebig erweitern, reduzieren oder anpassen.
Ja also das, weil wir reden ja immer davon das anzubinden und
Fakt ist aber auch es muss nicht ne definierte Anzahl an
Schnittstellen von Anfang angeben, ja.
Wie du ja meintest. Früher gab es halt keine App,
mit der ich das machen konnte. Hätte ich jetzt mal.
Klar, es ist jetzt sehr lange und es hat es ist viel passiert
in der Zeit, aber gehen wir mal davon aus, wir haben jetzt
unsere Software noch so mit dieser Architektur und auf
einmal kommt jemand ey ich hab ne krasse Idee, wir können das
mit einer App machen, ihr wisst nicht was ne App ist.
Stellt euch vor ihr habt so ein Ding in der Hand und damit habt
ihr Zugriff ja ein Smartphone ihr wisst nicht was ein
Smartphone Smartphone aber. Dann kann ich ja sagen, OK, ich
erweitere es um einen Port und hab ne neue Schnittstelle
sozusagen und ich implementier diesen Adapter oder ich geh mit
einem weiteren Adapter an so einen Port ran.
Wie auch immer das denn umgesetzt werden soll, aber ich
kann es erweitern oder auch reduzieren, wenn ich zum
Beispiel sag ey ganz ehrlich, es kommt gefühlt nur noch einer im
Monat und will n Überweisungszettel abgeben, das
streichen wir. Dann kann ich das sozusagen
wegnehmen, diesen Pfad also jetzt wirklich rein
architekturmäßig auf dem Papier. Ja, genau das hat jetzt mit
nicht viel zu tun, dass jemand mit dem Zettel ankommt, aber
damit man sich das vorstellen kann, ja, genau das heißt, der
Port ist quasi noch intakt, aber es wurde n Adapter quasi
gestrichen, ne genau. Und wir in dem Fall würde ich
jetzt mal davon ausgehen, dass es dann so aussieht.
Ja, also wir hatten ja zum Beispiel jetzt den Port
Überweisung tätigen, ne, das ist ja so ne oder weniger auch so ne
Art use case, dann ne. Und genauso kannst du jetzt zum
Beispiel auch, ich glaub, das kam ja irgendwann auch mal,
dieses Identität bestätigen, zum Beispiel online beispielsweise,
ne, da kam jetzt irgendwann dazu, ne ich, ich weiß jetzt
nicht wie das in den 70er Jahren war, ob man da einfach zur Bank
gegangen ist und gesagt hat, Jo Ick möcht n Konto anlegen, alles
klar, heutzutage musst du dich ja richtig also übertrieben
ausweisen und alles. So ne Identitätsprüfung machen
und dann hast du zum Beispiel auch wieder so n Port für die
Identitätsprüfung. Das heißt du kannst zum
Beispiel, es gibt ja verschiedene Verfahren, ne, also
irgendwie online über auch wieder irgendwie über ne App
oder du gehst halt in irgendeine Filiale rein oder frag mich
nicht, ich glaub da gibt es verschiedene Möglichkeiten und
das könnte ja jetzt zum Beispiel auch wieder n Port sein, genauso
wie zum Beispiel n Dauerauftrag einrichten, Konto eröffnen was
weiß ich Kontostand abfragen. Könnten alles irgendwie Port
sein, die ja irgendwie gleichzeitig wieder bestimmte
Adapter. Ne.
Also der Adapter könnte der Gleiche sein den du anschließt,
ne es könnte überall wieder die App sein, die sozusagen diesen
Port anspricht, ist ja kein Problem, ne aber im groben und
ganzen hast du trotzdem immer wieder irgendwie bestimmte
Adapter die du anschließt, ne beispielsweise finde ich bei der
Identitätsprüfung machst du das ja meistens nicht mit Deiner
Banking App von Deiner Bank, sondern mit einer dritten App.
Zum Beispiel mit so einem ident verfahren.
Weißt du, dann hast du ja dann keine Ahnung wie die Dinger alle
immer heißen. So, aber gefühlt gibt es da zig
Millionen und dann kannst du dich damit so identifizieren,
aber das ist mehr oder weniger dann auch wieder n Adapter der
an diesen entsprechenden Port irgendwo angrenzt, ne.
Ja, jetzt mit dem Beispiel kann man sich ja denken, OK, das
klingt richtig, richtig, fantastisch und auch in der
Theorie. Wie ihr das erklärt habt, so,
das klingt nach einer coolen Architektur.
Die Frage ist, und das haben wir schon mal so n bisschen
angeteasert, läuft das immer so? Ja, funktioniert das immer so?
Und ja, ich glaub man hat es schon n bisschen gemerkt, wir
haben durchblicken lassen, nee funktioniert nicht immer so, nee
Leute sind nicht immer so wirklich überzeugt davon, wenn
man sowas vorschlägt und die Frage ist ja da jetzt ganz klar
warum, ja warum ist das so warum?
Ist vor allem also wo ist das Problem?
Ja, das ist, fangen wir mal damit an, bevor wir zum Warum
kommen, man muss ja erstmal bisschen was lokalisieren, das
bleibt wo liegt das Problem und ich finde das Problem liegt sehr
selten dabei in dem Architekturkonzept.
Klar wir kommen doch dazu, es gibt Fälle wo diese Architektur
wirklich nicht Sinn macht. Aber wenn sie Sinn macht und es
trotzdem Probleme gibt, da muss man sagen, liegt es oft nicht an
der Architektur selbst, sondern daran, wie sie verstanden und
umgesetzt wird. Ne.
Und das ist genau der.es klingt in der Theorie einfach, es
umzusetzen wie du meintest ist schwierig und erfordert sag ich
mal auch oftmals wirklich erfahrene Coder und Coderin
beziehungsweise ein Mix. Ja, das heißt nicht, dass du
jetzt keine Junior Developer dabei haben darfst.
Gar nicht. Das heißt das absolut nicht,
aber man muss zumindestens n paar Leute haben, die ne gewisse
Erfahrung haben in Sachen Architekturen, die auch n
bisschen was erlebt haben schon und wissen wie wichtig das ist,
es konsequent durchzusetzen und nicht nur in den ersten 2
Wochen. Na ja, genau, aber ich find es
auf jeden Fall. Das ist so, also können wir
eigentlich trotzdem gleich mal direkt kurz thematisieren
zumindest also ich hab auf jeden Fall auch schon öfter mal so
gehört, so ja hier, klar, da nimmst du die hexagonale
Architektur und dann ist alles supi ne tolle Sache so ne so n
bisschen sarkastisch halt so, weil dann offensichtlich eben
dahinter stand. OK, das ist halt doch nicht geil
so nach dem Motto hab ich probiert ist voll voll
bescheuert ne und klar. Ist das immer die?
Also ich frag mich dann immer, wie oft hast du es probiert,
weil das ist find ich immer für mich n wichtiger Punkt du setzt
dich ja als Kind auch nicht aufs Fahrrad, fährst einmal los,
fällst hin und denkst dir so Alter was ne Kacke ich bin raus
ja oder was weiß ich stehst das erste Mal als kleines Kind auf,
fällst wieder hin und sagst weißt du was ich krieg den Rest
meines Lebens. Durch die Gegend.
Macht. Also man muss natürlich Übung
reinstecken, klare Sache, aber es kann natürlich auch an
unterschiedlichen Dingen liegen und zwar du meintest ja OK, wann
lohnt sich es nicht, Gegenfrage oder Gegenreaktion, manchmal ist
es ja auch so, dass es so Leute gibt, die sagen, sag mir nicht,
was wir tun. Wir nehmen aber auf jeden Fall
ne hexagonale Architektur und dann hast du halt auch schon mal
n Problem, wo du dann vielleicht Leute davon überzeugst, dass das
Kacke ist. Ne, weil es halt eben überhaupt
nicht passt. Ne, warum es nicht passt.
Gut, das können wir uns noch mal angucken.
Dann aber ja, das ist so dieses typische over Engineering, ne,
also wie sieht das Projekt aus? Weiß nicht genau, vielleicht
wirklich mal NMVP machen, lass mal n ganz kleines
Minimalbeispiel machen. Ja, können wir gerne tun, aber
erstmal hexagonale Architektur. Ich hab hier schon mal 10 Ports
aufgeschrieben, die wir eventuell brauchen und 10
weitere, die wir vielleicht brauchen und Adapter hab ich
auch schon vorbereitet, weil wir müssen ja verschiedene Sachen
dann an die Ports anschließen und verbinden und das ist halt
genau der falsche Weg ne ja das ist so Anti jakni hoch 10 ja
also dann. Erschlag ich ja quasi schon im
Workload alle Coder und Coderin da dran und dann hat schon
keiner mehr Bock da drauf und das entspricht auch nicht dem
Grundgedanken zu sagen, ich bin flexibel und entkoppelt und ich
kann erweitern, reduzieren und anpassen.
Nee, das ist ich hau einfach alles rein, was gerade durch
meinen Kopf geht und hoffe, dass am Ende irgendwas Cooles
rauskommt und kann behaupten ja ich hab ne geile Architektur
verwendet, also es lag nicht an mir, dass das gescheitert ist.
So ne. Aber ich sag mal so, also selbst
wenn es sich lohnt ne und man sagt OK hexagonale Architektur
ist ne gute Sache, würde passen dann braucht man sich trotzdem
ja nicht direkt hinzustellen und zu sagen so jetzt erstmal 10
Ports definieren 20 Interfaces an den Start bringen, so und
eigentlich aber noch gar nicht wissen was das System eigentlich
wirklich kann. Ne ich glaub das ist n häufiges
Problem leider Gottes das hatten wir auch schon öfter mal
angesprochen, dass man sich. Manchmal viel zu wenig über
darüber Gedanken macht, was eigentlich genau passieren soll
im System, teilweise auch geschuldet durch zu wenig
Gedanken, in die Tickets geflossen.
So was soll eigentlich wirklich gemacht werden, was will der
User überhaupt und am Ende hast du irgendein Systemmorloch, wo
du dir eigentlich denkst, so was was war eigentlich noch mal hier
der Sinn dahinter? Ne also es macht Sinn zu sagen
was ist. Ist eigentlich wirklich von
unserem System oder von unserer Anwendung von unserem Produkt.
Was wird wirklich erwartet? So was ist wirklich der Sinn
dahinter und dann kannst du ja ne wie wir auch schon meinten
bestimmte Use Cases davon ableiten und dann vielleicht
anfangen zu sagen, das könnten mal irgendwann Ports werden,
weil das sind ja so Use Cases die sich herauskristallisiert
haben, aber lass uns erstmal mit einem anfangen, ne weil.
Auch selbst dann, wenn du sagst, hexagonale Architektur lohnt
sich ja vor allem auch eigentlich erst dann, wenn du
wirklich sagst, OK, wir haben irgendwie ne fachlogik, ne, also
die irgendwie wirklich, du hast irgendwie ne Business Logik zu
deinem Produkt wo du sagst das ist ne Logik, die verändert sich
nicht, dann kannst du überhaupt erst mal sagen, OK, da könnte
vielleicht irgendwie ne hexagonale Architektur
rausspringen und dann ist noch die Frage, hast du so mehrere
Zugangswege, weißt du also auch von außen musst du mehrere
Adapter anschließen, es bringt dir ja auch nichts wenn du
sagst. Ja gut, wir haben hier n Port,
da kommt immer ein Adapter dran und fertig ist die Laube.
Weißt du Mhm so dann OK, keine Ahnung 1000 Jahren hast du ne
hexagonale Architektur aufgesetzt, aber an jeden Port
schließt ein, also wird ein Adapter angeschlossen.
Ja, das ist halt n großer Punkt. Wenn jetzt zum Beispiel mein
System oder mein Projekt, sag ich mal n einfaches Back End mit
so Crude Operation ist und. Da hängt jetzt nur eine
Datenbank dran, ne kleiner ne, das ist jetzt wirklich n kleines
Projekt und da wird es keine Variation geben, dann brauch ich
das nicht machen ja weil dann wenn ich Anpassung mache ist eh
immer nur der eine Teil betroffen.
Und den muss ich anpassen, wenn es denn in die Richtung geht.
Ja, also wenn ich jetzt zum Beispiel ja an der Datenbank was
anpasse oder an dem Controller oder was auch immer, dann ist es
halt immer diese eine Kette und dann brauch ich das so nicht
aufbauen, dann ist das einfach nur Overhead am Ende.
Ja. Die du nämlich schon meintest.
Wenn ich aber mehrere Schnittstellen hab oder eine
Logik halt für verschiedene Außenweltschnittstellen
bereitstellen möchte, ja wie dein Bankbeispiel zum Beispiel.
Ja, dann, dann kommen wir halt eher in die Richtung und was mir
halt auch, weil ich vorhin meinte, dass die Ports so
unglaublich wichtig sind. Ich find NN absoluter
Stolperstein dabei ist halt auch, dass man genau die Theorie
versteht, ja, dass man sagt ja OK, versteh ich ja, dann hab ich
Ports und da gehen Adapter dran und dann hab ich das alles
entkoppelt easy ja versteh ich. Und dann fang ich an und sag ja
gut, dann haben wir jetzt n Port, das ist jetzt n Rest user
Controller ne und der kann dann irgendwie über die Userdaten was
ändern, abfragen was auch immer immer jetzt zum Beispiel bei dem
Bankbeispiel ich bin da jetzt Kunde ne und das ist halt schon
wieder genau der falsche Weg zu sagen ja der Port also du
definierst jetzt n Port, der heißt Rest user Controller, da
ist schon mal da gehen schon mal die Alarmglocken an weil dann.
Bist du gedanklich wieder komplett in deiner Restwelt
unterwegs und sagst? Ja, wir, wir haben irgendwelche
Rest calls und müssen Rest Endpunkte bereitstellen und was
auch immer ne und das ist ja überhaupt kein Domain driven
Design mehr am Ende und wir haben ja gesagt, im Kern achten
wir auf die Domain und das heißt die Domain ist ja eher sowas wie
ich hab n Kunde ja und ich hab Kundendaten und so also das ist
so das Wording was sich dann. Im Kopf haben muss und nicht
rest User Controller der Rest User Controller ist eher schon
wieder Richtung Adapter, dann am Ende, dass ich sage ich möchte
jetzt meine Rest Schnittstelle an mein Port Kundendaten
anschließen und das über Rest. Weißt du also so muss ich das
betrachten aber viele verschmelzen Port und Adapter
dann nicht auf dem Papier auf dem Papier ist das klar
hingeschrieben ne aber wenn es dann Richtung Software geht und
Umsetzung Implementierung. Dass sie da denn anfangen, moks
zu machen und das nicht klar trennen.
Also dass das im Kopf eigentlich nicht klar getrennt ist.
Ja, du hast dann eher sowas wie Kunde speichern, Kunde laden
oder sowas anstatt n rest user Controller Port ne so nach dem
Motto ich mein. Genau, also wirklich das
fachliche. Was passiert dahinter?
Kurz Daten abfragen beispielsweise.
Genau das Ding ist halt. Man könnte sich jetzt
hinstellen, sagen ja warte mal aber ist Port Port, ist ja nicht
Kern im Kern, soll ja sozusagen diese Business Logik sein und
nicht die Technik reingezogen werden, wieso dann in den Ports,
wieso darf das da auch nicht sein?
Also erstmal hast du ja vom Grundbild her ist ja dieses
Hexagon ne wenn du dir dieses noch mal so in den ins ins
Gedächtnis rufst. Sind die Kanten ja gehören zum
Hexagon ne. Also das ist ja sozusagen, es
ist ja ne, alles andere sind die Adapter die von außen dann
andocken und alles was außerhalb dieses Hexagons ist.
Technik alles was drin ist, keine Technik und demzufolge
muss man sich auch vorstellen, dass ja der Kern genauso diese
Funktionen nutzen muss oder zur Verfügung stellt, dann im
Endeffekt über diesen Port, das heißt der Kern kennt diese
Funktionen und der Kern sollte halt keine Technik kennen, so
fertig ne, das ist halt der Punkt definitiv und.
Da muss man sich dann auch überlegen so kein Port ist nicht
n Interface für jede Klasse, sondern es dient halt für einen
Use Case am Ende ne so kann man das am am schönsten schneiden.
Ich weiß nicht warum ich mir hatte mal n Kollege erzählt, der
hieß übrigens auch Tino, war so einer der auch nettesten
Menschen muss wohl am Namen liegen weiß ich nicht die so
kennenlernen. Durfte bisher.
Es gibt n Paar von uns. Aber ich, also es hat jetzt
vielleicht nicht hundertprozentig was mit
hexagonaler Architektur zu tun, aber ich muss irgendwie immer
wieder daran denken, weil er irgendwann auch mal meinte, du
hast n einen, wenn du zum Beispiel von außen hast NDTO,
das kommt irgendwie in dein System rein, ne und du kannst
theoretisch dieses DTO genauso 1 zu 1 weiterverwenden in deinem
System an sich macht es ja Sinn so, weil du dir denkst, warum
muss ich jetzt noch mal Overhead drauf packen und eigentlich das
mehr oder weniger gleiche Objekt noch mal.
Duplizieren, anders benennen und dann aber irgendwie dann an
einer anderen Stelle verwenden. Und ich fand, eigentlich macht
es, also es klingt erstmal so, ja OK, warum sollte man das tun,
aber und das ist wirklich interessant wenn du sagst du
hast zum Beispiel auf deiner Seite wo du das DTO verwendest
ne ich geh jetzt mal extra von Ports und Adaptern weg, da
möchtest du noch was hinzufügen. Irgendwie was erweitern und du
willst aber noch nicht das komplett in eine gesamte andere
Software die dahinter hängt umsetzen?
Dann hast du trotzdem irgendwo diese diesen diese Trennung
zwischen deinem GTO und deiner Entity sag ich jetzt mal oder
deinem deinem Weiß nicht Business Objekt nenn ich es mal.
Indem du sozusagen es einmal rüber shiftest.
Und du sagst ja zum Beispiel, 5 Attribute kommen auf 5
Attribute. Wenn du jetzt hier 6 hast, dann
sagst du halt OK 5 von den 6 Attributen kommen auf diese 5
Attribute, das heißt du kannst super irgendwas erweitern und
wenn du irgendwas erweiterst außen sag ich jetzt mal, musst
du es noch nicht innen erweitern, das heißt du kannst
Stück für Stück das Ganze aufbauen, du bist halt
entkoppelt ne und ich finde das passt irgendwie auch super dazu
zu diesem, zu diesem, zu dieser hexagonalen Architektur,
irgendwie muss ich mal daran denken.
Fand ich auf jeden Fall. Das Gleiche geht natürlich auch
in die andere Richtung definitiv.
Also du kannst natürlich auch, sag ich mal von nach innen, also
innen in deiner fachlichen Logik sozusagen was anpassen und
erweitern, möchtest aber noch nicht, dass die Außenwelt sich
updaten muss und nicht zwangshaft als zwangsweise oder
nur n Teil. Ja, also da, du bist halt
einfach entkoppelt und frei, das ist n riesengutes Beispiel was
du da n riesengutes Beispiel. Es ist schon.
Riesen Superlative heute sag es ist das Beste, es ist das beste
und deswegen finde ich ist das auch absolut sinnvoll.
Ne man kommt oft an den Punkt, dass man sagt Boah jetzt
wirklich noch ne DTO klasse oder ne Datenstruktur dafür.
Es ist doch genau das gleiche, kann ich nicht einfach das
interne Modell rausgeben, das passt doch ja nee.
Eben nicht beruhigt diese diese, diese sag ich mal.
Abstraktion einbauen ja, diese Entkopplung, um einfach später
diese Möglichkeit zu haben und das Ganze fördert auch deine
Testbarkeit am Ende, was für uns beide auch immer n riesen Punkt
ist, den wir predigen, weil das vor allem n riesen Punkt sein
sollte. Es ist halt auch rediger was
Alter ich. Es ist ja auch unfassbar wichtig
ne hohe Testbarkeit zu ermöglichen und die Architektur
ist sehr gut geeignet dafür, weil was wir ja jetzt sehen ist,
wir haben ne interne Business Logik die definiert also unsere
Architektur definiert wie man sie ansprechen kann und welche
Daten sie anfordern kann, sozusagen nach innen und außen
und wie ich ja anfangs meinte. Genau in diesem Zuge muss auch
deine deine deine Software Abhängigkeit gerichtet sein und
damit schaffe ich es dann halt beispielsweise auch wirklich
gute Tests dafür zu schreiben, weil was man ja jetzt ganz klar
sieht. Ich hab n Port und meine
Business Logik erwartet, zum Beispiel Daten auf diesen Port
die verarbeitet werden sollen und gibt Daten zurück.
So und jetzt kann ich ja ganz einfach sagen Hey ich hab n
Adapter mit der echten Außenwelt aber.
Aber ich kann auch genauso mir nen eigenen Adapter schreiben
für meine Testwelt und den Andocken sag ich mal ne und
schon hab ich ne super testbarkeit an der Stelle.
Ja, definitiv ohne die echte Außenwelt kennen zu müssen.
Ich meine, wie nervig ist das, wenn du kennt, jeder der Tests
schreibt kennt das, denkt sich so EY ist n Judith Test ist
wirklich nur reine Logik, super easy wie geil kann man das
Abtesten und dann kommst du irgendwann an n Test weil
denkst. Ah, da hängt jetzt die Datenbank
mit dran. Wie mach ich das?
Ah, da muss ich ne Menge wegmocken ja noch n Service hier
noch n Service ah OK ich hab jetzt also ich hab die Datenbank
ich hab n Service ich hab noch n Service ah und da geht noch mal
NHTTP Call irgendwie raus und du denkst dir so ah da muss ich
alles wegmocken oh das wird so richtig scheiße und das ist der
Punkt wo du dir denkst ah vielleicht könnte man noch mal n
bisschen was an dem ganzen Kram ändern weil wenn du dir denkst
das ist richtig scheiße testbar da geht noch was.
Das auf jeden Fall. Das ist halt, das ist halt n
unglaublich guter Punkt und richtig guter Pluspunkt, vor
allem bei dieser Architektur, weswegen wir sie auch wirklich
mögen. Ja, also sagen wir mal so, wenn
jetzt jemand sich fragt zum Beispiel ja, OK, ich guck euch
öfter mal auf Twitch zu, da macht ihr mal so kleine Mini
Projekte, hab ich ja jetzt noch nichts von der hexagonalen
Architektur gesehen. Und genau das haben wir ja auch
argumentiert hier verdammt Schande über unser Haus, wir
müssen es machen, nein, weil das halt auch Mini Projekte sind, wo
es dann halt einfach keinen Sinn macht das so aufzubauen.
Aber liebe Zuhörer, lieber Zuhörer, wenn du sagst Ey als
Community Projekt, lass uns das doch mal angucken, lass uns das
mal zusammen umsetzen, lass mal die Pro und Cons daran erkennen.
Dann kann man das auch sehr gerne machen und sich mal n
Beispiel überlegen. Ich denke das gibt auf jeden
Fall richtig Mehrwert. Hätten wir Bock drauf oder Fabi
das mal so als kleiner Appell kann man gerne mal machen und
eine Sache noch zu dem Kollegen mit auch mit dem Namen Tino Ne,
da muss ich jetzt einfach kurz mal auf topic ne Story erzählen,
ich dachte ja immer mein Leben lang, dass der Name recht selten
ist, weil ich komme aus einer Kleinstadt und da kannte ich nur
einen anderen Tino ja. Schon viel.
Dann bin ich so, dann sind wir, haben wir ja zusammen studiert.
In der Stadt gab es noch mal einen OK, das waren dann schon
mal 2 andere in meinem bisherigen Leben, und irgendwie
dachte ich mir immer so, ja, der ist es scheint wirklich selten
zu sein, der Name ne und ich weiß noch, da waren wir
irgendwann mal mit Freunden auf dem Wochenendtrip und saßen so
im Zug und da kam das Thema auf ja, dass n Freund meinte ja dein
Name ist wirklich selten, ich hab noch nie n anderen Kino
kennengelernt, ja. Und auf einmal dreht sich hinter
also auf der Bank dahinter jemand um und sagt ja, also ich
heiße auch Tino und dann hä, das gibt's ja nicht, das ist ja
krass und der da drüben heißt übrigens auch Tino, Nee, komm,
jetzt verarscht du ihn. Und dann saß noch ein dritter
Tino in dem gleichen Abteil drin, und die haben alle ihren
Ausweis gezeigt und ich auch, ich dachte okay, das ist krass,
das sind mehr Tinos von einem Waggon als ich mein ganzes Leben
kennengelernt habe. Aber dann waren alle auch
versammelt in einem Raum, oder? Ja, alle in dem gleichen ja,
also das also die also. Alle Deutschen waren dann dort.
Na, außer die 2, die ich vorher kennengelernt hatte, die waren
nicht mehr. Also es gibt dann insgesamt 7
Ah, OK. Ja, ich glaub mehr gibt es noch
nicht. Pipapo o.
K. Gut auf.
Jeden Fall so am Ende der Folge. Ja, auf jeden Fall so
zusammenfassend ja, um vielleicht noch mal so n tollen
Spruch zu bringen, um das ganze Thema sanft zu fassen.
Mach es nicht kaputt. Jetzt kommt mal ne geile
folgendes hier. Wenn man sagt, so hexagonale
Architektur ne in einer guten Architektur, ja wenn sie
hexagonal ist, kann man Technik löschen, ja ohne dass man
Fachlogik neu schreiben muss, so als kleiner Merksatz vielleicht
am Ende. Ja, schön gut, gut hu.
Ich hatte ein bisschen Angst, aber das war gut, Fabi, das war
sehr gut da, so können wir es stehen lassen, jetzt am Ende,
das heißt, mir bleibt nur noch übrig, mich bei dir zu bedanken
für die Folge, es hat sehr, sehr viel Spaß gemacht, sehr sehr
cooles Thema und noch mal in deine Richtung liebe
Zuhörerinnen, lieber Zuhörer, wenn du fragen hast.
Anmerkung Erfahrung, vor allem auch zu dem Thema, dann lass es
uns bitte wissen, schreib uns eine Mail und oder meld dich auf
dem Discord, wo du möchtest. Du kannst uns auf vielen
Plattformen erreichen, wir würden uns super super freuen
darüber und gehen gerne in den Austausch mit dir.
Alle links in den Shownotes wie immer.
Und wenn dir dieser Podcast gefällt oder du dir jetzt so
denkst, ey cool, jetzt sprechen Sie über Architektur.
Ja, das ist so n so n neuer Bereich, den sie jetzt anfangen
im Podcast richtig geil, da lass doch gerne ne Bewertung da, das
würde uns mega freuen empfiehl den Podcast weiter wenn du
denkst hey hier mein Team ne wir sind ja gerade so am überlegen
Architekturtechnisch die müssen das mal hören dann ruhig
weiterempfehlen. Würde uns mega freuen und.
So die Kirsche auf der Sahne oder irgendwie, so sagt man das
doch, wäre natürlich in den Shownotes findest du n
spendling, wenn du uns damit unterstützen würdest.
Vielen vielen Dank, möchtest natürlich nicht, würdest vielen
vielen Dank dafür und ansonsten hören wir uns alle beim nächsten
Mal wieder. Habt ne schöne Zeit, startet
noch weiterhin gut ins neue Jahr und bis dahin.
Eure Kunden weiß gemeinsam besser.
Ich habe jetzt richtig crock ein neues Creacle Factor.
Genau, ich habe ja schon mal so was, macht die ID auf.
Ich mache ja schon.