Latest / Coding Buddies | Tech & Dev-Mindset / #156 Gute Software muss nicht Hipp sein - Die Schichtenarchitektur

Transcript

#156 Gute Software muss nicht Hipp sein - Die Schichtenarchitektur · Coding Buddies | Tech & Dev-Mindset

0:00
Kennst du das? Du änderst Kleinigkeiten und
0:02
plötzlich bricht dir die ganze Anwendung, dann würde ich sagen
0:04
willkommen in schlecht verstandener
0:06
schichtenarchitektur wir klären heute, was schichtenarchitektur
0:09
eigentlich ist und warum sie in so viel Enterprise.
0:11
Projekten stecken Coding Buddies, Dein Podcast rund um
0:15
Softwareentwicklung und aktueller Tech News herzlich
0:18
Willkommen. Halli Hallo und herzlich
0:32
Willkommen zur neuen Folge des Coding Buddies Podcast.
0:35
Schön, dass du wieder eingeschaltet hast, denn deine
0:39
Gastgeber heute mal wieder wie immer von Anfang an meine
0:43
Wenigkeit, der Tino und der fantastische Fabi Fabi, ich
0:47
begrüße Dich zur neuen Folge was geht ab bei dir?
0:50
Ja, halli. Hallo, was geht, was geht,
0:56
geht's dir gut? Merkst, dass es immer mehr so
0:59
eine Überraschung ist am Anfang, ich sag es immer so ein bisschen
1:01
anders, aber ich verlier nicht meine meine Herkunft, dabei
1:04
weißt du meine Anmoderationsherkunft ja.
1:08
Du bleibst dir treu. Auf jeden.
1:10
Fall, ich bleib dir da einfach treu.
1:13
Also zumindestens die Frage was geht ab, muss sein.
1:17
Ja ich finde wo du mir selten beantwortest was abgeht, aber
1:20
okay ich sag dir was abgeht ja ich hab letztens sag mal was
1:23
geht ab. Habe ich was gelesen, was ich
1:25
irgendwie wieder ganz lustig fand?
1:27
Da ging es darum, dass so AI Agenten es ne Website gibt mit
1:31
so AI Agenten die sich sozusagen nen human buchen können.
1:37
Weißt du da geht es quasi darum, dass du dich anbieten kannst als
1:40
Mensch für Sachen die ne AI ja ohne physischen Körper nicht
1:44
machen kann ne, also ne AI sagt dann so ey ich Buch mir n
1:47
Menschen und damit er das für mich macht OK.
1:53
Das ist krass. Irgendwie.
1:54
Ich hab ich hab jetzt nicht verifiziert ob das wirklich ob
1:57
das stimmt oder nicht. Also ich war jetzt nicht so
2:00
Trust Me Bro oder was ja also Quelle, Quelle, Quelle, Quelle,
2:07
schwieriges Wort, Social Media wollte.
2:09
Ich eigentlich sagen geht ja schon gut los heute.
2:12
Also wie gesagt, keine Ahnung ob das stimmt, ich hab es mir jetzt
2:15
nicht im Einzelnen angeguckt, aber ich finde du kannst mir auf
2:19
jeden Fall sowas erzählen und ich würde sagen ja gibt's
2:21
locker. Locker.
2:22
Heutzutage verwundert mich hier nichts mehr und wenn ich jetzt.
2:25
In 2 Jahren oder so. Ja, ja, es sind ja eh sehr
2:29
witzig. Ich fand auch die ja auch wieder
2:32
Quelle Trust Me Bro, Ich weiß gar nicht wie es heißt, aber es
2:35
gab da irgendwie so ne Social Media Plattform so von AI für AI
2:40
wo AI mit AI über Menschen sprechen kann und so, das fand
2:44
ich auch ganz witzig, den Ansatz aber gleichzeitig auch ziemlich
2:47
erschreckend was da denn so drin war, aber.
2:51
Heute soll es ja nicht um RI gehen.
2:53
Ja, also klar, wir greifen ab und zu Themen auf, es ist
2:57
einfach das Thema in der letzten Jahre und wahrscheinlich auch in
3:01
den nächsten Jahren und soll heute aber nicht unser Thema
3:06
sein, denn heute wollen wir ja mit einer Reihe weitermachen,
3:09
die ja noch gar nicht so alt ist.
3:10
Quasi erst dieses Jahr so gestartet ist und es wird Zeit
3:14
für die nächste Folge und zwar möchte ich heute mit dir.
3:17
Wieder über Softwarearchitekturen reden und
3:20
mir quasi das nächste Pattern, das nächste
3:26
Softwarearchitekturdesign vornehmen und das mal
3:30
ausführlich besprechen, erklären, warum es vielleicht
3:34
schon so n bisschen in die Jahre gekommen ist, warum es aber
3:37
immer noch, sag ich mal irgendwie einen Grund gibt,
3:41
warum es noch im Umlauf ist und das ganze Mal mit dir
3:44
analysieren. Und deswegen möchte ich einfach
3:49
mal mit dir heute über Schichtenarchitekturen sprechen.
3:53
So, und ich glaub jeder der irgendwie in der Informatik
3:56
schon n bisschen länger unterwegs ist.
3:58
Aber nicht nur in der Informatik ja überall gefühlt wird diesen
4:02
Begriff schon mal gehört haben und dem begegnet sein.
4:06
Und woran liegt das eigentlich? Ja, also warum ist
4:09
Schichtenarchitektur immer noch wichtig und das würde ich gerne
4:13
mal so am Anfang mit dir. Beleuchten, denn da braucht man
4:18
sich eigentlich nur mal so den deutschen deutschsprachigen
4:21
Markt angucken. Also gehen wir mal nur so von
4:23
unseren Regionen hier aus, ja dann ist es ja so.
4:27
Wir haben viele Banken, wir haben viele Versicherungen, ne
4:30
starke Industrie war sie zumindestens, wird auch wieder
4:33
denk ich Behörden natürlich jede Menge und halt so unseren
4:39
wohlgeliebten Mittelstand, die Firmen und.
4:44
Witzig ist, dass viele Systeme, die da drin laufen, ja die lange
4:48
laufen, die auch am besten nicht geändert werden sollten.
4:50
Auch gerade bei Banken und so ja oft so Schichtenarchitekturen in
4:55
den Systemen ja n Standard ist. Ne, also das begegnet einem
4:58
immer wieder, sag ich mal. Also ich hatte zum Beispiel
5:01
damals als Hiwi. Zur Studienzeit auch in einem
5:07
Unternehmen gearbeitet, was so Bankensoftware hergestellt
5:10
hatte. Und da war das halt auch so.
5:13
Ja hier schichtenarchitektur und Oh, das werden wir auf gar
5:17
keinen Fall, werden wir da rangehen nein nein nein nein,
5:19
nein, nein, nein, das läuft, das ist robust.
5:22
Wir werden das erweitern. Wir werden das Main Tain, aber
5:24
das Ding bleibt so ne, dann hast du nämlich auch so Rubriken und
5:29
sag ich mal Branchen, wo man halt auch Angst vor Änderung
5:32
hat, ne und dann diese Schichtenarchitektur einfach
5:35
seit Jahren da gelebt wird und trotzdem find ich es halt so
5:42
spannend. Ja das überall begegnet einem
5:45
das und es wird aber trotzdem sehr oft nicht sauber gelebt.
5:49
Also war auch da so n Ding, dass man sich n paar mal dachte, ah
5:53
wär ja schon geil das so und so zu machen.
5:55
Ja, aber das würde aber unsere Architektur reißen, das wäre
5:58
gegen unsere Vorstellung der Architektur ja, aber das würde
6:03
es schon schneller machen jetzt ja, also es könnten wir das
6:06
schnell abhaken, das Thema und deswegen wird auch diese
6:10
Architektur sehr oft gebrochen. Das haben wir schon immer so
6:13
gemacht. Machen wir auch weiterhin so
6:16
das. Brechen, ja.
6:21
Und dann hört man ja auch ziemlich oft und ich denke, das
6:24
kennst du auch. Ja, die Architektur ist schuld,
6:28
ja, warum auch diese Architekturentscheidung, oder?
6:30
Ja, das ist ja auch eigentlich keine richtige Architektur, was
6:33
da was da passiert, ja. Das Schichtmodell jetzt oder was
6:36
meinst du? Schichtenarchitektur ja.
6:41
Ja, kenn ich. Also erstmal will ich ganz kurz
6:43
noch mal sagen es. Krass, dass wir so schnell von
6:46
diesem lustigen Thema, das ich angefangens hier erwähnt hab,
6:50
jetzt auf einmal bei Banken sind OK.
6:52
Ja, ich, wir machen auch gleich noch so n bisschen Investment.
6:56
Talk hinterher. Nee, aber was wollt ich sagen,
7:03
ja, wir machen ja hier auch die Schicht ne, also erstmal
7:05
Begrüßung ja ja dann ins Thema. Ganz genau.
7:10
Also es gibt ja niemals, es geht ja niemals ins Thema ohne eine
7:13
Begrüßung, es muss immer durch die Begrüßungsschicht, richtig.
7:16
Genau. Und das muss aber auch richtig
7:18
gelebt werden. Wie du schon meinst, weil
7:20
ansonsten kommen halt solche Probleme und dann wird es am
7:24
Ende auch wieder auf irgendwie auf die Architektur geschoben.
7:27
Ich kenne es auch oft, dass dann gesagt wird, ja
7:28
schichtenarchitektur ist ja eh scheiße, sollte man gar nicht
7:30
machen, wie wir ja auch immer so schön sagen, es kommt immer ein
7:35
bisschen auch auf den Anwendungspfeil drauf an.
7:39
Aber was natürlich definitiv ein Problem ist, wenn du sagst, du
7:45
hast irgendwie eine Architektur und Schichtenarchitektur und du
7:47
ziehst es nicht richtig durch ne oder machst es nicht sauber,
7:50
dann treten natürlich Probleme auf und das ist natürlich klar.
7:55
Es ist halt Fakt, dass wenn du etwas machen möchtest und das
8:00
dann nicht richtig durchziehst, das Problem auftreten ja also.
8:05
Und das ist. Unter dem Stern stehen ja viele
8:07
Themen, die wir hier besprechen, ja.
8:09
Und das ist aber glaub ich halt, also halt generell das wirklich
8:14
das Hauptproblem, ne dass du sagst OK wir machen das so und
8:16
so und dann die Disziplin Halt eben fehlt es wirklich auch so
8:20
zu machen meistens ja aus ich sag mal bestimmten
8:23
Entscheidungen heraus wie zum Beispiel muss jetzt schneller
8:25
gehen Ach komm mach das erstmal so wir ziehen das später gerade
8:29
so diese typischen Sachen. Aber dann gibt es natürlich
8:33
Probleme, Probleme, die halt eben auftreten.
8:36
Angenommen, du hast jetzt zum Beispiel deine deine Schichten,
8:39
wir gehen jetzt mal ganz abstrakt davon aus und sagen,
8:41
wir haben einfach irgendwie erstmal schichten.
8:44
Ja, die einzelne Verantwortlichkeiten in unserer
8:46
Software haben Mhm und wenn man das natürlich nicht richtig
8:50
macht und sagt, OK, wir haben zwar die Schichten definiert und
8:54
sagen es gibt Schicht, ich nenn das mal 123.
8:57
Und wir kriegen es aber nicht richtig hin, diese Schichten
8:59
auch durchzuziehen und richtig zu trennen.
9:01
Ja, weil man vielleicht erst mal anfängt und dann aber irgendwann
9:04
anfängt zu sagen, Ah, aus Schicht 1, da kann ich aber auch
9:07
schon, ich kann in Schicht 1 auch schon n bisschen was von
9:09
Schicht 2 machen, in diesem speziellen Fall, dann fängt es
9:12
natürlich an, dass so diese Verantwortlichkeiten der
9:14
einzelnen Schichten halt eben verschwimmen.
9:16
Ja, ineinander sozusagen. Ne.
9:18
Also wenn du jetzt sagen wir mal, du hast ne Schicht, die ist
9:22
gelb und eine Schicht ist blau, ja und dann fängt es auf einmal
9:25
an, dazwischen ja sich so ne grüne Schicht zu bilden, die
9:27
eigentlich nicht da sein sollte. Krasse Farblehre beeindruckt
9:31
habe ich gelernt, jetzt voller Mücke, also niemals grün
9:37
dazwischen. Ne, verständlich, das kann man
9:40
sich gut merken, ne? Absolut ja.
9:43
Also ich find es ja auch gut, dass du sagst, lass uns mal
9:45
vorstellen, es gibt so verschiedene Schichten und
9:47
Verantwortlichkeiten, weil das oft dahinter steckt, auch sehr
9:51
technisch gesehen, das muss man auch dazu sagen, ne, dass es oft
9:54
eine technische Umsetzung von Schichten ist an der Stelle und
9:59
genau dieses Verschwimmen ist. Super oft der Fall.
10:04
Also das ist keine Seltenheit, dass vielleicht jetzt manche
10:06
sich denken, ja gut, in der Theorie, ist doch logisch, ja
10:09
ich hab jetzt ne Schicht, die macht das, die hat ne
10:11
Schnittstelle zur unteren Schicht und es geht immer nur
10:14
von unten nach von oben nach unten und wieder hoch und nie
10:18
irgendwie kreuz und quer oder so, aber das wirklich sauber
10:22
umzusetzen und genau das ist das Problem, dass das irgendwann
10:25
nicht mehr der Fall ist. Durch Shortcuts, Abkürzung
10:27
Hotfixes die rein müssen und man sich denkt Boah nee ja ich muss
10:30
das jetzt hier aber erstmal so machen.
10:32
Technische Schuld, die sich aufbaut, gar die ganzen
10:34
Klassiker, die du auch schon angerissen hast, sorgen ja
10:36
dafür, dass Grün entsteht. Am Ende ne ja und ich find gut,
10:41
dass du das direkt als ersten Punkt nennst, weil das genau
10:44
deswegen macht man so Schichten, zum Beispiel um da einfach
10:48
Klarheit zu schaffen, das nicht verschwimmen zu lassen.
10:51
Das und selbst wenn du dir das Team technisch vorstellst, ja
10:55
gehen wir mal davon aus, ich arbeite in einem Softwareprojekt
10:58
mit 3 Teams. Wir, wir machen jetzt keinen
11:02
Aufbau hier, nur einfach mal gedanklich Team AB und C und die
11:07
Software ist so aufgebaut, dass es eine Schicht A, eine Schicht
11:09
b und eine Schicht C gibt, dann kann ich dadurch allein schon
11:13
gewährleisten, dass ich sage, Team A arbeitet natürlich an
11:16
Schicht AB an BC an C. Ob das jetzt sinnvoll ist jetzt
11:19
ein Gedankenbeispiel, aber dadurch kriege ich halt eine
11:22
klare Trennung hin und klare Verantwortlichkeiten und Team a
11:26
weiß genau wie sie mit B reden muss und b weiß ganz genau, dass
11:29
es nur Input von. A annimmt und nicht von C da
11:33
drunter beispielsweise. Also dass du klare Regeln hast,
11:36
dann am Ende ne und doch ohne. Spasteln eigentlich, oder?
11:40
Genau am Ende, ganz genau. Und was bringt das mit sich?
11:43
Nämlich schon ne Verbesserung des klassischen zweiten Problems
11:47
dabei, wartbarkeit ja, also wann?
11:52
Wie kann ich sicherstellen, dass mein System heile bleibt, dass
11:54
es nicht chaotisch wird, dass ich einfach wirklich das Ganze
11:59
betreuen, verwalten kann und auf Kurs halten kann und das
12:03
steigere ich damit auch besser, als wenn ich statt 3 Teams oder
12:07
3 Schichten dann habe ein Haufen jeder macht überall irgendwas
12:11
mal und keiner weiß mehr was wurde gemacht, was wurde nicht
12:13
gemacht, wer redet mit wem, wer kümmert sich darum und genauso
12:18
ist es ja auch innerhalb einer Software, das kannst du jetzt
12:20
auf alles map, das kannst du. Team mappen das kannst du auf
12:23
teamübergreifende Sachen mappen, aber halt auch auf eine
12:26
Softwarearchitektur und deswegen macht man das Ganze damit nicht
12:30
mehr alles kreuz und quer geht am Ende ne aber ich find wenn du
12:33
n wichtiger Punkt. Wenn du wartbarkeit sagst, ich
12:36
find da so n bisschen Erweiterbarkeit kommt da auch
12:38
mit rein, was auch durchaus n Problem sein kann, weil
12:40
angenommen zum Beispiel du hast irgendwie ne arbeitest an einem
12:44
an einem System und hast zum Beispiel n sagen wir mal
12:47
Controller und der Controller nimmt irgendwelche Daten, also
12:50
ne irgendwelche. Objekte an zum Beispiel ne und
12:53
du hast in jetzt in dem Objekt hast du 5 Felder und dieses
12:56
Objekt machen wir mal. Gedankenexperiment ist genau das
13:00
Objekt genau die Entity die du am Ende auch in die Datenbank
13:03
reinspeicherst. Wenn du das hast.
13:05
Und du änderst nur n bisschen was an deinem am Frontend, zum
13:09
Beispiel was diese API oder irgendwie was zum Beispiel Daten
13:12
über n Post oder n Put Endpunkt Reingeben möchte.
13:15
Ne und da kommt n bisschen mehr dazu und du änderst zum Beispiel
13:18
nur im Controller, dann zum Beispiel das willst du irgendwie
13:21
dein deine also n weiteres Feld hinzufügen das sechste.
13:27
Dann kannst du ja diese Anwendung gar nicht weiter
13:29
betreiben, außer du gehst quasi durch deine ganze deine ganzen
13:34
Schichten durch, bis zum Ende, bis zu deiner Datenbank, wo du
13:37
dann am Ende noch ne Datenbank Migration machst, damit du
13:39
dieses sechste Feld drin hast. Ne, das heißt diese diese
13:42
Erweiterbarkeit ist ja dann echt deutlich quasi komplexer
13:47
geworden, anstatt dass du sagst, du hast vielleicht n einzelnes
13:50
Objekt NDTO nur in der zum Beispiel am Controller.
13:53
Wenn wir jetzt da sind, ne und du hast n Entity Objekt und du
13:55
hast vielleicht noch. Ich sag mal domainobjekte, da
13:58
kommen wir gleich noch n bisschen drauf.
13:59
Aber also irgendwo in der Mitte hängen ne, aber dann hast du ja
14:02
quasi und und wenn das nur ja ich sag mal eigentlich die
14:07
gleichen Objekte sind, die aber an unterschiedlichen Schichten
14:10
stehen, ne wie du schon wieder meinst ne also Team A Team B
14:12
Team C hat sein Ne hat seinen eigenen Scope, dann kannst du ja
14:17
im Controller dieses Feld hinzufügen, was ja noch lange
14:19
nicht bedeutet, dass du dieses Feld bis in die Datenbank
14:21
durchziehen musst. Das heißt du kannst erstmal was
14:23
erweitern, musst aber deine Datenbank noch nicht anpassen.
14:27
Das heißt, du kannst es ganz inkrementell Regeln.
14:29
Entspannt. Absolut absolut.
14:32
Und dadurch, dass ich das so machen kann, habe ich auch einen
14:37
anderen sehr guten Benefit dabei und zwar, dass ich auch die
14:39
Testbarkeit damit erhöhen kann und Leute ja testen ist sehr
14:43
wichtig, wir sagen es immer wieder, wir appellieren immer
14:46
da. In die Richtung.
14:47
Aber es ist auch hier natürlich n absoluter Vorteil, wenn ich
14:51
sage, ich habe definierte Schichten, auch das Beispiel,
14:54
was du gerade genannt hast, ne, selbst wenn es nicht komplett
14:57
durchimplementiert ist, was bei Schichten schichtlosen Systeme
15:02
sag ich mal ne, es gibt natürlich auch andere
15:03
Architekturen, aber sagen wir mal wir haben keine.
15:06
Und ich baue das ein. Dann wird es sehr wahrscheinlich
15:08
an allen Stellen klingeln, weil ich die Funktion mit einem
15:11
Parameter zu wenig aufrufe, weil die Funktion im zweiten
15:14
Parameter auf einmal erwartet und so weiter das heißt, es wird
15:18
überall klingeln in der Software und es funktioniert nicht mehr,
15:21
ich kann sie nicht mal mehr bauen, sage ich mal.
15:23
Ja, und das ist halt ein Problem und genauso wenn ich die
15:27
Schichten habe, kann ich sie ja zum Beispiel für eine Schicht
15:29
implementieren, weil ich genau weiß, wie meine Abhängigkeiten
15:33
aussehen wie. Mein Scope ist, was meine
15:36
Verantwortlichkeit ist, und ich kann das auch schon abtesten,
15:39
weil ich die Schnittstellen nach außen kenne.
15:42
Dann kann ich ja quasi mir selbst im Test vorgaukeln, dass
15:46
die anderen das schon erledigt haben und damit umgehen können.
15:49
Das ist ja super. Das ist also besser, geht ja
15:50
nicht, weil dann kann ich genau meine meine, sag ich mal
15:55
Verbindlichkeiten, meine Verantwortlichkeiten umsetzen
16:00
und abtesten, ob das im Gesamtsystem schon verknüpft
16:03
ist, wie du ja meintest, darum geht es ja gar nicht, ich kann
16:06
es ja aber für mich, wenn ich jetzt zum Beispiel Team C bin
16:08
und Team C hat Schicht C und die soll erweitert werden, kann ich
16:11
das machen, ob B das jetzt schon abfragt oder nicht und das ist
16:15
halt ne super Sache am Ende ne. Und gehen wir mal, gehen wir mal
16:19
davon aus, dass dass man testen sollte, ne, das ist wichtig,
16:22
weil das reduziert, sag es noch mal.
16:25
Ich hab es eben schon gesagt, aber sag es noch mal bitte ja
16:27
weil es es reduziert ja die Komplexität der Tests, wenn man
16:30
jetzt keine Tests hat, kann man sich ja hinstellen und sagen
16:32
scheißegal ne aber das mein ich also.
16:34
Nein, nein, Test wichtig noch mal Test sehr wichtig und das
16:41
muss halt auch bei dem letzten ankommen.
16:43
Fabi und ich find das gut, dass wir das nach außen tragen, das
16:45
ist wirklich gut. Wir sagen es nachher noch mal
16:47
OKOK und so n fünften Punkt, da weiß ich nicht wie du dazu
16:54
stehst. Aber ich denke da stimmst du mir
16:56
zu. Ist so ne typische
16:59
Architekturerosion ne das fängt dann irgendwann an so n bisschen
17:03
zu bröckeln das ganze und das fällt dann einfach in sich
17:06
zusammen. Und ich finde, dein Farbbeispiel
17:09
ist so super witzig, weil es stimmt einfach ne, du hast ne
17:12
gelbe und blaue Schicht und warum?
17:14
Wo kommt Grün auf einmal her, warum seh ich n grünen Klecks
17:17
auf einmal auf meinem Software Bild sag ich mal ja genau weil
17:20
das passiert ne dann werden regeln gebrochen dann werden
17:24
Sachen nicht eingehalten es gibt so n Cross Layer Zugriff wie man
17:27
das ja auch gerne mal nennt ne also cross Layer im Sinne von
17:30
ich überspringe Schichten. Und ich gehe auf einmal in die
17:34
falsche Richtung. Es gibt ja so klare Vorgaben,
17:37
wir hatten ja schon zum Beispiel über das hexagonale Architektur
17:41
Pattern gesprochen, was natürlich einen anderen Ansatz
17:43
verfolgt, aber trotzdem ja regeln hat, und genauso hat eine
17:47
Schichten Architektur regeln, und wenn ich diese Aufweiche
17:51
breche, dann habe ich genau den Punkt, dass mir die ganze
17:55
Architektur zusammenbricht und am Ende nur noch auf dem Papier
17:58
existiert. Ich habe irgendwann so viel
18:00
technische Schuld aufgebaut, dass ich eigentlich gar nicht
18:02
mehr von einer umgesetzten Architektur sprechen.
18:03
Sprechen kann. Ja, ich hab es auch schon mal
18:06
erlebt, dass man zum Beispiel, wenn wir jetzt noch mal bei dem
18:09
Controller, wenn wir das Controllerbeispiel noch mal
18:11
ranziehen, dass man einfach aus dem Controller heraus direkt,
18:15
sag ich jetzt mal datenbankenanfragen gemacht hat.
18:19
Ne, also dass man halt wirklich sozusagen diese was heißt, ich
18:23
nenn es jetzt mal serviceschicht oder wie auch immer du das jetzt
18:25
nennen möchtest. Na ja, dass du die einfach
18:26
überspringst, dass du einfach sagst, OK, du kriegst irgendwie
18:28
was an Controller und der fragt direkt dann halt die Datenbank
18:31
an. Was natürlich auch echt Käse
18:34
ist. Ne und dann hast du vielleicht
18:35
auch sogar in dem Beispiel auch noch direkt nicht nur die
18:38
Kopplung der Objekte durch die Schichten sozusagen.
18:40
Was ich vorhin meinte, sondern dann hast du vielleicht sogar
18:44
nicht mal mehr die Schichten dazwischen ne, sondern wirklich,
18:46
also direkt ne Controller auf Datenbank und dann wenn du dann
18:51
noch Logik brauchst, dann packst du die auch noch gleich in den
18:52
Controller rein und dann hast du im Endeffekt einfach genau diese
18:55
Erosion wie du meintest. Du hast eigentlich dann
18:57
eigentlich hast du nur noch ne grüne Schicht am Ende ja.
19:01
Ja, genau. Und dann dann verlier ich halt
19:03
diese ganzen Vorteile oder beziehungsweise die Probleme
19:06
werden wieder real und die Architektur verhindert nicht
19:09
mehr die Probleme, sondern ich hab es soweit aufgeweicht, dass
19:12
ich schon gar keine Architektur mehr hab und absoluter Klassiker
19:16
ist nicht so, ja warum sollte das passieren?
19:18
Ja ich mein in der Theorie klingt immer alles einfach die
19:21
Realität in Projekten wo vielleicht auch Zeitdruck drauf
19:23
ist sieht anders aus und ich denke, dass jeder der halt auch
19:27
im Projektgeschehen schon mal gearbeitet hat wird.
19:30
Da jetzt nicken zu hören, sage ich mal und sich denken.
19:32
Ja, es ist leider so, dass das immer wieder eine Gefahr ist und
19:36
man sich immer wieder selbst disziplinieren muss zu sagen,
19:40
Nein, wir ziehen das jetzt so durch wie du, wie du schon
19:44
meintest. Ja, ich änder in der obersten
19:47
Schicht etwas, das zieht sich jetzt durchs ganze Projekt
19:50
durch, durch alle Schichten, ja gut, ich kann das einzeln für
19:52
mich implementieren, wie wir meinten, aber das heißt ja
19:55
nicht, dass es dann im Gesamtsystem funktioniert, das
19:57
heißt, alle Schichten müssen das implementieren, die Änderungen.
20:00
Und die Anpassung. Und vielleicht ist es eine
20:03
Sache, wo ich mir denke, aber ich kann doch in der obersten
20:05
Schicht doch schon entscheiden, ob das durchgeht oder nicht,
20:08
oder ich kann doch entscheiden, was für Daten zurückkommen, ich
20:11
kann das doch ableiten aus denen, die ich schon habe.
20:14
Ja okay mag sein, dann kannst du vielleicht alleine das ändern
20:18
und das Feature funktioniert erstmal, aber es ist halt
20:20
einfach ein Designbruch an der Stelle, weil es per Definition
20:24
per Regeln durch die Software gehen muss.
20:27
Also du. Du nimmst dir quasi ne
20:29
Verantwortlichkeit raus, die aber nicht deine ist.
20:32
Das ist so. Ich ruf bei einer Hotline an und
20:36
hab irgendwie ne spezifische Frage und ich werd nicht
20:39
weitergeleitet, sondern die Person sagt du weißt du, ich
20:41
glaube das passt schon alles Gute so weißt du, das machst du
20:46
ja auch nicht, sondern du hältst da ja auch.
20:49
Es sind ja am Ende auch Schichten, das geht irgendwann
20:51
in die Fachabteilung, in die Kundenservice Fachabteilung weiß
20:54
ich wohin, bis hin ins Aktenlager, was sozusagen deine
20:57
Datenbank ist, wo deine Akte rausgezogen wird, jetzt ja
21:01
digitale Akte von mir aus ja, also was darf ich nichts, aber
21:07
dann wird doch am Ende nachgeguckt und dann geht doch
21:09
die Info wieder nach oben, sozusagen weißt du, egal ob das
21:13
jetzt digitalisiert passiert oder wirklich einer noch ins zu
21:17
den Akten rennt ne. Ins Lager.
21:21
Aber das ist doch am Ende der Ablauf dahinter und dann kann
21:24
ich ja nicht einfach vorgelagerter außerhalb meiner,
21:28
sag ich mal, Verantwortlichkeit schon Entscheidung treffen, dann
21:31
das mach ich da ja auch nicht und genauso sollte ich es auch
21:33
nicht in der Software tun. Mal kurz sagen sollte man nicht
21:36
tun, manchmal wird es getan, aber wir haben jetzt viel von
21:40
Schichten gesprochen, ganz allgemein Schichten irgendwelche
21:43
Schichten ja 123 ABC, wie auch immer.
21:48
Aber also wir können ja mal so n bisschen gucken, dass wir
21:51
vielleicht so wirklich auf Schichten gehen, die man
21:55
vielleicht auch so kennt, gerade im Schichtenmodell, dass man zum
21:58
Beispiel sagt, so Presentation Layer, application layer domain
22:01
Layer, presistance layer, sowas zum Beispiel ne, und damit man
22:06
sich das vielleicht n bisschen besser vorstellen kann, hast du
22:10
da vielleicht irgendwie ne Analogie aus der Rubrik Essen.
22:18
Du meinst eine klassische Coding Buddies Analogie können wir
22:24
machen, da bin ich so richtig anzuheizen.
22:25
Ja und jetzt wird jetzt geht es wieder los ich hoffe alle sind
22:29
bereit Hunger zu haben jetzt ja lass einfach wieder ein
22:32
Restaurant nehmen, Restaurants einfach unsere klassischen
22:35
Analogien weil sie einfach so gut auf Informatik und
22:38
Softwareentwicklung mappen. Ja, so ne Schichtenarchitektur
22:43
und diese klassischen Schichten, die du gerade genannt hast, da
22:46
geh ich voll mit. Ja, man redet oft von einem
22:47
Presentation Layer, der irgendwie sag ich mal die
22:51
Software nach außen repräsentiert.
22:53
Du hast n Application Layer wo so die Application an sich drin
22:57
ist. N Domain Layer mit so Business
23:00
Logik persistance hast du glaube ich noch gesagt, da steckt
23:04
meistens dann auch so die Repositories mit der Datenbank
23:06
dahinter. Aber wie?
23:08
Wie kann man jetzt sich so n Ablauf vorstellen und ich finde
23:11
da wird jetzt auch noch mal gut ersichtlich, warum man nichts
23:15
überspringt. Ja das könnte man damit glaube
23:17
ich jetzt auch ganz gut darstellen, weil wenn wir uns n
23:19
Restaurant vorstellen, wie sieht das aus?
23:21
Ich als Gast gehe in das Systemrestaurant sagen wir mal
23:26
Software ne setzt mich da an Tisch hab diesen presentation
23:30
layer dass ich ne Karte habe, ich kann gucken das ist ja genau
23:35
das gleiche als hätte ich jetzt. Auf einer Website ne auch
23:39
irgendwie ne Liste an Essen und ich kann darüber bestellen.
23:42
Wie auch immer, jetzt Sitz ich halt gerade im Restaurant, guck
23:45
in die Karte und sag schnitzelpommes heute
23:48
schnitzelpommes ich weiß nicht warum Sitz eigentlich beim
23:51
Italiener keine Ahnung, aber schnitzelpommes so und dann geh
23:56
ich ja nicht los und sag OK schnitzelpommes ich geh jetzt in
24:00
die Küche mach mir schnitzelpommes passiert ja
24:04
nicht was passiert es kommt jemand.
24:07
Und ich kann die Bestellung aufnehmen, zum Beispiel, weil
24:09
zum Beispiel n. Kellner ja und der Kellner und
24:12
diese ganze Koordination, dieser Bestellvorgang, das bildet
24:15
irgendwo ja schon ne nächste Schicht ab, das ist ja gar nicht
24:18
mehr die ich biete, was nach außen hin anschicht, die das
24:22
klärt. Zum Beispiel sieht die Karte
24:24
aus, welche Nummer steckt hinter Schnitzel, Pommes so also es
24:28
gibt dann irgendwie so n wert irgendwas, was ich als Gast
24:31
weitergebe, die 35 bitte zum Beispiel mit Ketchup.
24:37
So und die Application Schicht der Kellner zum Beispiel, der
24:40
weiß jetzt OK 35 mit extra Ketchup und sorgt jetzt dafür,
24:45
dass das so abgearbeitet wird, dass am Ende des Tages, oder ich
24:49
hoffe schneller als am Ende des Tages das Essen wieder rausgeht.
24:53
So ne. Das heißt, dass ich den Gas
24:54
jetzt Schnitzel Pommes mit extra Ketchup gebe.
24:57
Ja. So.
24:58
Aber was passiert dahinter? Der Kellner geht ja jetzt auch
25:02
nicht in die Küche und bereitet das zu, das heißt, da gibt es ja
25:05
anscheinend noch irgendwie ne Schicht.
25:07
Heißt, und da sind wir zum Beispiel dann irgendwann schon
25:10
bei der Domainschicht, die Du genannt hattest, so richtig
25:12
klassisch mit Business Logik, weil Schnitzel, Pommes ist nicht
25:17
in jedem Restaurant, Schnitzel, Pommes, das steckt zwar irgendwo
25:20
grundlegend das gleiche Essen hinter, aber jeder hat ja noch
25:24
sein Geheimnis wie er n super Schnitzel macht.
25:26
Die Pommes werden noch n bisschen anders gemacht.
25:28
Ja, und trotzdem ist es am Ende in Presentation Layer Schnitzel,
25:32
Pommes, das heißt der Kellner geht zur Küche und sagt
25:36
Schnitzel, Pommes bitte die wiederum weiß genau regeln ja
25:42
Business Logik OK ich brauche jetzt keine Ahnung 200 Gramm
25:45
Pommes keine Ahnung ist das viel ist das wenig ich würd sagen OK.
25:50
Ist viel, oder? Also kriegt er aber weil er
25:53
hungrig ist und n großes Schnitzel so und er weiß wie es
25:55
zubereitet werden muss. Was ist der persistance Layer an
25:59
der Stelle persistance Layer Datenbank ja ich hab irgendwo n
26:02
Lager mit Zutaten ich muss natürlich jetzt auch die Zutaten
26:05
holen aus der Kühltruhe, von mir aus ist ja auch irgendwo wieder
26:08
ne eigene Schicht der Zugriff da drauf und so weiter und dann
26:12
geht das quasi von der obersten Schicht runter wieder hoch und
26:15
der Gast denkt sich Schnitzel Pommes geil.
26:18
Freut sich darüber. Wer freut sich darüber nicht,
26:21
aber wie du schon meintest, so, es ist ja also weder der Kellner
26:24
kocht noch der Kellner rennt aber auch nicht ins Lager und
26:27
holt was und bringt es dann dem Koch, sondern das ist ja
26:29
wirklich ne, das wäre dann auch wieder ein Architekturbruch wenn
26:32
du sagst. Das wäre wohl geil.
26:35
Der Kellner geht schon mal los, der weiß ja Pipapo was für
26:37
Zutaten braucht hier Koch übrigens 35 hier hast du schon
26:41
mal das Schnitzel, ja klar. Aber so ne das das wär halt, das
26:47
wär halt nicht das was man sich dann vorstellt.
26:49
Wie gesagt, es passiert halt zu häufig.
26:53
Also in vielen Projekten trotzdem noch, dass es halt sich
26:56
auch mal einschleicht. Ne, es ist ja auch nicht immer
26:58
ganz hundertprozentig offensichtlich, es kann ja auch
26:59
sein, dass vielleicht auch jemand neu ins Team kommt und
27:02
noch nicht ganz das durchblickt hat und so ne dafür ist
27:05
natürlich auch immer gut das ganze nochmal zu reviewen und so
27:07
weiter und sofort, aber die Ursache sei mal dahingestellt
27:11
und genau darauf muss man halt eben achten.
27:14
Dass man eben genau diese Schichten ordentlich halt
27:17
anordnet und ordentlich bespielt.
27:19
Und weil wir jetzt gesagt haben, es gibt jetzt zum Beispiel
27:23
Presentation, application Domain und persistance Layer, OK, es
27:28
sind ja nicht immer nur, also n Layer Architektur heißt ja
27:32
nicht, es gibt jetzt genau diese Layer, es gibt jetzt
27:34
unterschiedliche Layer, ne, es kann ja auch wie gesagt n gelben
27:36
und n blauen Layer geben, kein Grün wichtig.
27:40
Aber ich sag mal, es gibt ja auch andere Beispiele von
27:45
Layern. Ne, also zum Beispiel also ich
27:47
sag mal Praxis Praxisbeispiele wie zum Beispiel ne
27:51
zweischichtenarchitektur ne ist ja dann vielleicht zum Beispiel
27:54
n kleinen Server, kennt man ja zum Beispiel, das heißt du hast
27:58
irgendwie im kleinen vielleicht irgendwie die Oberfläche nur n
28:01
Beispiel jetzt ne Server ist vielleicht dann die Logik
28:04
wiederum und dann deine Daten. Wie wie man es jetzt auch immer
28:08
schneiden möchte, ne. Also zum Beispiel gerade bei so
28:10
Games ist es ja oft so ne, bei Games hast du dann so dies du
28:14
siehst etwas und irgendwo wird was berechnet ne.
28:16
Also wenn du jetzt zum Beispiel dir vorstellst, du hast
28:18
irgendwie so Multiplayer Game und dann hast du zum Beispiel
28:21
als Spieler hast du ja dein Spiel, was ja irgendwie so mehr
28:24
oder weniger der Client ist und synchronisiert wird es dann auf
28:27
dem auf dem Server, das ist ja wie zum Beispiel wir haben ja
28:30
jetzt gerade bei Twitch, sind wir gerade dabei unser Neues
28:34
unseren neuen Programmierwettbewerb zu
28:35
entwickeln. Und da ist es wieder dazu.
28:38
Ja genau, und da ist es ja mehr oder weniger auch so, dass wir
28:43
dann ne Boardschnittstelle anbieten mit Clients.
28:45
Ja, also wir nennen sie auch Clients, die man dann wieder
28:48
implementieren kann und diese Clients können dann sozusagen
28:52
dem Server Daten schicken und der hat dann sozusagen diese
28:55
ganze Logik, wo dann alles verrechnet wird und so weiter
28:58
ne, das ist ja. Genauso, und da kannst du jetzt
29:00
natürlich sagen, OK, innerhalb deines Web Socket Servers, wo
29:04
dann auch das Spiel drauf läuft und so sind vielleicht auch noch
29:06
Schichten irgendwo da mit drin. Möglicherweise ja, aber ich sag
29:12
mal es kommt auf die Größe drauf an, das ist jetzt nicht so
29:15
Großes, eher n Blog, also haben wir Clients ne serverschicht so.
29:20
Ja, ja, und warum macht man das? Ne?
29:23
Warum haben wir das gemacht? Das ist natürlich auch einfach.
29:25
Es bringt halt so oft Vorteile mit sich, dadurch, dass sich
29:28
Schichten klar getrennt sind, dass die aber bei Spielen zum
29:31
Beispiel nicht gescheatet werden, kann am Ende ja.
29:33
Also wenn ich jetzt sage, es läuft alles auf dem Client und
29:37
da wird alles berechnet und das geht dann irgendwie an den
29:39
nächsten, dann kann ich das manipulieren im Prinzip, aber
29:43
wenn ich einfach die. Berechnungen ja, und die Logiken
29:47
auf dem Server laufen hab und der Client sagt mir nur was er
29:51
tut, sozusagen dann hat der Server das in der Hand, dass das
29:54
nicht manipuliert wird. Jetzt gehen wir mal davon aus,
29:56
der ist nicht manipuliert, wenn dann ist er für alle gleich
29:58
manipuliert ne, aber du kannst halt schwieriger betrügen, dann
30:02
einfach an der Stelle und das ist ja auch beim Wettbewerb zum
30:05
Beispiel wichtig ne mal angenommen jeder lässt das bei
30:07
sich laufen und baut quasi das Spiel an sich zugunsten seines
30:11
Bots um. Dann ist das unfair.
30:13
Einfach am Ende des Tages ne und genau deswegen, um auch
30:17
konsistent zu sichern, ist das Halt zum Beispiel jetzt ne gute
30:19
Architektur dafür und kleinen Server hat glaube ich jeder mal
30:23
gehört und kann man halt auch als so Schichten dann betrachten
30:26
an der Stelle, deswegen finde ich das wirklich n cooles
30:28
Beispiel. Ich mein Server, also Server ist
30:31
bei uns natürlich momentan dann, wenn wir es so sehen.
30:33
Der Server läuft dann auf unserem Rechner, aber wir haben
30:35
ja auch schon mal drüber nachgedacht, dass wir sagen nach
30:37
dem Turnier oder so machen wir n Kleinen.
30:39
Also hosten wir das Spiel so ne, dass man das wirklich auf dem
30:42
Server hostet und dann hat man die Möglichkeit eben sozusagen
30:46
auch einfach so aus Spaß seine Bots dann gegeneinander antreten
30:49
zu lassen, auf dem Server, auf dem wir es dann hosten.
30:51
Ne, genau, dass die Clients lokal laufen und dann der
30:54
Spieleserver quasi richtig gehostet ist.
30:57
Und das ist ne coole Sache. Dafür brauchen wir natürlich
31:00
aber n Server, auf dem das quasi deployed werden kann und auch
31:05
läuft. Da möchte ich mal ganz kurz
31:07
Werbung machen. Für, und zwar für unseren
31:09
heutigen Partner Strato. Denn Strato hat zurzeit wieder
31:12
absolute No brainer Angebote, gerade bezüglich Server, denn 1
31:16
ist Fakt ja bei egal welcher Architektur, muss ja auch
31:20
irgendwo das Frontend oder das Backend laufen.
31:22
Und da stellt sich natürlich die Frage, warum nicht direkt auf
31:25
einem Strato Server, denn das bedeutet, dass.
31:27
Deutsche Standorte DSGVO konform und Green Hosting was wir beide
31:32
auch super wichtig finden, steht nämlich auch im Fokus des
31:35
Unternehmens. Richtig, und wenn das jetzt zum
31:38
Beispiel dein erster Server ist, dann passt das auch, denn es
31:40
gibt ein super einsteigerfreundliches User
31:42
Interface, aber du kannst natürlich auch als
31:44
Fortgeschrittener natürlich den Root Zugriff.
31:46
Verwenden und die Strato v Server sind natürlich ideal zum
31:50
Hosten kleiner Projekte oder allgemein deiner Projekte.
31:54
Vielleicht auch das nächste Blockbuster Spiel, was du gerade
31:57
in. Entwickelt, weil wir gerade über
31:58
Spiele gesprochen haben. Wenn du also nicht nur saubere
32:01
Softwarearchitektur bauen willst, sondern auch n passenden
32:03
Server dazu haben willst, dann schau dir auf jeden Fall mal die
32:06
Angebote an. Den Link findest du in den
32:08
Shownotes und damit unterstützt du auch zusätzlich das Coding
32:11
Buddies Projekt ohne Mehrkosten. Werbung Ende.
32:15
Aber man muss natürlich sagen, dass gute Infrastruktur alleine
32:18
ja keine saubere Struktur ersetzt.
32:20
Also man braucht natürlich ne saubere Struktur in der
32:22
Software, das stimmt. Man kann natürlich das ganze
32:25
auch jetzt, weil wir jetzt 2 Schichten hatten.
32:27
Man kann das Ganze natürlich auch noch ein Feingranularer
32:29
machen, zum Beispiel eine 3 Schichten Architektur, wo
32:33
Wunder, vielleicht auch eine 4 Schichten Architektur drosseln,
32:38
aber zum Beispiel jetzt so eine 3 Schichten Architektur um so
32:40
ein Praxisbeispiel zu bringen. Wir hatten ja vorhin auch über
32:44
eine Bank gesprochen oder ein Webportal einer Bank
32:47
beispielsweise, also dass man jetzt zum Beispiel eine
32:50
Presentation hat. Dann die Business Logic und halt
32:53
die Data Schicht. Ne, also dass man wirklich sagt,
32:56
OK du hast einmal das was du siehst ne nach außen präsentiert
32:59
wird. Du hast deine Logik irgendwo und
33:00
du hast deine Daten deine Grundlage von von Daten die du
33:04
hast ne und so also zum Beispiel wenn du jetzt so ne so ne Bank
33:08
hast ne ist es ja auch schön das ganze dann ordentlich zu trennen
33:12
weil wie wir ja schon meinten du willst ja die die Logik ja zum
33:16
Beispiel also weil wir jetzt weil ich jetzt gesagt hatte man
33:18
wir haben so ne Logikschicht so ne Business logikschicht die.
33:22
Die willst du ja zum Beispiel auch nicht in die Presentation
33:24
reinziehen, ne da, da soll ja wirklich nur gesagt werden, das
33:26
und das hast du zum Beispiel auch deinen weiß ich, Kredit
33:29
rahmen nee beziehungsweise wie heißt das hier deine Kreditrate,
33:33
ne, dass du zum Beispiel sagst so ey Zinsen sind gerade so und
33:36
so hoch was weiß ich ne hier kannst du so und so viel sparen.
33:40
Das siehst du im Frontend beispielsweise oder in deiner
33:42
Presentation und gleichzeitig wird aber in der Logik in einer
33:45
Business Logik ja dann im vielleicht diese Regeln werden
33:48
da angepasst und wieviel du aber am Ende wiederum was weiß ich
33:51
auf dem Konto hast oder so, das ist halt ne Sache, die ist
33:54
persistent irgendwo in einer Datenschicht zum Beispiel
33:56
gespeichert ne. Sowas zum Beispiel.
34:01
Ne ja, also oder auch wenn du so n Antrag denn zum Beispiel wenn
34:04
du Kredit meinst ne, dann füllst du ja was da was du in der Hand
34:08
hast ist wie du den Antrag ausfüllst ja, aber wie der
34:11
verwertet wird, wie der wie deine Bonität geprüft wird, ne
34:14
was denn am Ende rauskommt, das hast du ja gar nicht in der
34:16
Hand, das ist nicht deine Schicht an der Stelle ne und da
34:20
da sieht man das auch, dass da so n schichtmodell einfach auch
34:23
auch aus Security Sicht logischerweise absolut Sinn
34:26
macht, ne? Oder, oder wenn bei 3 Schichten
34:30
ja glaube ich denken gerade hier, Grüße gehen raus an alle
34:33
Fronthändler unter uns denken natürlich die Front, die ist
34:37
genau denken natürlich auch viele gleich direkt an sowas wie
34:41
das MVC Pattern, ne was im Prinzip ja auch so 3 Schichten
34:44
hat, dass du sagst MVC Model View Controller.
34:49
Ja, und das ist im Endeffekt auch nichts anderes als aus U
34:54
also mit starkem UI Fokus zu sagen.
34:57
Wie können wir sauber das voneinander trennen?
34:59
Ne was sehe ich, wer verwaltet das wie ich interagiere damit
35:04
und greift quasi auf das unterliegende Modell zu und dann
35:08
ist so ne Schichten Architektur auch halt absolut sinnvoll an
35:11
der Stelle. Damit du das nicht vermischt, ne
35:14
damit nicht der Button selbst sagt Ich wurde geklickt.
35:17
Übrigens gib mir mal die Daten und hier hast du sie weißt du
35:21
das ist ich hab das ja auch nicht da.
35:23
Ich hab das auch schon mal erlebt, weil du gerade sagst
35:25
vermischen und Frontend und so hatte ich auch schon mal da.
35:30
Wenn du jetzt zum Beispiel also angenommen du hast NN Endpunkt
35:33
den du ansprichst, weil du irgendeine Suche machst, ne,
35:34
dann ist zum Beispiel fand ich n ganz spannende n ganz spannendes
35:37
Gespräch mal, dass du zum Beispiel du hast ja die
35:40
Möglichkeit zu sagen, ich frag. Frage die Daten an ne und du
35:45
kannst ja entweder sagen ich schicke jetzt so ne Art Filter
35:48
mit ans Backend und das Backend schickt dir dann im Endeffekt
35:51
anhand dieses dieses Filters die Daten raus oder du fragst alle
35:55
Daten an erstmal und filterst dann im Frontend.
35:57
Ne das ist natürlich dann am Ende n bisschen
36:01
designentscheidung, aber und wie du das machen willst und wieviel
36:04
Daten überhaupt mitkommen ne angenommen du würdest sagen ich
36:06
hole mir immer alle Daten und das sind super viele Daten ne
36:08
dann sollte man sich die auf jeden Fall nicht holen aber.
36:12
Aber rein theoretisch ne. Wenn man jetzt sagt Logik
36:15
trennen irgendwie. Ich finde das ist immer noch so
36:17
ne Logik, die man auch im Frontend haben kann im
36:19
Verhältnis zu die Abfrage darauf, ob dein Username und
36:23
Passwort vielleicht gültig ist oder so oder was weiß ich ne,
36:28
dass du zum Beispiel auch n gültiges Passwort zum Beispiel
36:31
beim Erstellen eines Accounts angibst.
36:33
Und wenn das zum Beispiel im Frontend getestet wird, aber
36:35
nicht im Backend oder vielleicht unterschiedlich, dann hast du
36:38
konntest du dir zwar n Account erstellen mit dem Passwort, aber
36:41
das Passwort kannst du nicht mehr eingeben, weil dieses
36:43
Zeichen zum Beispiel gar nicht mehr erlaubt ist.
36:44
Hinterher oder so ne. Also da muss man halt gucken, es
36:48
ist ja möglich irgendwie auch Logik in natürlich im Frontend
36:51
zu haben, kommt man ja wahrscheinlich gar nicht
36:53
drumherum, aber es ist immer die Frage, gehört es irgendwie mehr
36:55
oder weniger zur Businesslogik dazu oder nicht ne Filterung für
36:59
die Seite muss nicht unbedingt businesslogik sein.
37:02
Wenn wir jetzt noch mal bei Business Business Logik sind,
37:04
beispielsweise, aber bestimmte Dinge sind halt einfach wichtig,
37:08
dass die nicht im Frontend stattfinden, ja.
37:11
Genau. Und ja dann. 4 Schichten würde
37:17
ich noch mal jetzt nennen, weil ich merke gerade wir haben es in
37:20
unseren Analogiebeispiel ja auch schon direkt vierschichtig
37:23
gemacht, weil viele Sachen sind halt so 4.
37:28
End Schichten ja, man kann sich halt immer noch welche
37:31
dazwischen bauen, aber so ne klassische 4 Schichten
37:34
Architektur ist jetzt wirklich nicht selten gerade so auch in
37:37
Backends, wenn man beispielsweise mit Spring Boot
37:42
arbeitet oder cater, also so mit Frameworks, dann sind die also
37:46
ich sag mal Sie zwingen einen nicht unbedingt dazu, aber man
37:49
merkt halt, dass es schon viele Mechanismen gibt, die auch
37:52
darauf aus sind das so zu verwenden, ja.
37:55
Oder ja frontend, weil du Frontend meintest.
37:59
Wenn ich jetzt so mit sowas wie Engular arbeite beispielsweise,
38:02
dann habe ich ja auch so verschiedene Schichten, die mir
38:04
indirekt vorgegeben werden. Ne, dass ich zum Beispiel ne
38:07
Application Service Layer hab beispielsweise oder Components
38:12
die nach außen gehen, ne, also man kriegt es so indirekt halt
38:17
so über Frameworks mit, dann würde ich halt gerade.
38:21
Allein schon Beispiel nur mal ganz kurz, weil es gibt ja
38:23
Annotations, zum Beispiel wie Controller oder Service oder so
38:26
ne, das sind ja. Genau sowas genau und dadurch
38:28
kriegst du ja das sozusagen indirekt mitgegeben, sag ich
38:33
mal. Und da muss ich halt dann immer
38:34
irgendwie an backends denken, wenn ich halt sage, zum Beispiel
38:37
Presentation Layer sind meine Controller mit den Endpunkten.
38:40
Application Service Layer ist denn der Service den ich
38:44
verwende aus dem Controller heraus.
38:46
Der Service hat dann gewisse Logiken, aber sagt am Ende auch
38:50
nur was soll gemacht werden und geht auch nur auf die nächste,
38:54
zum Beispiel den Domain Layer, also die Domain Schicht, dass
38:57
ich dann irgendwann in meiner Business Logik in meinen
39:00
Datenmodellen angekommen bin, was wiederum mehr.
39:04
Auf Repositories zugreift und auf die Datenbank dann
39:07
letztendlich ne. Das heißt dann bin ich schon
39:09
wieder in der Persistance Layer und so weiter und dieser Aufbau
39:14
macht es halt unglaublich robust meiner Meinung nach.
39:18
Es fördert halt auch, dass es robust ist.
39:21
Wie gesagt, Wartbar, Testbar zum Beispiel.
39:24
Ich möchte den Controller testen, ich möchte einfach nur
39:26
wissen, dass wenn. Das und das zurückgemeldet wird
39:30
von meinem Service den ich aufrufe.
39:31
Dann geb ich n 404 zurück oder nen 200 ob der Tester an der
39:36
Stelle jetzt Sinn macht oder nicht, aber ich bin in der Lage
39:39
weil es klar getrennt ist und nicht direkt da auf dem
39:41
Repository oder so zugegriffen wird.
39:44
Den Service zu faken ne also ich bau mir n mog für den Service
39:47
geb dann dementsprechend vor was ich möchte und kann testen ob
39:50
mein Controller das macht, genauso kann ich den Service ja
39:53
auch einzeln abtesten indem ich beispielsweise dann die nächst
39:57
tiefere Schicht mocke und so weiter und das ist ja ne super
40:02
Sache. Dann kann ich das so weit runter
40:04
gehen bis ich sage OK und jetzt gaukel ich nur noch ne Fake
40:09
datenbank vor ne wenn ich ne testdatenbank anbinde oder was
40:12
auch immer also ich kann bin halt in der Lage das einzeln
40:15
alle zu betrachten ja und zu testen und das ist halt auch
40:19
gerade bei Backins einfach ne super Sache ja das wäre halt für
40:22
mich so n klassisches 4 Schichten Modell oder?
40:25
N je nachdem, wie wie einzeln du die dann irgendwann in der Tiefe
40:29
betrachtest, ja. Ja, du kannst es natürlich noch
40:32
weiter ausführen. Auf jeden Fall.
40:34
Also auch hier die Anmerkung, dass wir unser Backend ja auch
40:39
war ja so n Community, wie soll ich sagen, Vorschlag an der
40:44
Stelle ne n Community Vorschlag zu sagen ey guckt euch doch mal
40:48
cator an ne ihr sagt ihr seid mit Springboot unterwegs und
40:51
Springboot haben wir auch viel verwendet vorher aber.
40:54
Lasse einfach mal Cato nehmen, ne schön nativ kotlin, geil
40:58
mögen wir und ist geil geiles Framework, Empfehlung geht raus,
41:03
aber da im Prinzip sieht unser Backend genauso geschichtet auch
41:06
aus ne also dass wir sagen OK ja das Backend hat irgendwo ne
41:11
schichtenarchitektur wir haben zwar noch so n Domain Fokus sag
41:15
ich mal ja also dass wir das ganze Domain.
41:19
Ich würd nicht sagen komplett domain driven betrachten, aber
41:22
schon ne Domain in Vordergrund stellen sag ich mal
41:25
fachlichkeiten abbilden wollen und Schichtenarchitektur an der
41:29
Stelle muss man sagen, das ist ja was wir sagen sehr technisch
41:31
ne. Du hast klare Schnittstellen,
41:33
der darf nur das Aufrufen, der darf nur das Aufrufen, niemals
41:36
in die andere Richtung. Das sind ja so sehr technische
41:38
Sachen, keine fachlichen. Ja, Domain Design schließt er
41:42
jetzt eine Schichtenarchitektur nicht aus?
41:44
Unbedingt. Nee, genau.
41:45
Aber man muss es halt klar differenzieren an der Stelle,
41:49
also dass das eine sehr technisch ist und Domain driven
41:53
ist. Der Ursprungsgedanke ist
41:55
fachlich zu betrachten. Auch hexagonale Architektur um
41:58
mal ne Gegenüberstellung zu bringen ist sehr domain driven
42:01
wir hatten ja auch gesagt, im Kern ist die Business Logic, da
42:04
sind unsere Domain, da sind unsere Fachlichkeiten und dann
42:06
geht es nach außen. Ja, aber also das auf jeden Fall
42:11
der der Fokus ist natürlich dann irgendwo n anderer und trotzdem
42:14
ist es ja nicht so, dass Domain driven Design im.
42:18
Haben wir auch eine Folge darüber gemacht?
42:19
Aber dass es jetzt nicht primär eine Architektur ist, sondern
42:24
halt eben mehr eine Designentscheidung, muss man ja
42:26
auch sagen. Genau weil ich kann ja zum
42:30
Beispiel für jede Fachlichkeit mir diese Schichten aufbauen,
42:32
genau, aber es ist ja natürlich auch so, dass also es hat
42:37
Vorteile, auf jeden Fall sowas zu verwenden, definitiv.
42:41
Es ist natürlich, also es ist, wie wir immer so schön sagen, es
42:45
kommt auf die Sache drauf an, auf die.
42:47
Die auf den einzelnen Fall wann macht etwas Sinn, wann macht
42:51
etwas nicht, denn das ist natürlich aber definitiv auch
42:53
so, dass es durchaus sein kann, dass vielleicht so ein
42:56
Schichtmodell auch vielleicht weniger geeignet ist für etwas
42:59
ne oder für einen Anwendungsfall oder für eine, sagen wir mal, du
43:04
programmierst etwas und kommst dann irgendwann relativ schnell
43:08
vielleicht an den Punkt, dass du sagst, du hast irgendwie dein
43:11
Controller als Beispiel und. Musst irgendwie eigentlich gar
43:16
nichts machen und musst wirklich trotzdem nur an deine Datenbank
43:19
ran und dann denkst du dir so ja gut, aber irgendwie fehlt mir
43:22
jetzt noch eine Schicht, weil wir ja gesagt haben
43:24
schichtenmodell und dann hast du im Endeffekt irgendwie nur so
43:27
eine Art Durchreiche, die dann da stattfindet, also dass du
43:32
sozusagen eine du ziehst per Definition eine Schicht ein, die
43:37
aber eigentlich nur eine leere Hülle ist.
43:39
Ja, und dann macht es halt irgendwie keinen Sinn mehr,
43:42
sowas halt irgendwie unbedingt durchzuziehen.
43:44
Wenn du merkst, so OK, was mach ich hier eigentlich, warum hab
43:47
ich jetzt ne Schicht die macht nichts das.
43:50
Ist n sehr guter Punkt. Also klar, wir haben jetzt
43:52
gesagt, so zum Beispiel Backend, so klassische Architektur oder
43:56
klassische klassische Schichten, die da drin sind, sind die die
43:59
und die und die, ja, und das waren jetzt 4 bis 5, also muss
44:03
ich das machen, die beiden haben das jetzt so gesagt, Nein, so
44:05
ist es natürlich nicht, ne und du hast recht.
44:09
Wenn ich eine Leerhülle habe oder beziehungsweise nur so eine
44:12
Durchfahrtsstraße als Schicht, dann ist das sogar ein Anti
44:16
Pattern, was oft als Think Cole bekannt ist oder beziehungsweise
44:20
benahmt wird, weil es am Ende dann auch nichts anderes mehr
44:23
ist. Ja, also ich baue irgendwie eine
44:25
Schicht ein, aber das sickert einfach nur so dadurch die da
44:28
die Daten uns passiert nichts damit.
44:30
Also wozu ist sie da, wie du ja meintest, wenn mein Backend
44:33
einfach nur. Eigentlich wie n Datenbankserver
44:36
ist sozusagen und ich frag Daten an und ich krieg die Daten und
44:39
da wird nichts mitgemacht, da wird nichts geprüft, da ist
44:41
keine Businesslogic mehr, da brauch ich da auch die ganzen
44:44
Schichten dazwischen nicht. Ja ja, also zumindestens die die
44:47
Application Service Schicht ist fraglich dann.
44:51
Ja genau, und da muss man natürlich dann n bisschen
44:55
challengen, dass man sagt, OK, ist das jetzt geeignet.
44:59
Macht das jetzt Sinn, muss ich das jetzt genauso durchziehen
45:01
oder nicht? Ne das wie gesagt, da muss man
45:03
immer. Genau das ganze Betrachten und
45:05
überlegen, was wann wie wo Sinn macht.
45:09
Was auf jeden Fall oder wo es ja auf jeden Fall gut geeignet ist
45:13
würde ich sagen, wenn man jetzt noch mal guckt, ne, wann macht
45:15
es wirklich auf jeden Fall Sinn, sind halt eben so Business
45:19
Anwendungen mit geschäftslogik ne wenn man sagt Okay zum
45:23
Beispiel du hast ein Backend und du musst nicht nur mehr als
45:29
Daten irgendwie weiterreichen, sondern dass du wirklich eine
45:31
Trennung hast, dass du sagst du. Du hast irgendwie.
45:34
Du nimmst Daten an. Diese Daten müssen vielleicht
45:36
verarbeitet werden, du musst noch irgendwas damit machen,
45:38
hast zum Beispiel so eine Art Service Schicht, die dafür
45:41
sorgt, dass wo die Business Logik vielleicht drin steckt,
45:44
irgendwas wird verrechnet und erst nach der Verrechnung kann
45:47
irgendwas gespeichert werden, dann ist es halt sinnvoll so was
45:51
zum Beispiel zu nutzen. Und da fand ich dein
45:55
Bankbeispiel halt super. Das zeigt das Halt.
45:57
Gut ist auch der Grund, warum ich eine Einleitung gesagt habe,
45:59
es ist in. So vielen Unternehmen noch
46:02
vertreten, weil Bank ist einfach das beste Beispiel.
46:04
Der Kreditantrag, der soll sich ja nicht das Formular ändern
46:08
oder an dass ich andere Daten angeben muss, nur weil quasi die
46:12
Kreditberechnung zinssatzberechnung, ob ich
46:15
überhaupt kreditwürdig bin, wenn sich da Gesetze ändern, regeln
46:18
ändern, was auch immer, dann ist das n Teil der unteren Schicht
46:22
das zu ändern. Ne darunter, dass die
46:25
Kundendaten richtig gespeichert werden oder der Kreditantrag
46:27
soll auch nicht verändert werden, deswegen es geht ja dann
46:30
nur darum, lass mal die Berechnung ändern ob er den
46:32
Kredit kriegt oder nicht und dann will ich ja auch nur eine
46:34
Schicht anrühren und deswegen ist das halt n super Beispiel
46:37
weil das kann man sich gut vorstellen.
46:39
Also ich kreuz ja nicht in meinem Antrag an, aber bitte
46:42
nach 2022 berechnen und nicht die aktuelle oder sowas weißt du
46:46
oder welche welches Gesetz wollen sie denn nehmen dafür?
46:49
Gerade für die. Berechnung weißt du von 6
46:51
passiert ja 118 10 als Gold. Ja, aber das ist halt n gutes
46:59
Beispiel, weil der Rest soll unberührt sein.
47:01
Ich will da keine Änderung machen, nur weil sich quasi n
47:03
Gesetz geändert hat und steuerberechnung sich geändert
47:06
hat, der Zinssatz sich ändert whatever.
47:08
Ja, auf jeden Fall. Das das ist auf jeden Fall n
47:14
wichtiger Punkt. Das heißt, du hast ja vielleicht
47:15
irgendwie so bestimmte, vielleicht auch wenn du so
47:19
Domain regeln hast ne oder Domain regeln ich mein gut ne,
47:22
da hast du ja haben wir wieder das Wort Domain drin, ne dass du
47:25
sagst OK du hast irgendwo ne Business Logik die aber jetzt
47:28
natürlich an einer Schicht verortet ist.
47:31
Und ob du jetzt zum Beispiel sagst, du hast jetzt ne
47:33
hexagonale Architektur oder n schichtenmodell, aber wichtig
47:37
ist ja, dass es trotzdem sinnvoll ist, an der Stelle
47:40
irgendwo zu sagen, dass du deine Business Logik kapselst, egal
47:44
wo. Ja, aber in dem Fall zum
47:47
Beispiel kannst du es halt in einer bestimmten Schicht machen,
47:49
wo du sagst diese Schicht. Auch wenn du zum Beispiel sagst,
47:52
du passt deinen Controller irgendwie an, es kann ja auch
47:55
sein, dass du vielleicht einfach nur unter bestimmten Bedingungen
47:57
andere Rückgabewerte zurückgeben willst, weil du irgendwie aus
48:02
blöder Weise an dem Controller immer gesagt hast, OK, egal was
48:06
passiert, gibt 200 zurück, aber das willst du irgendwie nicht
48:08
mehr machen, weil dein Frontend jedes Mal du machst eine
48:11
Überweisung und jedes Mal kommt. Okay super, wir haben deine
48:15
Überweisung bestätigt, alles klar, super Sache und irgendwann
48:18
kriegst du ein Brief und dann heißt es so, sorry, aber uns
48:21
fehlt nur ein bisschen Geld, weil die Bank halt eben nicht
48:24
sozusagen tritt ne Trennung von den Antworten gemacht hat,
48:28
obwohl die Business Logik halt immer die gleiche ist, ne?
48:33
Ja oder halt wie gesagt, denn die Außenschicht sich ändert ne,
48:36
weil ich halt verschiedene Anbindungen hab, aber die
48:39
Business Logik da drunter die Gleiche ist.
48:40
Dann macht es halt auch Sinn, dass ich sag na gut, wenn ich so
48:43
n architekturmodell hab, dass ich die obere Schicht
48:45
austauschen kann beispielsweise das ist ja auch noch so n Punkt,
48:49
dass ich sage ich hab ne Kernanwendung mit Schichten und
48:52
die Application Layer da oben kann ja zum Beispiel auch mal
48:55
adaptiert werden ausgetauscht werden wie du meintest ne dann
48:58
spricht das halt auch schon ganz klar dafür das so zu machen.
49:01
Ja ja. Aber ich meine, es gibt ja auch
49:04
noch andere Modelle, dass man sagt, OK, also offensichtlich
49:10
kann es ja auch nicht immer geeignet sein, es kann ja auch
49:12
mal vielleicht weniger geeignet sein oder wo man sagt, OK, also
49:14
wenn wir jetzt sagen, ja, also man könnte sich jetzt hinstellen
49:18
und sagen, OK, klingt ja jetzt, klingt ja, kann ich für alles
49:21
benutzen, aber warum gibt es denn noch andere Architekturen,
49:23
weißt du? Also wir haben ja gesagt, robust
49:27
ja. Ich finde, wenn etwas robust
49:30
ist, ist es oft halt auch einhergehend mit starr so n
49:34
bisschen. Und das mein ich nicht negativ,
49:36
überhaupt nicht, weil wie gesagt, wenn du zum Beispiel so
49:39
feste Logiken hast, ne und darüber sich nur Sachen ändern,
49:42
dann ist das genau das was du willst an der Stelle, ja, dass
49:46
du so n richtig krasses Fundament hast und da drunter,
49:48
das ist robust, da passiert nichts so ne.
49:51
Wenn ich aber beispielsweise. Weil wir Domain driven gesagt
49:56
haben. Ja, wenn ich sehr, sehr stark
49:59
domain driven Design umsetze und mein ganzes Projekt darauf
50:03
auslege, sehr stark auf Fachlichkeiten gucke, was habe
50:07
ich für Use cases da, was für Fachlichkeiten, was wie kapselt
50:11
sich mein System überhaupt? Dann haben wir gesagt, so
50:14
hexagonale Architektur, das matcht halt sehr geil dann
50:17
miteinander und dann wäre das vielleicht eine bessere Wahl an
50:20
der Stelle als zu sagen wie. Packe ich jetzt meine Domain
50:27
driven Überlegung, sag ich mal ne, also meine mein fachlichen
50:31
Ansatz in ein technisches Modell, also technisch im Sinne
50:35
von weil man wie gesagt klare Schichten hat, die klar getrennt
50:38
sind und dann und dann diese Regeln gelten, das ist halt
50:42
wirklich sehr technisch und das zum Matchen ist dann halt
50:45
vielleicht nicht immer optimal oder noch besser, wenn ich sage
50:48
es ist so Event driven es gibt ja auch Event driven design, ne,
50:51
dass ich halt wirklich alles. In Events.
50:54
Mir denke, wenn das passiert, dann das das und das.
50:57
Wenn das passiert dann dann das und das und so, ja können wir
51:00
auch mal ne Folge zu machen Event driven ist halt auch
51:03
spannend, dann ist das wahrscheinlich nicht die beste
51:07
Architektur Entscheidung dahinter, weil wie gesagt, dafür
51:10
gibt es ja denn eigene Architekturen auch ja und?
51:14
Je mehr ich das aus diesem, aus dieser Sicht betrachte, umso
51:17
weniger wird denn für mich so ein bisschen die
51:19
Schichtenarchitektur, sage ich mal, als richtige Entscheidung
51:23
gelten. Ich weiß nicht, wie es anders
51:24
sagen soll, nicht, es ist auf jeden Fall nicht falsch, aber
51:27
das zeigt mir so ja vielleicht denn doch in eine andere
51:30
Richtung gucken. Na guck mal, wenn du sagst, du
51:32
hast zum Beispiel so ein auch vielleicht eine ein System, was
51:36
aus vielen einzelnen Services besteht.
51:40
Nur mal, sagen wir mal jetzt ne Microservices.
51:43
Da hatten wir auch mal ne Folge drüber gemacht.
51:47
Wenn du jetzt zum Beispiel angenommen, du hast vielleicht
51:50
so irgendein Service und sagst ey ich möchte aber diesen
51:53
Service, da möchte ich noch n anderen Service benutzen, weil
51:55
du zum Beispiel sagst du hast n System und dieses System damit
51:59
möchtest irgendwie ne Authentication zur Verfügung
52:00
machen, ne zur Verfügung stellen.
52:02
Du möchtest irgendwie, dass du sagst.
52:04
Auf diesem System kann man sich authentifizieren, so, aber es
52:07
muss nicht unbedingt unser System sein, mit dem du dich
52:09
authentifizierst. Du kannst ja zum Beispiel auch
52:11
mit dich mit Google oder Github oder Frami nicht kannst du dich
52:13
halt authentifizieren, gibt es ja manchmal ne sign in with so
52:17
und so, ich hab aber noch nie gesehen.
52:19
Ja und also. Noch mal ganz kurz abschließend,
52:22
da macht es vielleicht Sinn zu sagen, Ey setzt deine einzelnen
52:25
Services auf, dass du quasi deine dein System verteilt ist.
52:29
Aber ich habe auch noch nie gesehen, dass zum Beispiel du
52:31
eine Bank hast, wo es heißt sign in US Google, du willst ja quasi
52:37
nicht Google die Anmeldedaten deiner Bank geben, also
52:41
beziehungsweise dass dass du rein theoretisch, wenn du Google
52:44
hacken würdest, nicht dann oder gehackt werden würde oder
52:48
irgendein anderer Service muss ja nicht jetzt nicht unbedingt
52:50
Google sein, aber. Dass du dann, wenn dieses System
52:52
gehackt wurde, dass dann irgendwie jemand auf deinen Bank
52:55
Account zugreifen kann. Jetzt kann man sich natürlich
52:57
hinstellen und sagen, gut ja, aber wenn ich die Bank Hacke
52:59
klar OK, aber du hast halt einfach diesen diesen diesen
53:03
Hoheitsbereich wo du sagst, OK das ist sinnvoll für diesen
53:08
Anwendungsfall, aber nicht immer ja aber wie gesagt, ich möchte
53:12
mich jetzt zum Beispiel nicht mit Google bei meiner Bank
53:14
anmelden können, möchte ich jetzt nicht.
53:17
Und das ist halt auch das Ding. Ich finde Micro Services absolut
53:21
geiler Vergleich, weil das ja auch so ein bisschen State of
53:24
the Art oft genannt wird, Serverless, Micro Services,
53:27
alles in der Cloud ja, es gibt die Anwendungsfälle dafür, gar
53:32
keine Frage, und die sind gut und das ist geil, dass dass es
53:34
so was gibt, aber wie zum Beispiel eine Bank, eine
53:38
Versicherung, ja oder Behörden auch.
53:41
Klar, ob das jetzt altbacken ist oder nicht, aber es gibt halt
53:44
auch einfach Gründe, warum man auf so n geschlossenes System
53:47
dann zum Beispiel setzt und sagt da, das setzen wir in einer
53:50
Schichtenarchitektur um, das muss robust sein, das muss klare
53:54
Verantwortlichkeiten haben, wie du meintest.
53:55
So ne Hoheit haben dahinter, ja und das ist nämlich genau der
53:59
Grund. Warum?
54:02
Wenn man sich die Frage stellt, ich find die ist n bisschen
54:04
provokant, aber man kann sich ja jetzt hinstellen und sagen ist
54:07
schichtenarchitektur 2026 überhaupt noch zeitgemäß oder
54:11
sollte man das alles einstampfen und neu aufbauen?
54:13
Mal abgesehen davon, dass diese Unternehmen definitiv nicht
54:16
sagen werden, Jo klar machen wir jetzt direkt neu, hatte ich ja
54:18
anfangs das Beispiel gebracht, da hütet man sich ja vor so ne
54:22
krassen Änderungen zu machen ja aber.
54:26
Ist es denn wirklich notwendig oder ist es gar nicht so
54:29
schlecht, was sie machen? Und ich finde sehr gut, dass du
54:32
diese Gegenüberstellung bringst, weil es wie gesagt, was ist eine
54:36
Schichtenarchitektur am Ende, sie ist verständlich, was ja
54:40
auch zum Beispiel für verschiedene Normen und Prozesse
54:42
super wichtig ist. Kann ich das nachweisen, kann
54:45
ich nachweisen, dass es Main tainable ist, dass sie es warten
54:48
kann, es ist Testbar, ist es komplett abgetestet.
54:51
Ist alles nachvollziehbar da drin ne und wenn ich jetzt so n
54:55
Konstrukt nehme und sage ja jetzt mach ich aber mal Tausende
54:57
microservice da draus, ja und das Warten ist die Hölle im
55:02
Vergleich zu dem anderen. Ja wie gesagt Vor und Nachteile
55:05
aber Fakt ist wenn ich so viele Teilsysteme hab müssen die
55:08
einzeln deploint werden, die müssen einzeln maintained werden
55:11
und ergeben zusammen das Gesamtsystem am Ende da hab ich
55:15
einen geschlossenen Bau Baustein sag ich mal der mein System
55:19
abbildet diese Architektur beinhaltet.
55:21
Haltet und da ist einfach alles klar geregelt, auch wenn es
55:24
natürlich irgendwo technisch geregelt ist.
55:26
Ne, aber es funktioniert, es ist robust.
55:28
Ja ja, und damit ist ja auch so, ein bisschen kann man ja auch
55:33
noch mal, ich sag mal zusammenfassend sagen, klar, wir
55:36
haben 2026, es gibt Architekturen wie Microservices,
55:40
Event driven Systeme oder Event driven architectures, was auch
55:45
immer ne domain driven design so, weil es diese ganzen Sachen
55:47
ja gibt, alles. Und trotzdem, aus den Gründen,
55:51
die wir genannt haben, ist es ja durchaus auch sinnvoll und
55:54
wichtig und auch je nach Entscheidung richtig zu sagen,
55:58
dass man vielleicht auch einfach mal ne ganz normale ich nenn es
56:02
jetzt mal ganz normale Schichtenarchitektur verwendet,
56:04
ne? Fakt ist, ist nicht modern,
56:08
wissen wir, ist nicht hip, wissen wir auch, aber manchmal
56:13
so oder weißt du sowas etabliertes, Kerniges, robustes
56:17
ist doch nicht schlecht, oder? Genau.
56:20
In dem Sinne, ich würd sagen wir sind glaub ich auch schon wieder
56:23
zeitlich n bisschen fortgeschritten.
56:27
Können wir die Folge abschließen?
56:29
Hat auf jeden Fall Spaß gemacht. Tino vielen Dank dafür.
56:34
Softwarearchitektur ist auf jeden Fall immer ne wichtige und
56:38
interessante Sache, sollte man sich auf jeden Fall immer
56:40
genauestens durch den Kopf gehen lassen wir.
56:45
Finden es auf jeden Fall spannend.
56:46
Liebe, zuhören, Liebe zuhören, sag auf uns auf jeden Fall, was
56:48
du cool findest beziehungsweise welche softwarearchitekturen
56:51
dich sehr interessieren. Was hast du schon genutzt, was
56:53
hast du vielleicht noch nicht genutzt, worüber möchtest du
56:55
vielleicht unbedingt noch mal ne Folge hören?
56:57
Schreib uns auf jeden Fall, komm gerne dazu auf n Discord,
57:00
schreib uns ne DM, schreib in die Channels, kannst uns auch ne
57:03
Mail schreiben. Oder bei Instagram.
57:06
Frag mich nicht. All diese Links gibt es auf
57:08
jeden Fall in den Shownotes und wenn du sagst ey geiler Podcast.
57:12
Richtig Spaß hat, richtig Spaß gemacht, die Folge zu hören,
57:15
generell den Podcast zu hören und du hast noch nicht eine
57:17
Bewertung da gelassen, dann macht es auf jeden Fall
57:19
unbedingt sehr sehr wichtig, das würde uns mega helfen und
57:23
genauso wenn du jetzt zum Beispiel sagst, Ey meine Güte,
57:26
ist das cool, da möchte ich noch ein bisschen mehr dazu geben.
57:30
Dann kannst du zum Beispiel auch mit einem Kleinen mit einer
57:32
kleinen Spende uns unterstützen. In dem Falle bedanken uns
57:36
natürlich auch ganz recht herzlich und dann würde ich
57:39
sagen, Tino, das war es mal wieder bis zur nächsten Woche,
57:43
deine Kollegin. Gemeinsam besser.
57:48
So, ich werde mich jetzt mal bei dieser Plattform da anmelden,
57:51
die nicht bezahlt werden. Können ja i kriegt dann also AI
57:53
Credits, die ich dann wieder für Proms ausgeben.
57:55
Kann.