WEBVTT

00:00.000 --> 00:07.240
Domainschiffen-Design versteht sich recht gut mit Funktionaler-Pokamierung, was ja auch ein bisschen trendet in den letzten Jahren.

00:07.760 --> 00:14.440
Auf welche Feinheiten muss ich denn achten? Du hast es eben angesprochen, hexagonale Architektur. Wie baue ich meine Services auf?

00:14.960 --> 00:21.440
Das ist ein entscheidender Punkt von Domainschiffen-Design, dass man die Logik ganz klar dann auch mit dem Begriffen zusammenführt.

00:21.680 --> 00:25.160
Das heißt, dass man die Logik für ein Order auf beide Orders selber hat.

00:25.160 --> 00:29.040
Das ist jetzt nur eine Sache und irgendwie klingt das so, als würde noch ganz viel hinterher kommen.

00:29.040 --> 00:31.040
Genau, da gibt es noch ganz, ganz viel.

00:31.040 --> 00:33.040
Revision 556.

01:01.160 --> 01:06.160
Diese Revision wird unterstützt von Demodern.

01:06.160 --> 01:14.200
Demodern ist eine Digitalagentur mit Sitz in Köln und Hamburg und gehört zu den führenden Creative Technology-Agenturen in Europa.

01:14.200 --> 01:24.120
Rund 80 Digitalexpertinnen arbeiten derzeit für internationale Marken und Unternehmen wie Nike, IKEA, SAP, LG oder Mazda.

01:24.120 --> 01:36.720
Demodern wurde bereits mit zahlreichen Kreativpreisen ausgezeichnet. Neben Qualität, Innovation und Kreativität ist Teamwork die Superkraft der Agentur und du kannst bald zum Team gehören.

01:36.720 --> 01:43.320
Gesucht wird ein Full-Stack-Developer bzw. eine Full-Stack-Developerin mit Fokus auf Webmobile.

01:43.320 --> 01:55.320
Du bist dann verantwortlich für die Front- und Backend-Entwicklung interaktiver Projekte, die technische Recherche und Konzeption, aber vor allem für die Weiterentwicklung von Interaktions- und Web-Technologien.

01:55.320 --> 02:01.320
Unterstützt wirst du von einem internationalen Team aus den Bereichen Design, Konzeption und Entwicklung.

02:01.320 --> 02:02.320
Klingt gut?

02:02.320 --> 02:06.320
Dann bewirb dich unter demodern.de.

02:06.320 --> 02:14.320
Vielen Dank für die Unterstützung dieser Revision von WorkingDraft.

02:14.320 --> 02:23.320
Hallo und herzlich willkommen beim WorkingDraft. Wir sind schon in der Revision 556 und diesmal haben wir ein ganz besonderes Thema mit dabei.

02:23.320 --> 02:32.320
Es ist nämlich das Thema Domain Driven Development oder Domain Driven Design, aber bevor wir dahin kommen, sagen wir erstmal, wer mit dabei ist.

02:32.320 --> 02:36.320
Da ist nämlich aus dem Team dabei, die Vanessa, hallo.

02:36.320 --> 02:37.320
Servus.

02:37.320 --> 02:44.320
Ich bin der Hans und wir haben uns einen Gast eingeladen, und zwar den Florian Benz. Hallo Florian.

02:44.320 --> 02:46.320
Hallo zusammen.

02:46.320 --> 02:57.320
Schön, dass du mit dabei bist für die Hörerinnen und Hörer. Vielleicht kannst du dich einmal kurz vorstellen, wer bist du, was machst du so und dann gehen wir auch schon rein in das Thema heute.

02:57.320 --> 03:04.320
Genau. Hallo, ich bin der Florian Benz. Ich bin aktuell VP Engineering by Scalable Capital.

03:04.320 --> 03:09.320
Vielleicht kennst einige von euch schon hauptsächlich bekannt für unsere Broker App.

03:09.320 --> 03:15.320
Und da bin ich jetzt seit acht Jahren dabei, seit 2015. Solange gibt es auch die Firma.

03:15.320 --> 03:31.320
Das heißt, ich habe als erster Mitarbeiter die ganze Entwicklung mitbekommen und kann daher auch so ein bisschen erzählen, was jetzt Domain Driven Design by Scalable heißt, wann wir es eingeführt haben und wie sich das Ganze entwickelt hat.

03:31.320 --> 03:40.320
Und mein Hintergrund ist, ja angefangen habe ich als Java Entwickler, bin dann in die Webentwicklung ein bisschen reingerutscht bei meiner ersten Firma.

03:40.320 --> 03:48.320
Genauer gesagt AngularJS, einer der Gründe, wieso ich bei Scalable gelandet bin und dann haben wir ein Reakt verwendet.

03:48.320 --> 03:56.320
Aber ich habe über die Jahre nicht viel am Webfronten gemacht, aber immer mal wieder ein bisschen was.

03:56.320 --> 04:07.320
Das heißt, ich habe da auch Einblicke, aber hauptsächlich hinten dran Java oder noch über die Jahre Kotlin und dann auch viel bei AWS an der Cloud.

04:07.320 --> 04:20.320
Ja, sehr cool. Also es ist ja auf jeden Fall die Geschichte sozusagen vom Development in die Management Rolle und da dann bei einer Firma, das ist natürlich mega cool.

04:20.320 --> 04:32.320
Und vor allem möchtest du da heute mal auf einen speziellen Bereich eingehen und mit uns darüber sprechen, wie ihr denn bei euch Domain Driven Design eingeführt habt, was ist das überhaupt und so weiter.

04:32.320 --> 04:42.320
Wir haben eine Working-Craft-Revision in, ich glaube, mit der Nummer 314, in der wir mal über Domain Driven Development gesprochen haben.

04:42.320 --> 04:55.320
Das ist halt schon ein bisschen länger her. Jetzt verwende ich diese Begriffe Domain Driven Design und Domain Driven Development so irgendwie fast synonym, aber weiß gar nicht, ob das eigentlich so okay ist.

04:55.320 --> 05:05.320
Deswegen vielleicht an dich Florian, erst mal die Frage, was ist denn eigentlich Domain Driven Design und wie unterscheidet sich es dann auch vielleicht vom Domain Driven Development?

05:05.320 --> 05:17.320
Also Domain Driven Design ist ein sehr breites Feld. Das heißt, ich versuche es jetzt mal aus meiner Sicht zu beschreiben und im Deutschen ist es am besten mit der Fachlichkeit übersetzt.

05:17.320 --> 05:27.320
Das heißt, man versucht praktisch den Fachbereich einer Firma mit der Entwicklung zu kombinieren.

05:27.320 --> 05:36.320
Das fängt bei einfachen Sachen an, indem man zum Beispiel dieselbe Sprache verwendet und nicht die Entwickler jetzt hingehen und die Sachen irgendwie benennen.

05:36.320 --> 05:41.320
Das hört sich erst mal offensichtlich an, ist in der Praxis aber relativ schwer.

05:41.320 --> 05:48.320
Das heißt für mich auch für den Entwickler, dass er sich damit auseinandersetzen muss, was baue ich da eigentlich, was heißt das jetzt?

05:48.320 --> 06:00.320
Und was ich aus meiner Erfahrung sagen kann, man denkt sich als Entwickler was okay, das könnte so und so heißen in meinem Code, aber das ist oftmals nicht der korrekte Fachbegriff.

06:00.320 --> 06:15.320
Und hört sich jetzt vielleicht blöd an, aber dann zu lernen, was ist wirklich der korrekte Fachbegriff, wenn man zum Beispiel im Finanzbereich ist, wie nennt man das in der Wehrpapier-Abwicklung genau das Ding?

06:15.320 --> 06:18.320
Sich da reinfuchsen ist ganz schöne Arbeit.

06:18.320 --> 06:22.320
Und Domain Driven Design hat so mehrere Themen.

06:22.320 --> 06:27.320
Das heißt erst mal praktisch das Ganze verstehen, was man da überhaupt bauen will.

06:27.320 --> 06:31.320
Und da gibt es dann halt eben auch mehrere Verfahren, die angewendet werden.

06:31.320 --> 06:34.320
Da kommt es halt wie Event Storming zum Einsatz.

06:34.320 --> 06:39.320
Und dann gibt es natürlich die Punkte, wie man es dann konkret umsetzt.

06:39.320 --> 06:47.320
Die meisten Entwickler werden schon das eine oder andere davon schon mal gemacht haben, aber Domain Driven Design fasst halt eben alles so schön zusammen.

06:47.320 --> 06:55.320
Das heißt es gibt wirklich dann Muster, wie baue ich meine Klassen, wie setze ich es dann zusammen.

06:55.320 --> 07:01.320
Aber auch wenn ich jetzt mehrere Services habe im Backend, wie interagieren die?

07:01.320 --> 07:03.320
Was gibt es da für Muster?

07:03.320 --> 07:07.320
Das heißt, das ist sehr breit.

07:07.320 --> 07:17.320
Und wenn ich mich jetzt nicht vertue, ist das das Buch zu dem Thema, was den Begriff auch so richtig etabliert hat von 2003.

07:17.320 --> 07:23.320
Also auf jeden Fall vom Eric Evans, der sich halt eben hingesetzt und hat gesagt, okay,

07:23.320 --> 07:27.320
wir haben jetzt so viel darüber gesprochen, ich schreibe das jetzt mal alles zusammen.

07:27.320 --> 07:31.320
Und natürlich, wie jedes Thema entwickelt sich das Thema auch enorm weiter.

07:31.320 --> 07:36.320
Das heißt, bis das dann verbreitet hat und so dauert,

07:36.320 --> 07:43.320
und mittlerweile haben die meisten Entwickler es schon mindestens schon mal den Begriff irgendwo gelesen oder gehört,

07:43.320 --> 07:46.320
aber viele haben es auch noch nicht umgesetzt.

07:46.320 --> 07:52.320
Und dann ist die Hauptfrage, und das war auch unser Problem, ich habe jetzt das Buch gelesen,

07:52.320 --> 08:00.320
ich habe das auf einer Konferenz angehört oder ein Podcast gehört, aber wie setze ich das jetzt konkret um?

08:00.320 --> 08:05.320
Und das ist erstaunlich schwer, weil die Sachen hören sich erst mal offensichtlich an,

08:05.320 --> 08:12.320
das macht Sinn, aber wie ich es dann konkret umsetze, ist dann schon eine andere Herausforderung,

08:12.320 --> 08:15.320
an der wir auch ganz schön zu knabbern hatten.

08:15.320 --> 08:23.320
Auch wenn man sich extrem viel vorher schlau gemacht hat, ist es dann in der Praxis doch extrem schwer.

08:23.320 --> 08:28.320
Ich hätte da gleich eine konkrete Frage zu der Namensgebung.

08:28.320 --> 08:36.320
Das klingt sinnvoll, allerdings habe ich gleich den ersten Stolperstein, wenn wir zum Beispiel über etwas reden

08:36.320 --> 08:43.320
und wir wissen noch nicht, wie es im Produkt wirklich benannt wird oder wir haben da erst so einen temporären Namen.

08:43.320 --> 08:48.320
Das ist ein extremer Beispiel, das andere extremer Beispiel, irgendwann muss es geändert werden.

08:48.320 --> 08:54.320
Nennen wir einfach mal, wir haben da eine Textarea und sie ist für uns quasi immer in der Description gewesen,

08:54.320 --> 09:01.320
in der Beschreibung, nennen sie aber quasi in der UI zu Instructions Instruktionen um.

09:01.320 --> 09:08.320
Sollte das dann wirklich auch heißen, wir benennen auch wirklich das Feld in der Datenbank um zu Instructions

09:08.320 --> 09:14.320
oder geht man dann mit der Description weiter und müssten dann eher die Produktleute und Editorinnen

09:14.320 --> 09:18.320
eher weiterhin Description sagen, damit wir da die gleiche Sprache haben

09:18.320 --> 09:22.320
oder habe ich hier ein völliges falsches Beispiel und das meint man eigentlich gar nicht damit?

09:22.320 --> 09:27.320
Das ist ein super Beispiel, weil es auch direkt die Schwierigkeiten aufzeigt.

09:27.320 --> 09:32.320
Meine Antwort aus der Erfahrung, umbenennen, weil was passiert, wenn man es nicht umbenennt?

09:32.320 --> 09:40.320
Nach fünf Umbenennungen hat man dann fünf Begriffe und dann muss man immer im Kopf praktisch das Mapping machen.

09:40.320 --> 09:44.320
Das heißt, man muss das immer zuordnen und dann hat man irgendwann das Hauptproblem.

09:44.320 --> 09:50.320
Der Entwickler sagt was, jemand anders, der der Product Owner versteht was anderes,

09:50.320 --> 09:55.320
der Business Analyst wieder was anderes und schon hat man riesen Missverständnis

09:55.320 --> 09:59.320
und die Frage ist halt immer, wie einfach lässt sich so was umbenennen.

09:59.320 --> 10:03.320
Wenn ich jetzt einfach eine Klasse im Code habe, nehmen wir mal Datenbank außen vor,

10:03.320 --> 10:11.320
ist es ja einfach, die meisten IDEs, das meiste Toolding sagt einfach okay, Refacting umbenennen, ich bin durch.

10:11.320 --> 10:18.320
In der Datenbank umbenennen ist meistens schwierig, also weil das nicht so einfach vorgesehen ist

10:18.320 --> 10:23.320
und man in den meisten Fällen irgendein komplexes Verfahren wie Parallel Change machen muss,

10:23.320 --> 10:30.320
wo ich mache eine neue Spalte hinzu, schreibe gleichzeitig in beide Spalten und löchtern die Alte

10:30.320 --> 10:34.320
und der Aufwand lohnt sich meistens nicht.

10:34.320 --> 10:41.320
Da gibt es dann aber auch Muster, wie man das Ganze dann besser machen kann,

10:41.320 --> 10:47.320
zum Beispiel indem man den eigentlichen Code, die Logik von der Datenbank stärker isoliert,

10:47.320 --> 10:54.320
so dass ich es in meinem Code umbenennen kann, es aber in der Datenbank gleich benannt bleibt

10:54.320 --> 11:00.320
und dadurch die Altlast auf die Datenbank beschränkt ist, was natürlich auch nicht perfekt ist,

11:00.320 --> 11:07.320
aber viel, viel besser als wenn ich halt eben dann auf einmal fünf Versionen im Code habe.

11:07.320 --> 11:12.320
Das Problem mit wie benenne ich Sachen, die sich irgendwann ändern, ob wir es noch gar nicht wissen,

11:12.320 --> 11:15.320
da weiß ich auch nicht die perfekte Lösung.

11:15.320 --> 11:21.320
Aus meiner Erfahrung ist es so, wenn ich jetzt den Projektnamen im Code einführe, bleibt er da.

11:21.320 --> 11:25.320
Man geht nicht am Ende hin, also zum Beispiel, man hat ein Projekt, was noch nicht öffentlich sein darf

11:25.320 --> 11:32.320
und verwendet dann irgendein Code-Namen, dann entscheidet man sich meistens dazu, okay, der Code-Name bleibt

11:32.320 --> 11:39.320
und man schreibt irgendwo hin, hey, in unserer Firma gibt es die Code-Namen, die heißen das und das, fertig.

11:39.320 --> 11:43.320
Ja, ich meine, das ist ein ganz guter Punkt, irgendwie, wie kommt man zu Benennungen?

11:43.320 --> 11:50.320
Ganz viele Sachen sind ja in so einer Firma einfach durch Prozesse jahrelang irgendwie dann schon eingeschliffen.

11:50.320 --> 11:54.320
Da haben schon irgendwelche Namen, aber klar gibt es auch die neue Entwicklung.

11:54.320 --> 11:59.320
Soweit ich weiß, gibt es ja auch im DDD so einige Möglichkeiten,

11:59.320 --> 12:06.320
wie man zum Beispiel gemeinschaftlich sich auch Namen erarbeitet, also sei es jetzt über spezielle Events oder ähnliches.

12:06.320 --> 12:10.320
Da würde mich auf jeden Fall mal interessieren, wenn du uns ein bisschen erklären kannst,

12:10.320 --> 12:18.320
wie habt ihr das Thema denn neben der Theorie dann auch bei euch im Unternehmen in die Praxis umgesetzt?

12:18.320 --> 12:27.320
Wir haben angefangen ganz klein in einem Team und da haben wir natürlich die so Sachen nicht wirklich gemacht.

12:27.320 --> 12:31.320
Wir haben es aber mittlerweile, weil es sich so etabliert hat in der Firma,

12:31.320 --> 12:39.320
haben wir wirklich Events-Dorming-Workshops gemacht, wo wir unseren externen Trainer dazu geholt haben

12:39.320 --> 12:44.320
und das kann ich so weit wie nur empfehlen, ist natürlich muss man erstmal durchbekommen in der Firma,

12:44.320 --> 12:49.320
dass man jemand extern dazu holt, aber jemand extern, der damit schon Erfahrung hat

12:49.320 --> 12:55.320
und auch so der unabhängige Raum ist, der mal sagt, ich stelle jetzt hier die Regeln auf

12:55.320 --> 13:01.320
und ihr macht das jetzt mal, ist viel einfacher, als wenn sich jemand intern den Hut aufsetzt.

13:01.320 --> 13:07.320
Und dann ist es manchmal gar nicht so einfach, die richtigen Leute in einen Raum zu bekommen.

13:07.320 --> 13:11.320
Das heißt, das ist auch so ein Prozess in der Firma zu sagen,

13:11.320 --> 13:19.320
okay, alle verstehen, wie wichtig das Thema ist und sind deswegen bereit, da mal so ein Tag in so ein Workshop zu gehen,

13:19.320 --> 13:24.320
wo sich alle an einen Tisch setzen und dann sagen, okay, wir haben jetzt eine große Weise,

13:24.320 --> 13:27.320
wann wir versuchen, jetzt unser Produkt zu verstehen.

13:27.320 --> 13:31.320
Und als wir so weit waren, ging es auch nicht darum, was Neues zu entwickeln,

13:31.320 --> 13:37.320
sondern wir holen unser bestehendes System und gucken mal, was passiert da alles.

13:37.320 --> 13:43.320
Also wir fragen mal alle möglichen Leute in der Firma von Operations zu Product, zu Engineering,

13:43.320 --> 13:47.320
was passiert überhaupt? Was gibt es überhaupt für Prozesse?

13:47.320 --> 13:53.320
Und dann haben wir halt eben das Ganze geordnet und in mehreren Iterationen immer wieder drüber gegangen,

13:53.320 --> 13:58.320
okay, wie könnte man das jetzt kopieren und dann halt eben auch benennen?

13:58.320 --> 14:04.320
Weil wenn man dann zusammen da sitzt, merkt man auch, okay, die Leute verwenden nicht unbedingt denselben Namen.

14:04.320 --> 14:10.320
Und so entwickelt sich das Ganze dann, weil dann kommt jemand halt eben, der aus der Finanzbranche kommt und sagt,

14:10.320 --> 14:16.320
ja, das hat den Begriff. Ah, wusste ich gar nicht, wieder was gelernt, macht absolut Sinn.

14:16.320 --> 14:23.320
Weil sonst denken sich die Leute irgendwas aus und die anderen verstehen es nicht.

14:23.320 --> 14:30.320
Und ich kenn's aus unserer Codebase. Es gibt Kernsachen in der Firma,

14:30.320 --> 14:35.320
wo über die Jahre die Entwickler zehn verschiedene Begriffe verwendet haben.

14:35.320 --> 14:41.320
Es gibt halt immer wieder den Punkt, wo einer sagt, okay, ich will's irgendwie genericher machen,

14:41.320 --> 14:45.320
oder ich weiß es besser, ich benenn's jetzt anders.

14:45.320 --> 14:50.320
Deswegen sind wir jetzt bei neuen Projekten wirklich dazu übergegangen.

14:50.320 --> 14:55.320
Diesen Kernteil von Domain Driven Design, man nennt's dann Ubiquitous Language,

14:55.320 --> 15:01.320
die einheitliche Sprache wirklich einfach auf einer Wiki-Seite runterzuschreiben.

15:01.320 --> 15:10.320
Das heißt, die ganzen Fachbegriffe so runterzuschreiben, dass alle sie kennen und verstehen und die auch verwenden.

15:10.320 --> 15:14.320
Bei uns ist der Feld schon mal eine Schwierigkeit weg, die Unternehmenssprache ist englich,

15:14.320 --> 15:18.320
das heißt, wir verwenden die Begriffe eins zu eins so im Code.

15:18.320 --> 15:24.320
Es ist dann schon komplexer, wenn die Unternehmenssprache Deutsch ist, der Code aber auf englich,

15:24.320 --> 15:29.320
und dann die Entwickler anfangen, das selber zu übersetzen.

15:29.320 --> 15:34.320
Weil dann ist es oftmals auch nicht die beste Übersetzung.

15:34.320 --> 15:40.320
Die Alternative, die ich schon gesehen hab, war dann wirklich die deutschen Begriffe im Code zu verwenden.

15:40.320 --> 15:49.320
Was das nicht ganz so einfach ist, wo ich aber auch leider nicht sagen kann, wie das gut zu lösen ist,

15:49.320 --> 15:57.320
bei uns ist halt eben dadurch vereinfacht, dass wir als Unternehmenssprache englich haben und dadurch halt eben alles einheitlich auf englich verwenden.

15:57.320 --> 16:05.320
Was du sagst, finde ich sehr, sehr wichtig, das Thema Ubiquitous Language und dann halt dokumentiert zu haben.

16:05.320 --> 16:12.320
Ich glaube, gerade für so ein Newcomer beispielsweise, die eine Firma beitreten,

16:12.320 --> 16:14.320
irgendwie da einfach so ein Verzeichnis zu haben.

16:14.320 --> 16:21.320
Ach, wenn die Leute, ich sag jetzt mal, die Startseite sagen, meinen die in der App immer die Startseite.

16:21.320 --> 16:30.320
Okay, weil da ist es relativ eindeutig, aber es gibt ja so verschiedene Punkte, die in jeder Firma erstmal zu erlernen sind

16:30.320 --> 16:35.320
und das dann als Verzeichnis zu haben, als Glossary hilft total.

16:35.320 --> 16:41.320
Und wenn es dann halt an den Code geht, da sich drüber zurechtzufinden und das dann in den Code einfließen zu lassen,

16:41.320 --> 16:43.320
ist, denke ich, sehr sinnig.

16:43.320 --> 16:48.320
Was ich mal erlebt habe, ist, wenn es dann deutsche Begrifflichkeiten gab oder mehrere Begrifflichkeiten für ein

16:48.320 --> 16:54.320
und das Gleiche hat man sich meistens auf irgendwie eine Sache geeinigt und hatte dann das einfach auch mitdokumentiert,

16:54.320 --> 17:03.320
so dass man dann wie so ein Nachschlagewerk halt mit dazu hatte, das hat sich bei uns in der Vergangenheit ganz gut bewährt.

17:03.320 --> 17:06.320
Vanessa, rüber zu dir.

17:06.320 --> 17:14.320
Die deutschen Begrifflichkeiten hatte ich auch mal in einer Web App, die tatsächlich Produkte verwendet hatte.

17:14.320 --> 17:17.320
Für die es keine englischen Übersetzungen gab.

17:17.320 --> 17:23.320
Und da hat es dann ganz einfach wirklich so funktioniert, dass diese Produktnormen auf Deutsch, aber da gestern tatsächlich Englisch,

17:23.320 --> 17:28.320
da wäre vielleicht ein Risiko gewesen, dass es sich durchschlängert ist, aber einfach nicht passiert.

17:28.320 --> 17:33.320
Ich schätze mal, in der Finanzbranche wird es alle Begrifflichkeiten auch auf Englisch geben.

17:33.320 --> 17:36.320
Oder habt ihr Produkte, die einfach nur mit deutschen Namen existieren?

17:36.320 --> 17:41.320
Aber ich denke, ihr seid auch eine internationale App und nicht nur auf dem deutschen Markt.

17:41.320 --> 17:49.320
Die meisten Begriffe schon, aber es gibt natürlich das komplexe deutsche Steuerrecht

17:49.320 --> 17:54.320
und gewisse Regulatorik, wobei das ist mittlerweile auch einfacher geworden.

17:54.320 --> 18:01.320
Die Regulatorik, die für uns gilt, zum Beispiel von der BAFIN, die gibt es auch auf Englisch.

18:01.320 --> 18:06.320
Natürlich ist die deutsche Version bindend, aber es gibt dann eine offizielle Übersetzung.

18:06.320 --> 18:08.320
Also das ändert sich schon über die Jahre.

18:08.320 --> 18:13.320
Also vor ein paar Jahren gab es das noch nicht, aber das ändert sich.

18:13.320 --> 18:20.320
Ein guter Punkt war eben auch, wenn jetzt jemand neu in die Firma reinkommt oder ein Projekt, dass er dann praktisch so eine Seite hat.

18:20.320 --> 18:24.320
Und das gilt nicht nur für praktisch nur Übersicht, sondern auch, wenn er in den Code geht.

18:24.320 --> 18:31.320
Jetzt zum Beispiel bei einem Proker, ich will eine Order aufgeben, ich will Apple kaufen.

18:31.320 --> 18:36.320
Wenn man dann einfach in den Code reingehen kann und es da eine Klasse gibt,

18:36.320 --> 18:45.320
oder über ein Thema die ganze Funktionalität dann entdecken kann, das macht das für einen neuen viel, viel einfacher.

18:45.320 --> 18:51.320
Jetzt hört sich das vielleicht offensichtlich an, aber ich kann aus der Erfahrung auf viel, viel Gegenbeispiele,

18:51.320 --> 18:58.320
da gibt es da vielleicht eine Order, aber das ist dann das, was in der Datenbank abgespeichert ist und hat nicht viel mit der Logik zu tun.

18:58.320 --> 19:06.320
Das heißt, dann gibt es dann den Order-Service, den Order-Validator, irgendein Pre-Processor oder sowas.

19:06.320 --> 19:10.320
Und dann ist das eben über die ganze Codebasis die Logik so verteilt.

19:10.320 --> 19:18.320
Und das ist ein entscheidender Punkt von dem Mainchiffen-Design, dass man die Logik ganz klar dann auch mit dem Begriffen zusammenführt.

19:18.320 --> 19:23.320
Das heißt, dass man die Logik für eine Order auch bei der Order selber hat.

19:23.320 --> 19:30.320
Um das zu erklären, fängt man best mit dem kleinsten Baustein an und das sind Value-Objects.

19:30.320 --> 19:33.320
Ein gutes Beispiel ist Geld.

19:33.320 --> 19:41.320
Wenn man jetzt einfach Geld irgendwo als Entwickler irgendwo hinzufügt, kann man ja einen Feld hinzufügen

19:41.320 --> 19:49.320
und am besten verwendet man jetzt keinen Client-Commat-Methic-Alla-Flow-Double, sondern ein Java-Ware-Big-Decimal,

19:49.320 --> 19:55.320
um sich die Zahl richtig darzustellen und dann fügt man es halt irgendwo in der Klasse hinzu.

19:55.320 --> 19:59.320
Gut, was ist mit der Währung?

19:59.320 --> 20:01.320
Ja, jetzt habe ich meine Klasse da.

20:01.320 --> 20:04.320
Das ist eine Order und das steht halt irgendwo in Betrag dran.

20:04.320 --> 20:09.320
Und dann kann man halt eben noch einen Feld und String hinzufügen, Currency.

20:09.320 --> 20:13.320
Und über die Zeit gibt es halt eben noch einen Betrag.

20:13.320 --> 20:18.320
Vielleicht ist es eine andere Währung und dann hat die Klasse auf einmal mehrere Zahlen

20:18.320 --> 20:20.320
und mehrere Währungen.

20:20.320 --> 20:23.320
Und das muss man irgendwie zusammenordnen.

20:23.320 --> 20:29.320
Und das, was bei Domain-Trip-Design halt eben dann beworben wird, sind Value-Objects.

20:29.320 --> 20:32.320
Das heißt, ich führe Sachen, die zusammengehören zusammen.

20:32.320 --> 20:35.320
Das heißt, ich habe zum Beispiel eine Klasse Money.

20:35.320 --> 20:39.320
Die hat dann Zwingen, einen Betrag und eine Währung.

20:39.320 --> 20:47.320
Und die Währung, das kann jetzt auch wieder ein Value-Object sein, was einfach dann Currency heißt.

20:47.320 --> 20:51.320
Und wo es sicher sein kann, dass, wenn das ein Currency-Objekt ist,

20:51.320 --> 20:55.320
das auch nur eine valide Währung drin ist.

20:55.320 --> 21:00.320
Das ist auch das, was viele Leute so schon hier und da machen,

21:00.320 --> 21:05.320
ohne explizit Domain-Trip-Design zu verwenden, indem sie statt einem String

21:05.320 --> 21:09.320
oder einem Integer berechtlichen Wrapper drum herum machen,

21:09.320 --> 21:12.320
um der ganzen Sachen schönen Namen zu geben.

21:12.320 --> 21:15.320
Und das hat extrem viele Vorteile.

21:15.320 --> 21:19.320
Nicht nur von der Benennung her, das geht auch Richtung Sicherheit.

21:19.320 --> 21:22.320
Wenn ich auf einmal sicherstelle, dass die Währung,

21:22.320 --> 21:26.320
zum Beispiel nur so ein drei Wustam-Isocode ist,

21:26.320 --> 21:31.320
dann kann da keiner mehr bösartige JavaScript reinschreiben.

21:31.320 --> 21:36.320
Das heißt, man hat damit ganz viele Sachen auf einmal erschlagen.

21:36.320 --> 21:38.320
Und es ist natürlich viel einfacher zu verstehen,

21:38.320 --> 21:42.320
weil auf einmal habe ich dann halt eben alles zusammen.

21:42.320 --> 21:45.320
Und wenn man das Ganze dann konsequent so weitermacht,

21:45.320 --> 21:50.320
ist es auch viel, viel klarer, wo kommen die Sachen in meinem Code hin.

21:50.320 --> 21:54.320
Weil sonst ist immer die Frage, in welcher Klasse füge ich das jetzt hinzu,

21:54.320 --> 21:57.320
weil das in irgendeiner Utility.

21:57.320 --> 22:00.320
Aber wenn ich auf einmal eine Money-Klasse habe

22:00.320 --> 22:05.320
und ich brauche irgendwelche Utility-Sachen wie Runden

22:05.320 --> 22:07.320
oder gibt mir das mal schön aus,

22:07.320 --> 22:11.320
kann ich das einfach als Funktionen auf der Money-Klasse machen.

22:11.320 --> 22:15.320
Und wenn ich das alles schön zusammen habe,

22:15.320 --> 22:17.320
lässt sich auch schön testen,

22:17.320 --> 22:22.320
weil das ist ja erstmal nur eine Klasse mit wenigen Feldern,

22:22.320 --> 22:26.320
die idealerweise auch unveränderlich ist.

22:26.320 --> 22:29.320
Das ist ja auch ein Punkt, der immer beliebter wird,

22:29.320 --> 22:32.320
dass man nicht mehr jedes Feld verändern kann.

22:32.320 --> 22:35.320
Und viele Sprachen machen es einem mehr heutzutage

22:35.320 --> 22:38.320
auch viel einfacher, das so zu machen.

22:38.320 --> 22:43.320
So, jetzt bin ich schon ziemlich tief da unten reingegangen in die Muster.

22:43.320 --> 22:47.320
Was wäre denn das, du hast, glaube ich, die Value-Objekts,

22:47.320 --> 22:49.320
während das die kleinste Sache.

22:49.320 --> 22:51.320
Aber es gibt noch mehr Muster,

22:51.320 --> 22:53.320
oder es ist jetzt nur eine Sache,

22:53.320 --> 22:56.320
und ich klingt das so, als würde ich noch ganz viel hinterherkommen.

22:56.320 --> 22:58.320
Genau, da gibt es noch ganz, ganz viel.

22:58.320 --> 23:00.320
Wir verwenden auch lange nicht alles.

23:00.320 --> 23:05.320
Das heißt, Value-Objekts sind Sachen ohne eigene Identität.

23:05.320 --> 23:09.320
Das heißt, das sind einfache Sachen wie Geld, eine Farbe.

23:09.320 --> 23:11.320
Und jetzt, gerade zum Beispiel bei Farben,

23:11.320 --> 23:15.320
wenn man jetzt ans Wett denkt mit CSS,

23:15.320 --> 23:19.320
da gibt es ja auch X-Möglichkeiten, Farben darzustellen und so was.

23:19.320 --> 23:21.320
Ich habe sowas auch mal modelliert.

23:21.320 --> 23:23.320
Und wenn man das so baut,

23:23.320 --> 23:25.320
kann man sich auch viel einfacher was machen,

23:25.320 --> 23:29.320
was nur einen gültigen Zustand hat,

23:29.320 --> 23:31.320
indem man praktisch nur sich immer überlegt,

23:31.320 --> 23:33.320
okay, was darf ich überhaupt?

23:33.320 --> 23:38.320
Sonst hat man irgendwie die RGB-Codes irgendwo

23:38.320 --> 23:41.320
und schreibt dann ganz viel Code, um sicherzustellen,

23:41.320 --> 23:43.320
dass wirklich nur die Sachen drin sind.

23:43.320 --> 23:46.320
Wenn ich aber beim Erstellen von meiner Farbe

23:46.320 --> 23:48.320
schon eine Reckix drüberlaufen lasse,

23:48.320 --> 23:51.320
weiß ich, ich habe nur gültige Farben in meinem System.

23:51.320 --> 23:54.320
Die nächste Ebene drüber sind Entities.

23:54.320 --> 23:58.320
Das sind jetzt Sachen, die eine eigene Identität haben,

23:58.320 --> 24:00.320
üblicherweise eine ID,

24:00.320 --> 24:03.320
wie zum Beispiel ein Benutzer im System.

24:03.320 --> 24:07.320
Jeder Benutzer, jeder Kunde ist etwas Eigenes.

24:07.320 --> 24:11.320
Und Entities setzen sich normalerweise aus einer ID zusammen

24:11.320 --> 24:14.320
und einem Haufen Value-Objects.

24:14.320 --> 24:17.320
Und darüber kann man auch schon ein bisschen die Frage beantworten,

24:17.320 --> 24:19.320
was es jetzt für meine Entity zu groß wird,

24:19.320 --> 24:23.320
weil ich soll ja auch alle Logik in der Klasse haben.

24:23.320 --> 24:25.320
Und wenn es zu groß wird,

24:25.320 --> 24:27.320
dann kann man sich entweder überlegen,

24:27.320 --> 24:30.320
macht die Entity noch so Sinn

24:30.320 --> 24:34.320
oder habe ich nicht genug Value-Objects rausgezogen.

24:34.320 --> 24:39.320
Zum Beispiel aus einem Kunden kann man ja X-Unterbereiche rausziehen

24:39.320 --> 24:42.320
und die lassen sich dann auch viel besser isoliert testen

24:42.320 --> 24:45.320
und abbilden im Code.

24:45.320 --> 24:47.320
Und es hat dann wirklich den Vorteil,

24:47.320 --> 24:51.320
ich gucke mir dann den Kunden an, die Klasse

24:51.320 --> 24:55.320
und verstehe, darf ein Ausgehen, alle Logik, die da drauf ist.

24:55.320 --> 24:58.320
Was wir jetzt schön ausgespart haben ist,

24:58.320 --> 25:01.320
wir reden jetzt nicht über APIs, Datenbanken und so was,

25:01.320 --> 25:03.320
das ist noch ein separates Thema für sich,

25:03.320 --> 25:05.320
das ganze trennt man am besten,

25:05.320 --> 25:09.320
indem man die ganze Logik separat schreibt

25:09.320 --> 25:14.320
und die Domain-Logik praktisch wirklich als reiner Code hat.

25:14.320 --> 25:17.320
Das heißt, ohne Großabhängigkeiten,

25:17.320 --> 25:20.320
weil es dann ganz einfach zum Verstehen macht,

25:20.320 --> 25:23.320
weil ich muss mir keine Gedanken über APIs oder Datenbanken machen,

25:23.320 --> 25:25.320
das ist natürlich viel einfacher zu testen.

25:25.320 --> 25:28.320
Ich brauche ja nur Unit-Tests

25:28.320 --> 25:31.320
und brauche dann aber wieder Schichten,

25:31.320 --> 25:36.320
die mir das ganze in die API übersetzen oder in die Datenbank.

25:36.320 --> 25:43.320
Wenn ich jetzt mehrere Entities habe, die zusammengehören,

25:43.320 --> 25:45.320
dann spricht man von Aggregate.

25:45.320 --> 25:48.320
Das heißt, man sagt jetzt normal, eine Entity,

25:48.320 --> 25:50.320
was wäre jetzt ein Beispiel?

25:50.320 --> 25:54.320
Man hat einen Kunden und der hat eine Adresse, die zum Kunden gehört.

25:54.320 --> 25:58.320
Ich will aber, dass die Adresse vom Kunden nur über den Kunden geladen wird,

25:58.320 --> 26:00.320
dann kann man das Ganze als Aggregate machen und sagt,

26:00.320 --> 26:04.320
der Kunde ist aber praktisch die Wurzel von dem Ganzen noch nicht.

26:04.320 --> 26:06.320
Ich lade es nur über den Kunden,

26:06.320 --> 26:10.320
was auch schon wieder dann Probleme eliminiert,

26:10.320 --> 26:13.320
indem man jetzt die Adresse nicht mehr einfach so laden kann.

26:13.320 --> 26:16.320
Sonst ist es so, ich schreibe mir mal so eine SQL Query,

26:16.320 --> 26:19.320
lade es aus der Datenbank irgendwo meinen Code

26:19.320 --> 26:22.320
und verarbeite irgendwo ganz anders im Code die Adresse,

26:22.320 --> 26:26.320
weil das Marketing, die jetzt braucht, für irgendeine andere Anforderung.

26:26.320 --> 26:32.320
Das kann man damit dann auch abfrühstücken.

26:32.320 --> 26:35.320
Wenn man es jetzt noch ein bisschen komplexer macht, gibt es Services,

26:35.320 --> 26:40.320
wenn man eben Probleme hat, das Ganze so abzubilden,

26:40.320 --> 26:43.320
wenn man irgendwelche Prozesslogik drum herum hat,

26:43.320 --> 26:46.320
haben wir extrem selten.

26:46.320 --> 26:50.320
Dann Factories, um sich Entitäten zu erstellen,

26:50.320 --> 26:54.320
wenn die Logik fürs Erstellen selber zu komplex ist.

26:54.320 --> 26:57.320
Und dann geht es halt eben auch schon darum,

26:57.320 --> 27:01.320
okay, wir reden jetzt meine Services miteinander.

27:01.320 --> 27:02.320
Vielleicht ein bekanntes Beispiel,

27:02.320 --> 27:03.320
wo man auch gar nicht sagen muss,

27:03.320 --> 27:05.320
dass es jetzt aus dem mainstream Design kommt,

27:05.320 --> 27:07.320
ist ein Anti-Corruption Layer.

27:07.320 --> 27:11.320
Ich verbinde mein System mit einem externen Anbieter.

27:11.320 --> 27:14.320
Das ist die Frage, lasse ich den externen Anbieter

27:14.320 --> 27:18.320
meinen System dektieren oder baue ich eine Schicht rein,

27:18.320 --> 27:21.320
die das alles übersetzt.

27:21.320 --> 27:24.320
Wie vieles, es hört sich erst mal offensichtlich an,

27:24.320 --> 27:27.320
aber wenn man es nicht explizit macht, passiert es verdammt schnell,

27:27.320 --> 27:32.320
ist dann doch irgendwie der externe Anbieter irgendwas macht,

27:32.320 --> 27:34.320
man es dann nicht übersetzt.

27:34.320 --> 27:37.320
Und wenn der externen Anbieter es dann ändert,

27:37.320 --> 27:40.320
man dann gezwungen ist, sein halbes System zu ändern.

27:40.320 --> 27:43.320
Und so gibt es in dem mainstream Design ganz viele Muster,

27:43.320 --> 27:46.320
wie können jetzt Systeme zusammenarbeiten?

27:46.320 --> 27:48.320
Natürlich ist das Einfass,

27:48.320 --> 27:51.320
da immer sie sind möglichst getrennt

27:51.320 --> 27:55.320
und interagieren halt eben nur über klar definierte Schnittstellen.

27:55.320 --> 27:59.320
Es gibt aber auch viel komplexere Sachen.

27:59.320 --> 28:03.320
Davon haben wir aber, also die kann ich gar nicht alle so genau beschreiben,

28:03.320 --> 28:06.320
weil wir sie selber nicht im Einsatz haben.

28:06.320 --> 28:09.320
Auch ein wichtiger Punkt von dem mainstream Design,

28:09.320 --> 28:11.320
es ist quasi so ein riesen Topf,

28:11.320 --> 28:15.320
aus dem man sich die Sachen rausnehmen kann, die man braucht.

28:15.320 --> 28:19.320
Was aber gut ist, wenn man den Begriff explizit verwendet ist,

28:19.320 --> 28:23.320
dass man diesen riesen Topf hat, weiß okay, was kann ich nehmen,

28:23.320 --> 28:26.320
was macht Sinn und halt eben auch auf die Erfahrung

28:26.320 --> 28:29.320
von vielen Leuten zurückgreifen kann.

28:31.320 --> 28:35.320
Was ein wichtiger Begriff ist, ist Bounded Context.

28:35.320 --> 28:38.320
Und zwar, wie schneide ich mein System?

28:38.320 --> 28:42.320
Ich habe eben gesagt, okay, da sind irgendwelche Services, die miteinander reden.

28:42.320 --> 28:46.320
Ja, wie bestimme ich jetzt, wohin gehört in meinem System?

28:46.320 --> 28:52.320
Und genau wie wir am Anfang überhaupt mal die Begriffe zu bekommen,

28:52.320 --> 28:56.320
kann man über so Verfahren wie Events Dorming auch rausbekommen,

28:56.320 --> 28:59.320
okay, wie schneide ich mein System?

28:59.320 --> 29:02.320
Ist das jetzt zum Beispiel das Onboarding von einem Kunden?

29:02.320 --> 29:04.320
Das hat wahrscheinlich nicht mehr viel zu tun

29:04.320 --> 29:06.320
mit dem späteren Leben vom Kunden

29:06.320 --> 29:10.320
im Kündigungsprozess oder irgendwelche Sachen, die der Kunde macht.

29:10.320 --> 29:14.320
Und so kann man eben dann Sachen im System schneiden,

29:14.320 --> 29:18.320
was man normalerweise eh schon macht,

29:18.320 --> 29:22.320
um es möglich zu machen, dass unterschiedliche Teams dran arbeiten.

29:22.320 --> 29:26.320
Aber wenn man sich das überlegt, okay, wie macht das Sinn von der Business Sicht,

29:26.320 --> 29:30.320
hat man wahrscheinlich das System so geschnitten,

29:30.320 --> 29:34.320
dass es langfristig mehr Sinn macht.

29:34.320 --> 29:37.320
Weil was wir aus der Vergangenheit kennen, ist,

29:37.320 --> 29:39.320
ja, die Entwickler haben sich Gedanken gemacht,

29:39.320 --> 29:44.320
oh ja, das System so, das kommt dahin, dahin, das macht so ungefähr Sinn.

29:44.320 --> 29:47.320
Und dann kommen in der Zukunft halt eben Änderungen,

29:47.320 --> 29:52.320
die dann immer drei Services auf einmal betreffen.

29:52.320 --> 29:58.320
Oder das Team wird auf einmal auf andere Software gesetzt.

29:58.320 --> 30:02.320
Also, weil es halt eben von den Business Anforderungen so ist,

30:02.320 --> 30:05.320
dass es da einfach nicht mehr so viel gibt.

30:05.320 --> 30:10.320
Und dass man einfach die Teams, so wie sie vom oben gesehen wurden,

30:10.320 --> 30:14.320
gar nicht zur Software-Astruktur gepasst haben.

30:14.320 --> 30:18.320
Da gibt es ja auch Converse Lord, was sagt das,

30:18.320 --> 30:23.320
so wie man in der Firma miteinander redet,

30:23.320 --> 30:26.320
so entwickelt sich auch die Software.

30:26.320 --> 30:28.320
Das heißt, wenn man als Start-up wächst

30:28.320 --> 30:31.320
und die Leute immer noch extrem viel miteinander reden,

30:31.320 --> 30:34.320
und das war dann auch irgendwann unsere Schwierigkeit,

30:34.320 --> 30:38.320
dass man geguckt hat, okay, wie schneiden wir das jetzt besser?

30:38.320 --> 30:40.320
Ja, den Trick, den werde ich mir gleich merken.

30:40.320 --> 30:43.320
Ich denke auch, das, was du vorhin noch gesagt hattest,

30:43.320 --> 30:47.320
mit externen Systemen und jetzt Libraries,

30:47.320 --> 30:49.320
ich denke, das ist auch so ein Klassiker,

30:49.320 --> 30:51.320
den man als erstes mal lernt.

30:51.320 --> 30:54.320
Wir haben zum Beispiel Century, das haben wir wegkapsuliert

30:54.320 --> 30:57.320
in den Monitoring-TS-Datei.

30:57.320 --> 31:02.320
Century hat tatsächlich, glaube ich, diese Funktionsnamen nie geändert.

31:02.320 --> 31:04.320
Ich glaube, es ist immer noch Capture-Exception,

31:04.320 --> 31:06.320
aber nur, um sicher zu gehen,

31:06.320 --> 31:08.320
verwenden wir nur unseres eigenes Monitoring,

31:08.320 --> 31:10.320
das unterm Strich, dann wird Century aufruft.

31:10.320 --> 31:12.320
Ich weiß leider nicht mehr, wenn man Major-Lib,

31:12.320 --> 31:14.320
aber irgendwann ist es mir passiert,

31:14.320 --> 31:17.320
dass die eben den Funktionsnamen geändert hatte und ich stand da.

31:17.320 --> 31:19.320
Klar, jetzt ist es wie es Code

31:19.320 --> 31:21.320
und es ist tatsächlich irgendwie nur ein Command-F gewesen,

31:21.320 --> 31:24.320
aber sehr oft ist es nicht so einfach.

31:24.320 --> 31:27.320
An was ich jetzt gerade noch gedacht hatte,

31:27.320 --> 31:31.320
du hattest die Beispiele mit so umbenennen und Klassen.

31:31.320 --> 31:33.320
Hin und wieder habe ich schon das Gefühl,

31:33.320 --> 31:35.320
dass wir in der aktuellen Fronten-Entwicklung

31:35.320 --> 31:38.320
das Problem haben von Komponenten

31:38.320 --> 31:40.320
und vieles von Komponenten

31:40.320 --> 31:43.320
kann man jetzt für mich in dem Hinblick schon wie eine Klasse anziehen.

31:43.320 --> 31:46.320
Da merkt man auch, das hätte man schneiden sollen.

31:46.320 --> 31:48.320
Diese Logik hätte man rausziehen sollen.

31:48.320 --> 31:51.320
Man hätte vielleicht diese Farbberechnung nicht in der Komponente,

31:51.320 --> 31:54.320
die auch noch den Button am Ende rendert,

31:54.320 --> 31:56.320
sondern vielleicht einfach in der Utile-Function-Auslage

31:56.320 --> 31:58.320
und dann hätte die getestet werden können,

31:58.320 --> 32:00.320
wäre schon durch abgeschnitten.

32:00.320 --> 32:02.320
Aber mit dem umbenennen,

32:02.320 --> 32:06.320
ich weiß gar nicht, ob wir wirklich gute Tools in IDEs

32:06.320 --> 32:08.320
oder Text-Ideaturen haben,

32:08.320 --> 32:17.320
wenn ich z.B. eine React-Komponente-Description-Label genannt habe

32:17.320 --> 32:22.320
und jetzt vielleicht eine Property habe wie Require-Description

32:22.320 --> 32:24.320
oder ähnliches

32:24.320 --> 32:27.320
und irgendwo woanders steht noch mal Description.

32:27.320 --> 32:30.320
Ich weiß gar nicht, ob ein Tool wirklich klug genug ist,

32:30.320 --> 32:34.320
dass wenn ich sage, ich benenne jetzt die Datei um in Instruction-Field,

32:34.320 --> 32:37.320
das ist mir auch vorschlägt, willst du auch die Property

32:37.320 --> 32:40.320
von Require-Description zu Require,

32:40.320 --> 32:42.320
was auch immer ich gerade gesagt hatte, umbenennen.

32:42.320 --> 32:44.320
Entweder ich kann es nicht

32:44.320 --> 32:47.320
oder ich hatte das Problem noch nicht wirklich,

32:47.320 --> 32:49.320
weil wir machen eher den Zug,

32:49.320 --> 32:52.320
wir bleiben immer beim allerersten Namen.

32:52.320 --> 32:56.320
Ich versuche auch vehement dieses Fünf-Namen zu verhindern,

32:56.320 --> 32:59.320
indem wir einfach beim ursprünglichen Namen bleiben.

32:59.320 --> 33:01.320
Es gibt aber auch ein Problem,

33:01.320 --> 33:04.320
wenn man da tatsächlich mit dem Produkt berückspricht

33:04.320 --> 33:06.320
und da habe ich auch gemerkt,

33:06.320 --> 33:09.320
es gibt das Problem, wenn man Customer-Support hat,

33:09.320 --> 33:12.320
die ja wirklich mit richtigen Kunden und Kundinnen reden

33:12.320 --> 33:14.320
plötzlich, der Step geht nicht mehr,

33:14.320 --> 33:16.320
und ich sage, was für ein Step?

33:16.320 --> 33:18.320
Ach, Description geht nicht mehr,

33:18.320 --> 33:20.320
ich sage doch, dass Description nicht mehr geht.

33:20.320 --> 33:22.320
Natürlich müssen die die modernen Begriffe verwenden

33:22.320 --> 33:24.320
und nicht unsere technischen Begriffe.

33:24.320 --> 33:26.320
Aber aus dem Grund, weil ich es nicht weiß,

33:26.320 --> 33:28.320
wie man gut reflektieren kann,

33:28.320 --> 33:31.320
weil so Komponenten, dass alle Properties mit so übersetzt werden,

33:31.320 --> 33:34.320
tendiere ich eben eher dazu, beim Ersten zu bleiben.

33:34.320 --> 33:37.320
Ja, also ich habe schon Tools gesehen, die es gut können,

33:37.320 --> 33:40.320
aber es hängt halt eben auch stark von der Programmiersprache ab.

33:40.320 --> 33:43.320
Ich glaube jetzt, gerade der Trend zu Type-Tryptin

33:43.320 --> 33:45.320
hilft auch schon stark.

33:45.320 --> 33:47.320
Ich bin eher bei staatlich kompellierten Sprachen

33:47.320 --> 33:49.320
aller Java Kotlin unterwegs.

33:49.320 --> 33:51.320
Da ist es einfacher, so was zu machen,

33:51.320 --> 33:53.320
aber natürlich dieses,

33:53.320 --> 33:55.320
wenn ich jetzt die Klasse umbenenne,

33:55.320 --> 33:58.320
das Felder dann auch mit umbenannt werden,

33:58.320 --> 34:00.320
das kann man schon ableiten,

34:00.320 --> 34:02.320
ist aber auch schon wieder der nächste Schritt.

34:02.320 --> 34:05.320
Das heißt, es wird auch nicht überall perfekt funktionieren.

34:05.320 --> 34:07.320
Das heißt, da kommt man halt eben,

34:07.320 --> 34:09.320
wenn man es wirklich umbenennt,

34:09.320 --> 34:11.320
nicht drum herum,

34:11.320 --> 34:13.320
und wenn es dann irgendeinem Kommentar drin vorkommt,

34:13.320 --> 34:15.320
wird es noch schwieriger.

34:15.320 --> 34:17.320
Also ich habe es auch schon gesehen,

34:17.320 --> 34:19.320
wo dann so Vorstellke kommen.

34:19.320 --> 34:21.320
Willst du nicht auch noch den Kommentar umbenennt,

34:21.320 --> 34:24.320
aber ja, da wird es schon schwieriger

34:24.320 --> 34:27.320
und da kann man nie alle Fälle abdecken.

34:27.320 --> 34:30.320
Das bringt mich zu einem guten Punkt,

34:30.320 --> 34:33.320
und zwar in dem original Buch von Eric Evans gibt es

34:33.320 --> 34:35.320
ein komplettes Drittel vom Buch

34:35.320 --> 34:38.320
zu Refactoring to Deeper Insights.

34:38.320 --> 34:40.320
Im Endeffekt ist die Kernaussage,

34:40.320 --> 34:42.320
egal was du machst,

34:42.320 --> 34:44.320
das was du als erstes machst, ist nie perfekt,

34:44.320 --> 34:46.320
und du lernst immer.

34:46.320 --> 34:48.320
Und das heißt, man muss dann immer,

34:48.320 --> 34:50.320
man baut was,

34:50.320 --> 34:52.320
und dann versteht man es besser,

34:52.320 --> 34:54.320
das Business entwickelt sich,

34:54.320 --> 34:57.320
und dann refactored man.

34:57.320 --> 34:59.320
Ah, das gehört doch zusammen,

34:59.320 --> 35:01.320
jetzt schiebe ich das darum.

35:01.320 --> 35:03.320
Und das ist natürlich auch viel einfacher,

35:03.320 --> 35:05.320
wenn ich die,

35:05.320 --> 35:08.320
dieses Domain-Layer, also diese ganze Logik,

35:08.320 --> 35:11.320
alles getrennt habe von der Datenbank.

35:11.320 --> 35:13.320
Und ich glaube jetzt muss ich es doch mal auspacken,

35:13.320 --> 35:15.320
hexagonale Architektur,

35:15.320 --> 35:18.320
das ist eine Möglichkeit, das Ganze zu trennen.

35:18.320 --> 35:20.320
Das heißt, man sagt wirklich,

35:20.320 --> 35:22.320
okay, ich habe eine Domain-Schicht,

35:22.320 --> 35:24.320
da ist nur meine Logik,

35:24.320 --> 35:27.320
und da ist jetzt nichts technisches uns drin.

35:27.320 --> 35:29.320
Da mache ich nach Möglichkeit,

35:29.320 --> 35:31.320
mache ich auch gar kein Framework rein.

35:31.320 --> 35:34.320
Und das ist am Anfang extrem schwer.

35:34.320 --> 35:37.320
Am ersten Projekt, wo wir es umgesetzt haben,

35:37.320 --> 35:41.320
danach hat die Hälfte der Logik doch irgendwo anders.

35:41.320 --> 35:43.320
Und da muss man eben immer wieder hingehen,

35:43.320 --> 35:45.320
in so ein Lernprozess.

35:45.320 --> 35:47.320
Ah, jetzt habe ich die Logik da eingebaut.

35:47.320 --> 35:50.320
Beim Laden aus der Datenbank habe ich irgendwie doch noch Logik verwendet,

35:50.320 --> 35:53.320
statt nur blödes Mapping.

35:53.320 --> 35:55.320
Und da ist natürlich auch entscheidend,

35:55.320 --> 35:57.320
dass man das Ganze so macht,

35:57.320 --> 36:00.320
dass es einen nicht total frustriert,

36:00.320 --> 36:03.320
und da hängt es eben auch von den Sprachen ab.

36:03.320 --> 36:07.320
Wir haben verwendet seit 2008 hauptsächlich Kotlin statt Java,

36:07.320 --> 36:10.320
und das ist viel, viel weniger Kot,

36:10.320 --> 36:12.320
jetzt so ein blödes Mapping zu machen.

36:12.320 --> 36:15.320
Man muss auch viel weniger Test schreiben,

36:15.320 --> 36:18.320
um sicherzugehen, dass das wirklich funktioniert.

36:18.320 --> 36:20.320
Und dann ist es auch viel einfacher,

36:20.320 --> 36:23.320
die Leute davon zu überzeugen, so etwas zu machen.

36:23.320 --> 36:26.320
Wenn man dann mal länger in so einem System gearbeitet hat,

36:26.320 --> 36:28.320
will man es nicht mehr zurück.

36:28.320 --> 36:31.320
Weil auf einmal ist in der API oder in der Datenbank

36:31.320 --> 36:34.320
etwas ändern, ja, das ist eine eigene Schicht.

36:34.320 --> 36:37.320
Das Mapping sieht am Anfang blöd aus,

36:37.320 --> 36:40.320
weil ganz am Anfang ist mit hoher Wahrscheinlichkeit die API,

36:40.320 --> 36:44.320
die Logik, und das, was in der Datenbank ist, fast identisch.

36:44.320 --> 36:47.320
Das heißt, beim Mapping, das wirklich einfällt

36:47.320 --> 36:49.320
mit dem gleichen Namen auf das andere.

36:49.320 --> 36:51.320
Aber es passiert oft schneller,

36:51.320 --> 36:54.320
als man denkt, dass sich irgendetwas ändert,

36:54.320 --> 36:57.320
oder dass man noch eine weitere API hinzufügt,

36:57.320 --> 37:00.320
die an halt eben vielleicht doch etwas anders aussieht,

37:00.320 --> 37:03.320
wenn man die API dann doch zum Beispiel

37:03.320 --> 37:06.320
speziell an einem Mobile App oder sonst was anpasst,

37:06.320 --> 37:09.320
die dann halt eben das Ganze anders kopiert.

37:09.320 --> 37:11.320
Und was wir da auch gemerkt haben, ist,

37:11.320 --> 37:13.320
dass die Sprache selber, wie Kotlin,

37:13.320 --> 37:15.320
von den Sichtbarkeiten und so,

37:15.320 --> 37:17.320
das gar nicht alles hergibt,

37:17.320 --> 37:19.320
dass man die eben in so klark trennen kann.

37:19.320 --> 37:21.320
Also zum Beispiel wirklich hart verbieten,

37:21.320 --> 37:23.320
dass man da nicht auf was anderes zugreift.

37:23.320 --> 37:26.320
Natürlich könnte man dann Module machen und so was,

37:26.320 --> 37:28.320
aber es wird auch komplett komplex.

37:28.320 --> 37:31.320
Und dann gibt es interessanterweise aus München,

37:31.320 --> 37:33.320
ArcUnit, ein Open-Source-Tool,

37:33.320 --> 37:36.320
für die ganzen JVM-basierten Sprachen,

37:36.320 --> 37:39.320
womit man wirklich Regeln schreiben kann und sagen kann,

37:39.320 --> 37:42.320
hey, also ganz flexibel,

37:42.320 --> 37:44.320
alles, was in dem Paket ist,

37:44.320 --> 37:46.320
darf nicht auf das andere zugreifen,

37:46.320 --> 37:48.320
alles, was den Namen hat,

37:48.320 --> 37:50.320
darf nicht auf das zugreifen und so weiter und so fort.

37:50.320 --> 37:52.320
Und damit kann man wirklich

37:52.320 --> 37:57.320
das Ganze in einem Unit-Test erzwingen.

37:57.320 --> 38:02.320
Weil ansonsten so sehr, wie man drauf guckt,

38:02.320 --> 38:05.320
es schleicht sich immer irgendwas ein.

38:05.320 --> 38:08.320
Und das sind dann schon so wichtige Schritte,

38:08.320 --> 38:10.320
die wir auch gelernt haben,

38:10.320 --> 38:12.320
das Ganze dann umzusetzen.

38:12.320 --> 38:14.320
Es ist aber auch bei uns so,

38:14.320 --> 38:16.320
dass das Ganze sich ständig weiterentwickelt.

38:16.320 --> 38:19.320
Man lernt immer, was funktioniert, was funktioniert nicht.

38:19.320 --> 38:22.320
Das heißt, jedes neue Stück Software

38:22.320 --> 38:25.320
sieht wir ein bisschen anders aus als das Bestehende.

38:25.320 --> 38:29.320
Der iterative Approach, das macht ja

38:29.320 --> 38:31.320
durchaus sehr, sehr viel Sinn.

38:31.320 --> 38:34.320
Der eigene Code entwickelt sich weiter,

38:34.320 --> 38:36.320
die Ideen entwickeln sich weiter

38:36.320 --> 38:39.320
und vor allem das Gelernte entwickelt sich weiter.

38:39.320 --> 38:41.320
Jetzt ist es aber auch so,

38:41.320 --> 38:43.320
wahrscheinlich bei euch gewesen,

38:43.320 --> 38:45.320
dass nicht jede Entwicklerin und jeder Entwickler

38:45.320 --> 38:47.320
schon direkt wusste, was ist denn jetzt

38:47.320 --> 38:50.320
dieses Domain-Triven-Design

38:50.320 --> 38:52.320
und auf welche Feinheiten muss ich denn achten?

38:52.320 --> 38:54.320
Du hast es eben angesprochen,

38:54.320 --> 38:56.320
das ist eine hexagonale Architektur,

38:56.320 --> 38:58.320
wie baue ich meine Services auf und ähnliches.

38:58.320 --> 39:01.320
Das heißt, da ist für alle Beteiligten

39:01.320 --> 39:03.320
erst mal ein gewisser,

39:03.320 --> 39:05.320
so eine Art Lernkurve erst mal zu nehmen

39:05.320 --> 39:07.320
und irgendwie muss man ja auch ein Stück weit

39:07.320 --> 39:10.320
aus einer architektonischen Brille heraus

39:10.320 --> 39:13.320
überwachen in Anführungsstrichen,

39:13.320 --> 39:15.320
wie das Ganze sich entwickelt

39:15.320 --> 39:17.320
und dass man in die richtige Richtung geht.

39:17.320 --> 39:19.320
Wie habt ihr das gemacht?

39:19.320 --> 39:21.320
Das ist dann eben auch was,

39:21.320 --> 39:23.320
was mit der Firma gewachsen ist.

39:23.320 --> 39:25.320
Gewisse Konzepte von Domain-Triven-Design

39:25.320 --> 39:27.320
haben wir implizit über die ganzen Jahre

39:27.320 --> 39:29.320
schon verwendet, aber wirklich explizit

39:29.320 --> 39:32.320
haben wir 2019 in einem kleinen Projekt

39:32.320 --> 39:34.320
damit angefangen.

39:34.320 --> 39:36.320
Da habe ich ein Team geleitet,

39:36.320 --> 39:38.320
das damals extrem klein war,

39:38.320 --> 39:40.320
das waren außer mir noch zwei Entwickler

39:40.320 --> 39:42.320
und da haben wir uns einfach vorgenommen,

39:42.320 --> 39:44.320
okay, wir haben unser eigenes kleines Projekt,

39:44.320 --> 39:46.320
wir setzen das mal um

39:46.320 --> 39:48.320
und im Endeffekt war es halt eben auch

39:48.320 --> 39:50.320
größtenteils ein Becken-Service,

39:50.320 --> 39:52.320
der dann daraus entstanden ist

39:52.320 --> 39:55.320
aus heutiger Sicht

39:55.320 --> 39:57.320
bin ich auf das Ergebnis jetzt nicht sehr stolz,

39:57.320 --> 39:59.320
weil das genau das passiert,

39:59.320 --> 40:01.320
was ich vorangeschnitten habe,

40:01.320 --> 40:03.320
die Hälfte der Logik ist woanders gelandet

40:03.320 --> 40:06.320
und da das Projekt nachher nicht mehr so wichtig war,

40:06.320 --> 40:10.320
hatten wir auch nie mit der Zeit da viel aufzuräumen.

40:10.320 --> 40:13.320
Es gab da aber schon ziemlich viel,

40:13.320 --> 40:15.320
was wir gelernt haben.

40:15.320 --> 40:17.320
Zum Beispiel gab es,

40:17.320 --> 40:20.320
wir haben dann externen Partner angebunden,

40:20.320 --> 40:23.320
wo das Onboarding extrem komplex war,

40:23.320 --> 40:27.320
man musste irgendwie so acht Schritte durchlaufen.

40:27.320 --> 40:29.320
Und ich bin irgendwie nach einer Zeit wieder

40:29.320 --> 40:31.320
in den Code reingegangen

40:31.320 --> 40:33.320
und habe selber nicht mehr verstanden,

40:33.320 --> 40:36.320
weil das alles über den Code verteilt war.

40:36.320 --> 40:38.320
Und ich dachte mir einfach,

40:38.320 --> 40:40.320
dieses Onboarding, diese acht Schritte,

40:40.320 --> 40:44.320
das kann doch irgendwo zusammen sein.

40:44.320 --> 40:47.320
Und das ist dann halt eben gar nicht so einfach,

40:47.320 --> 40:49.320
sich dann praktisch dahin zu setzen

40:49.320 --> 40:52.320
und zu denken, okay, wie kriege ich das jetzt so hin,

40:52.320 --> 40:54.320
dass das so an einer Stelle zusammen ist.

40:54.320 --> 40:56.320
Natürlich hat jeder Schritt seine eigene Komplexität,

40:56.320 --> 40:59.320
aber am Ende haben wir es hinbekommen,

40:59.320 --> 41:02.320
eine Klasse zu haben für dieses Onboarding,

41:02.320 --> 41:05.320
für diesen Prozess, der dann wirklich gesagt hat,

41:05.320 --> 41:07.320
Schritt eins, und dann hat er auch wieder

41:07.320 --> 41:09.320
auf etwas anderes verwiesen,

41:09.320 --> 41:11.320
wo man es halt eben einfach nachvollziehen konnte.

41:11.320 --> 41:13.320
Wo man jetzt wirklich,

41:13.320 --> 41:15.320
wenn man dieses Beispiel, ich mache jetzt per Programming,

41:15.320 --> 41:17.320
ich will das jemanden erklären, man setzt sich hin.

41:17.320 --> 41:19.320
Und wenn ich dann selber erstmal halbe

41:19.320 --> 41:21.320
schon im Code suchen muss, wo ist der Schritt,

41:21.320 --> 41:24.320
wo ist der Schritt oder der Schritt, ja, blöd.

41:24.320 --> 41:27.320
Wenn es alles in einer Klasse ist, einfach.

41:27.320 --> 41:30.320
Aber damit waren wir dann so ein bisschen angefixst.

41:30.320 --> 41:33.320
Wir hatten so die erste Erfahrung gesammelt

41:33.320 --> 41:35.320
und dachten, okay, das geht viel, viel besser.

41:35.320 --> 41:37.320
Unsere Hauptschwierigkeit war,

41:37.320 --> 41:41.320
wie übersetzt sich jetzt die Theorie in unserer Praxis.

41:41.320 --> 41:43.320
Und dann haben wir angefangen,

41:43.320 --> 41:46.320
Ende 2019 im Proker zu bauen.

41:46.320 --> 41:48.320
Und da haben wir ein sehr schnell

41:48.320 --> 41:50.320
ein größeres Team gehabt.

41:50.320 --> 41:53.320
Im Endeffekt waren es über 10 Leute in einem Team.

41:53.320 --> 41:57.320
Wir haben dann wohl größer als unsere übliche Teamkurse entschieden,

41:57.320 --> 42:00.320
okay, wichtiges Projekt.

42:00.320 --> 42:02.320
Wir lassen es als ein Team laufen

42:02.320 --> 42:06.320
und hatten dann ein paar Entwickler dabei,

42:06.320 --> 42:09.320
die direkt begeistert, gesagt haben, okay,

42:09.320 --> 42:11.320
wir wollen das machen.

42:11.320 --> 42:13.320
Und dann ging das ganz auch viel, viel schneller.

42:13.320 --> 42:16.320
Weil dann war wirklich so, okay, wie übersetzen wir das jetzt

42:16.320 --> 42:19.320
in unsere Eistrichtur, in unseren Code.

42:19.320 --> 42:23.320
Und dann zum Beispiel diese Abstraktion von der Datenbank.

42:23.320 --> 42:26.320
Dann kamen recht schnell super Ideen da zusammen.

42:26.320 --> 42:30.320
Und wir haben dann auch mehrere Services

42:30.320 --> 42:32.320
direkt damit umgesetzt.

42:32.320 --> 42:36.320
Und natürlich die Leute, die es umgesetzt haben und dabei waren,

42:36.320 --> 42:38.320
da war die Begeisterung da.

42:38.320 --> 42:41.320
Den Rest der Firma hat es noch nicht so interessiert.

42:41.320 --> 42:43.320
Da ist natürlich mal passiert,

42:43.320 --> 42:46.320
dass der eine oder andere sich interessiert hat, nachgefragt hat.

42:46.320 --> 42:49.320
Wir haben auch versucht, ein bisschen die Firma rauszutragen,

42:49.320 --> 42:52.320
aber es war noch nicht so, dass es überall übergeschwappt ist.

42:52.320 --> 42:55.320
Wenn es sich dann aber immer mehr verbreitet

42:55.320 --> 42:57.320
und gerade die Leute, die damit gearbeitet haben,

42:57.320 --> 42:59.320
oh, jemand, der in das Team reingekommen ist,

42:59.320 --> 43:02.320
gesagt, oh, das ist viel einfacher zu verstehen für mich,

43:02.320 --> 43:05.320
dann hat man so einen langsamen Effekt,

43:05.320 --> 43:08.320
interessieren sich die anderen Teams dafür.

43:08.320 --> 43:11.320
Und mittlerweile sind wir im Zustand,

43:11.320 --> 43:14.320
wo es alle in der Firma wissen,

43:14.320 --> 43:17.320
aber nicht alle explizit anwenden.

43:17.320 --> 43:20.320
Da waren natürlich auch viele existierende Projekte da.

43:20.320 --> 43:23.320
Aber die Leute sind sehr aufgeschlossen,

43:23.320 --> 43:25.320
weil sie wissen, es funktioniert.

43:25.320 --> 43:27.320
Und die anderen sind begeistert davon.

43:27.320 --> 43:31.320
Und da hilft natürlich auch viel internes Teilen von Wissen.

43:31.320 --> 43:36.320
Also wir haben regelmäßig Tech-Lunches oder andere.

43:36.320 --> 43:39.320
Wir haben so Interessengruppen intern, die über so Sachen diskutieren.

43:39.320 --> 43:42.320
Da verteilt sich das Wissen zwischen den Leuten,

43:42.320 --> 43:44.320
die interessiert sind, extrem stark.

43:44.320 --> 43:48.320
Und so haben wir es dann immer weiter verbreitet.

43:48.320 --> 43:53.320
Und im Endeffekt, glaube ich, das größte Projekt war jetzt,

43:53.320 --> 43:57.320
dass wir alle unsere Produkte genommen haben,

43:57.320 --> 44:02.320
in mehreren Event-Stirming-Workstops durchgegangen sind,

44:02.320 --> 44:04.320
erst mal ganz oben und dann pro Produkt,

44:04.320 --> 44:06.320
um wirklich zu schauen,

44:06.320 --> 44:10.320
wie wollen wir unsere Teams und die ganze Software

44:10.320 --> 44:12.320
in Zukunft schneiden.

44:12.320 --> 44:17.320
Und haben in dem Prozess, der fast ein Jahr gedauert hat,

44:17.320 --> 44:19.320
aber mit dabei in der ganzen Firma,

44:19.320 --> 44:22.320
praktisch so ein Bild, da wollen wir hin.

44:22.320 --> 44:25.320
Natürlich ist das immer ein Idealbild.

44:25.320 --> 44:30.320
Aber wir haben jetzt praktisch so diesen Nordstern

44:30.320 --> 44:33.320
und alle wissen, okay, da geht es hin.

44:33.320 --> 44:37.320
Was auch viele Fragen dann im Alltag einfacher macht.

44:37.320 --> 44:39.320
Welches Team macht das jetzt?

44:39.320 --> 44:43.320
Wo gehört das Projekt in Zukunft hin und so weiter?

44:43.320 --> 44:46.320
Man merkt so, mit jedem Schritt kommt man dem Ganzen näher.

44:46.320 --> 44:49.320
Natürlich ist es halt eben auch nur so ein Momentaufnahme,

44:49.320 --> 44:53.320
und man wird es hin und wieder bearbeiten müssen.

44:53.320 --> 44:58.320
Aber man merkt dann schon, dass sich der ganze Aufwand dann lohnt.

44:58.320 --> 45:03.320
Und ich bin dann immer wieder begeistert, wenn ich sehe,

45:03.320 --> 45:06.320
wie schnell sich die Leute dann im Code so recht finden.

45:06.320 --> 45:11.320
Und gerade aktuell, wo ich selber quasi im Alltag keinen Code mehr schreibe,

45:11.320 --> 45:15.320
a