Über Domain-Driven Design (DDD) sprechen Hans und Vanessa mit dem Gast Florian Benz, VP of Engineering bei Scalable Capital. Florian beleuchtet dabei vor Allem dir Umsetzung samt Stolpersteinen in der Realität.
Unser Sponsor
Wir sind Demodern – wir sehen uns als Agentur einer neuen Generation: offen, unkompliziert, 100% digital. Gegründet von Designern, liegt unsere Leidenschaft in innovativen, digitalen Inszenierungen und einer sinnvollen User Experience. Wir entwickeln unsere Projekte gemeinsam mit Spezialisten aus Strategie, Design, UX und Development. „Let’s push things forward“ ist unser Leitsatz und Philosophie. Darin steckt unsere eigene Veränderung, aber auch, Projekte neu zu betrachten und zu rechtem Mehrwert zu bringen.
Ihr könnt gerne Kontakt zu Florian oder Marisa direkt aufnehmen – oder ihr schaut auf demodern.de/jobs vorbei.
Schaunotizen
[02:14:00] Domain-Driven Design
Florian begann die ersten Schritte mit Domain-Driven Design (im Folgenden mit „DDD“ abgekürzt) in Teams bei Scalable Capital im Jahr 2019. Zu den größten Herausforderungen zählte, wie man das theoretische Wissen über DDD konkret umsetzen. Bei der Theorie geht Florian speziell auf folgende Teile von DDD ein:
Explorativ,
strategisch und
taktisch. Genauer erläutert er die folgenden Komponenten von taktischem Design: Value Objects, Entities, Aggregrates, Repositories, Services und Factories.
Ein Hauptbestandteil von DDD ist es, eine gemeinsame Sprache zu entwickeln. Das ist jedoch gar nicht so einfach. Vor allem, wenn die allgemeine Code-Sprache bei Projekten oft Englisch ist, aber die Dokumentationssprache z.B. Deutsch. Doch wenn das Team einmal so weit ist, macht es die gemeinsame Sprache für alle einfacher. Für Entwickler:innen im Speziellen, den Code zu strukturieren und eine sehr wichtige Frage zu beantworten: Wo gehört dieser Code überhaupt hin?
Links
- Patterns, Principles, and Practices of Domain-Driven Design
Scott Millett, Nick Tune
- „The Big Blue Book“
Domain-Driven Design: Tackling Complexity in the Heart of Software —Eric Evans
- Domain Modeling Made Functional —Scott Wlaschin, KanDDDinsky 2019
- Making Impossible States Impossible—Richard Feldman, elm-conf 2016
- Kotlin and Domain-Driven Design-Value Objects—Florian Benz 2020
- DDD Crew – Welcome to Domain-Driven Design (DDD)
„This project contains definitions of DDD and fundamental concepts to reduce the learning curve and confusion.“
Verwandte Revisionen
- Revision 314: DDD, CQRS und WTF
Transkript
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
aber noch gerne Reviews mache oder mal Sachen nachschau,
45:15.320 --> 45:18.320
ist es natürlich auch für mich viel einfacher,
45:18.320 --> 45:21.320
wenn ich in den Code reingehe und weiß, okay, das ist die Struktur.
45:21.320 --> 45:24.320
Und wenn man den Fachbegriff weiß
45:24.320 --> 45:26.320
und einfach nur im Code nach dem Fachbegriff suchen muss,
45:26.320 --> 45:30.320
und man findet direkt die Logik dahinter.
45:30.320 --> 45:34.320
Was dann auch wieder hin dazu führt, dass das manchmal schneller ist,
45:34.320 --> 45:38.320
als es den Teamkollegen zu fragen.
45:38.320 --> 45:41.320
Na dann hat sich das aber schon richtig gelohnt.
45:41.320 --> 45:44.320
Ich denke, du hast gerade einen sehr wichtigen Punkt gesagt
45:44.320 --> 45:46.320
mit diesen Alltagsentscheidungen,
45:46.320 --> 45:51.320
die bestimmt vielen Leuten gar nicht so bewusst sind,
45:51.320 --> 45:54.320
die nicht täglich so dabei arbeiten oder dabei sind
45:54.320 --> 45:57.320
oder nicht diesen täglichen Entscheidungen treffen müssen.
45:57.320 --> 46:01.320
Und vielleicht den Personen, die diese ständigen Entscheidungen treffen müssen,
46:01.320 --> 46:06.320
gar nicht den freien Kopf jetzt dafür haben, sich zu überlegen,
46:06.320 --> 46:08.320
ist das nicht eigentlich doof, könnte man das nicht besser haben,
46:08.320 --> 46:11.320
wenn man ja dann im Tunnel ist und jetzt diese Antwort braucht.
46:11.320 --> 46:15.320
Aber ich glaube, immer dieses gemeinsame Ziel zu haben,
46:15.320 --> 46:17.320
kann schon sehr viel Zeit ersparen.
46:17.320 --> 46:22.320
Und ich kann mir vorstellen, dass so der ein oder die andere Hörer und Hörer
46:22.320 --> 46:27.320
sich denkt bei, wow, die hatten in ihrer Firma nicht nur einen,
46:27.320 --> 46:29.320
ich glaube, du hast das Event-Storming genannt,
46:29.320 --> 46:32.320
diesen ganzen Tag, wo die ganze Firma da war, so gefühlt,
46:32.320 --> 46:34.320
und dann sogar mehrere.
46:34.320 --> 46:36.320
Ja, wer hat denn da gearbeitet?
46:36.320 --> 46:38.320
Da geht ja nichts vorwärts.
46:38.320 --> 46:43.320
Aber du hast wahrscheinlich jetzt auch keine Zahlen hier einfach so rumliegen,
46:43.320 --> 46:45.320
aber du hättest schon das Gefühl,
46:45.320 --> 46:49.320
dass dieser eine Tag oder vielleicht diese drei Tage oder fünf Tage in Summe
46:49.320 --> 46:51.320
so viele Alltagsentscheidungen dann abgenommen hat,
46:51.320 --> 46:54.320
dass sich das auf jeden Fall schon rentiert hat.
46:54.320 --> 46:57.320
Genau, das ist dann eben bei so Sachen immer extrem schwer,
46:57.320 --> 47:01.320
das jetzt wirklich zu quantifizieren, was hat das jetzt wirklich gebracht.
47:01.320 --> 47:04.320
Vielleicht noch ein wichtiges bei diesen Event-Storming-Workshops,
47:04.320 --> 47:07.320
es ist ganz wichtig, dass nicht zu viele dabei sind.
47:07.320 --> 47:09.320
Was gerade bei den ersten extrem schwer war,
47:09.320 --> 47:14.320
wie finde ich die 15 Leute in der Firma, die dafür genau richtig sind,
47:14.320 --> 47:18.320
und wie kriegt das hin, dass alle die an einem Tag Zeit haben?
47:18.320 --> 47:21.320
Weil du nimmst natürlich gerade für die auf höhere Ebene,
47:21.320 --> 47:25.320
nimmst du dann die entscheidenden Leute, die das ganze Wissen haben, damit rein?
47:25.320 --> 47:27.320
Das war gar nicht so einfach.
47:27.320 --> 47:29.320
Was auch im Endeffekt dazu geführt hat,
47:29.320 --> 47:33.320
dass wir alle Remote durchgeführt haben.
47:33.320 --> 47:35.320
Also es war ursprünglich nicht der Plan,
47:35.320 --> 47:38.320
wir dachten, okay, es gibt doch besser, wenn alle im Büro sind,
47:38.320 --> 47:42.320
aber es hat sich halt eben dann doch als extrem schwierig herausgestellt,
47:42.320 --> 47:47.320
und dann haben wir meines Wissens nach alle Remote durchgeführt.
47:47.320 --> 47:51.320
Heutzutage mit dem ganzen Tooling ist ja auch kein Problem mehr.
47:51.320 --> 47:54.320
Es ist schon immer noch was anderes, man muss sich darauf einstellen,
47:54.320 --> 48:01.320
aber wie viele mittlerweile wissen, wenn nicht alle vor Ort sein können,
48:01.320 --> 48:05.320
muss man sich eher auf den einen oder mehrere Remote einstellen,
48:05.320 --> 48:08.320
und dann kann man es gleich komplett remote machen.
48:08.320 --> 48:11.320
Weil wenn dann die eine Hälfte am Whiteboard,
48:11.320 --> 48:15.320
die anderen in einem, was weiß ich nicht, was Board arbeiten,
48:15.320 --> 48:18.320
das ist ja nicht so einfach.
48:18.320 --> 48:22.320
Das führt meistens zu unschönen Situationen,
48:22.320 --> 48:26.320
dass entweder Krüppchen gebildet werden, die eh schon daraus bestehen,
48:26.320 --> 48:28.320
die einen sind remote, die anderen zu dem Büro,
48:28.320 --> 48:30.320
und nicht, wie es sich vielleicht sonst gegeben hätte.
48:30.320 --> 48:35.320
Und ganz schwierig finde ich es, wenn du nur eine Person nicht dabei hast.
48:35.320 --> 48:38.320
Ich war auch schon mal diese eine Person, das fühlt sich nicht so toll an.
48:38.320 --> 48:42.320
Da braucht man schon ein ganz tolles Team, das einen nicht vergisst.
48:42.320 --> 48:44.320
Was wir gemacht haben bei den Remote-Workshops,
48:44.320 --> 48:47.320
wir haben sie dann nicht an einem Tag gemacht.
48:47.320 --> 48:50.320
Wir haben dann zweimal vier Stunden gemacht an unterschiedlichen Tagen,
48:50.320 --> 48:55.320
weil wir dann einfach davon, also das war die Erfahrung von unserem Trainer,
48:55.320 --> 49:00.320
dass der gesagt hat, okay, das ist Remote einfach besser,
49:00.320 --> 49:03.320
und das hat bei unseren auch gut funktioniert.
49:03.320 --> 49:06.320
Ein sehr guter Punkt, den du auch sagst,
49:06.320 --> 49:10.320
jemanden dazu holen, Trainer, eine Trainerin,
49:10.320 --> 49:13.320
die vielleicht schon viel Erfahrung in dem Teilbereich haben,
49:13.320 --> 49:16.320
auch wenn man selber vielleicht die Theorie kennt,
49:16.320 --> 49:19.320
auch wenn da nochmal eine externe Person dabei ist,
49:19.320 --> 49:23.320
kann ich mir vorstellen, dass das natürlich auch nochmal einen gewissen Impact hat
49:23.320 --> 49:26.320
für die Teilnehmerinnen und Teilnehmer.
49:26.320 --> 49:30.320
Und vor allem, man steckt halt selber ja auch irgendwie immer in den Details drin
49:30.320 --> 49:33.320
und möchte seinen Wissen mit dazu beitragen.
49:33.320 --> 49:36.320
Und gleichzeitig den Prozess durchzuführen,
49:36.320 --> 49:38.320
ich glaube, das kennen wir irgendwie alle aus Workshops,
49:38.320 --> 49:41.320
es ist manchmal nicht so einfach.
49:41.320 --> 49:46.320
Und allein eine Person zu haben, die sagt, okay, ich habe das schon mal gemacht,
49:46.320 --> 49:51.320
und wir machen das einfach so und ihr haltet euch alle an die Regeln,
49:51.320 --> 49:55.320
das ist schon mal extrem viel wert.
49:55.320 --> 49:58.320
Und natürlich, was ich auch gelernt habe,
49:58.320 --> 50:02.320
jemanden, der sich halt eben mit dem ganzen Tooling dann gut auskennt
50:02.320 --> 50:06.320
und auch weiß, wie man sowas vorbereitet, nacharbeitet
50:06.320 --> 50:10.320
und dann auch sagt, okay, das sind jetzt die nächsten Schritte
50:10.320 --> 50:14.320
oder ich empfehle euch jetzt, in die Leute einzuladen.
50:14.320 --> 50:16.320
Das ist dann schon extrem viel wert,
50:16.320 --> 50:20.320
einfach diese Erfahrung, die dann jemand mitbringen kann
50:20.320 --> 50:22.320
und hat uns auch sehr geholfen.
50:22.320 --> 50:25.320
Ja, ansonsten kann ich mir vorstellen, dass das schon sehr schwierig sein könnte,
50:25.320 --> 50:29.320
jetzt den Anfang zu finden, wenn man gar niemand mit Erfahrung da hat
50:29.320 --> 50:31.320
und vielleicht ist dann eher dazu führt,
50:31.320 --> 50:35.320
dass man lieber mal gar nicht anfängt, bevor man es dann falsch macht.
50:35.320 --> 50:39.320
Da würden mir sogar auch wirklich ein paar Beispiele aus meinem Leben einfallen.
50:39.320 --> 50:43.320
Ich glaube, ich hatte mal so einen kurzen Exkurs zu Ramda.js.
50:43.320 --> 50:45.320
Hätte man in dem Projekt auch wirklich nicht...
50:45.320 --> 50:47.320
Das hat jetzt wenig mit Ramda selber zu tun,
50:47.320 --> 50:50.320
aber es war einfach so eine Person, war stark dafür.
50:50.320 --> 50:52.320
Die anderen hatten keine Meinung
50:52.320 --> 50:55.320
und dann gab es niemanden, der oder die dafür gesorgt hat,
50:55.320 --> 50:56.320
wie man das jetzt so angeht.
50:56.320 --> 51:01.320
Und das heißt halt wirklich, da war diese Datei mit Ramda geschrieben, diese ohne.
51:01.320 --> 51:03.320
Jetzt sollte man da mal einen Backfixen,
51:03.320 --> 51:07.320
kann nur die eine Person, weil die hat das geschrieben, das kann ich nicht lesen.
51:07.320 --> 51:09.320
Also es gibt ja wirklich so Negativbeispiele,
51:09.320 --> 51:11.320
dass man vielleicht lieber gar nicht anfängt,
51:11.320 --> 51:14.320
wenn man es nicht richtig durchsetzt.
51:14.320 --> 51:17.320
Ansonsten, ich glaube, du hast was sehr kluges gesagt,
51:17.320 --> 51:21.320
mit dem, dass man immer lernt, dass es beim ersten Mal nie richtig ist
51:21.320 --> 51:23.320
und dass es auch okay ist,
51:23.320 --> 51:25.320
weil ich möchte eigentlich nochmal auf diesem Punkt gerade,
51:25.320 --> 51:28.320
von gerade eben eingehen, dieses gemeinsame Ziel
51:28.320 --> 51:31.320
und was du gerade gemeint hattest mit, man hält dir jetzt an die Regeln.
51:31.320 --> 51:34.320
Für mich müssen es nicht immer die perfekten,
51:34.320 --> 51:37.320
die eine richtigen, komplett richtigen Regeln sein
51:37.320 --> 51:41.320
oder das perfekte Ziel, auf das man hinarbeitet.
51:41.320 --> 51:45.320
Aber einfach so wenig Ablenkung wie möglich zu haben,
51:45.320 --> 51:48.320
dass man vielleicht sagt, nach drei Monaten
51:48.320 --> 51:51.320
jetzt fällt uns auf, das aktuelle Ziel passt gerade nicht.
51:51.320 --> 51:53.320
Wir ändern jetzt irgendwie die Richtung.
51:53.320 --> 51:55.320
Es passt gerade nicht mehr wie die Module aufbauen,
51:55.320 --> 51:57.320
wir bauen sie ein bisschen anders auf.
51:57.320 --> 51:59.320
Aber in dieser Zwischenzeit wussten alle,
51:59.320 --> 52:02.320
nach welchen Regeln man hier gerade arbeitet
52:02.320 --> 52:06.320
und hat da sehr viel Zeit vielleicht durchgespart.
52:06.320 --> 52:08.320
Was ich mich gerade noch frage,
52:08.320 --> 52:11.320
wir haben ein bisschen Reunitests und so was angesprochen
52:11.320 --> 52:13.320
und auch diese Code Reviews leichter zu verstehen,
52:13.320 --> 52:17.320
weil man als komplett externe Person den Code besser lesen kann.
52:17.320 --> 52:21.320
Denkst du, dass der Code auch vielleicht sogar sicherer werden kann,
52:21.320 --> 52:23.320
vielleicht freier von Bucksugar,
52:23.320 --> 52:25.320
weil man irgendwie das Klare strukturieren kann,
52:25.320 --> 52:29.320
klarer trennen kann, weniger drumrum schreiben muss.
52:29.320 --> 52:32.320
Jetzt habe ich da noch einen Fall vergessen.
52:32.320 --> 52:35.320
Jetzt mache ich hier noch so ein If-Check mit rein.
52:35.320 --> 52:38.320
Ja, es ist natürlich jetzt schwer zu quantifizieren.
52:38.320 --> 52:44.320
Ich habe eben gesagt, dass wir mit dem Broker das erste große Projekt hatten
52:44.320 --> 52:47.320
und auch sehr ambitionierte Projekt.
52:47.320 --> 52:49.320
Wir hatten natürlich ein bestehendes System,
52:49.320 --> 52:51.320
auf dem wir aufsetzen konnten,
52:51.320 --> 52:53.320
muss aber trotzdem sehr viel neu bauen
52:53.320 --> 52:56.320
und haben es im Endeffekt mit dem vollen Team
52:56.320 --> 53:01.320
dann von Dezember bis ungefähr Juni fertig gebaut.
53:01.320 --> 53:06.320
Natürlich ist natürlich immer ein ganz fertiges Projekt nie,
53:06.320 --> 53:10.320
aber wir sind dann wirklich für den Entkunden live gegangen
53:10.320 --> 53:13.320
und es gibt ja normalerweise immer diese Phase,
53:13.320 --> 53:16.320
wir lassen jetzt die Leute intern, die Mitarbeiter,
53:16.320 --> 53:18.320
schon als Kunden drauf
53:18.320 --> 53:22.320
und es gab extrem wenig, was da wirklich schief gelaufen ist
53:22.320 --> 53:25.320
und das kenne ich sonst auch anders,
53:25.320 --> 53:29.320
weil gerade bei so komplexer Logik
53:29.320 --> 53:31.320
ist die oftmals über das ganze System verteilt
53:31.320 --> 53:34.320
und nur noch schwer irgendwo zu verstehen.
53:34.320 --> 53:37.320
Und früher, als wir damit angefangen waren,
53:37.320 --> 53:39.320
das habe ich wirklich für Logik in meinem System,
53:39.320 --> 53:41.320
das ist doch gar nicht so komplex gemacht,
53:41.320 --> 53:43.320
das sind das überhaupt in eine Ebene rauszuziehen
53:43.320 --> 53:48.320
und hier war es nachher so, ja, es ist doch extrem viel Logik
53:48.320 --> 53:51.320
und es hat uns ganz viel einfacher gemacht,
53:51.320 --> 53:55.320
diese Logik wirklich so zu schreiben,
53:55.320 --> 53:57.320
dass sie alle nachvollziehen konnten
53:57.320 --> 54:00.320
und dadurch auch fehlerfrei war.
54:00.320 --> 54:02.320
Ich würde sogar so weit gehen,
54:02.320 --> 54:04.320
dass ein Teil von einem Code
54:04.320 --> 54:05.320
man auch in einem Nichtprogrammierer
54:05.320 --> 54:07.320
mittlerweile einfach geben kann
54:07.320 --> 54:10.320
und er so grob versteht, was da für Logik drin ist,
54:10.320 --> 54:12.320
weil es einfach so benannt ist
54:12.320 --> 54:18.320
und zum Beispiel, was für Aktien besitzt sich gerade?
54:18.320 --> 54:21.320
Es gibt einfach eine klasse Inventar.
54:21.320 --> 54:24.320
Ein Teil davon wird live berechnet,
54:24.320 --> 54:29.320
ein Teil besteht aus dem, was am Ende des Tages passiert ist,
54:29.320 --> 54:32.320
aber diese Logik, die das zusammengeführt wird,
54:32.320 --> 54:34.320
die geht alles von einer Klasse aus
54:34.320 --> 54:38.320
und man kann das wirklich Schritt für Schritt nachvollziehen
54:38.320 --> 54:41.320
und dadurch, dass dann wirklich keine Infrastruktur,
54:41.320 --> 54:44.320
keine Datenbank, keine API oder so was drin ist,
54:44.320 --> 54:46.320
ist das auch gar nicht so viel Code.
54:46.320 --> 54:48.320
Der andere Aspekt mit der Sicherheit
54:48.320 --> 54:50.320
hatte ich vorher schon mal angeschnitten,
54:50.320 --> 54:51.320
dass man halt eben,
54:51.320 --> 54:54.320
dadurch die Automatikvalidierung drin hat.
54:54.320 --> 54:56.320
Das heißt, es ist eine ID, wo man sagt,
54:56.320 --> 55:00.320
die hat die Rackax oder die Länge,
55:00.320 --> 55:02.320
irgendwelche Zahlen oder sowas,
55:02.320 --> 55:04.320
die dann irgendwelche Constraints haben.
55:04.320 --> 55:07.320
Das kann man direkt alles mit einbauen.
55:07.320 --> 55:10.320
Genau, ich habe ein super Beispiel,
55:10.320 --> 55:14.320
dass aus dem Code Performance Broker live gegangen sind,
55:14.320 --> 55:18.320
Wort war es in der Datenbank geändert von einem Script.
55:18.320 --> 55:20.320
Also nicht über unsere Software,
55:20.320 --> 55:23.320
sondern es war praktisch ein Backgefix über ein Script.
55:23.320 --> 55:25.320
Dann hat die Software das versucht,
55:25.320 --> 55:27.320
aus der Datenbank zu laden
55:27.320 --> 55:30.320
und hat direkt die Kreative gesagt, nee.
55:30.320 --> 55:33.320
Und zwar hat unsere Validierung direkt gesagt
55:33.320 --> 55:35.320
in der Domain-Ebene,
55:35.320 --> 55:38.320
das ist keine valide Kundennummer.
55:38.320 --> 55:40.320
Und da war wirklich dann,
55:40.320 --> 55:42.320
hat ein Zeichen gefehlt in der Datenbank.
55:42.320 --> 55:44.320
Ohne diese Validierung,
55:44.320 --> 55:47.320
also wer validiert was, was ich aus der Datenbank lade.
55:47.320 --> 55:49.320
Ohne diese Validierung
55:49.320 --> 55:52.320
hätten wir das so komplett durch
55:52.320 --> 55:54.320
ans externen System geschickt
55:54.320 --> 55:57.320
und es wäre viel, viel später aufgefallen.
55:57.320 --> 56:00.320
Also da gibt es schon so einige Beispiele,
56:00.320 --> 56:03.320
wo es uns sehr geholfen hat.
56:03.320 --> 56:07.320
Und wo die Fehler einfach viel, viel früher dann auffallen.
56:07.320 --> 56:11.320
Heißt natürlich auch an ein paar Stellen mehr Arbeit,
56:11.320 --> 56:14.320
man muss sich dann immer Gedanken machen, was mache ich hier.
56:14.320 --> 56:18.320
Aber statt jetzt zum Beispiel
56:18.320 --> 56:21.320
alle Intagers in meinem System zusammenzusuchen,
56:21.320 --> 56:25.320
wenn jemand sagt, passt die Rundung an von dem, dem Betrag,
56:25.320 --> 56:27.320
hat man halt eben nicht Intagers,
56:27.320 --> 56:29.320
sondern hat einen konkreten Begriff.
56:29.320 --> 56:32.320
Dann heißt es jetzt nicht mehr Intagers,
56:32.320 --> 56:35.320
das ist jetzt zum Beispiel, das sind meine Zinsen.
56:35.320 --> 56:38.320
Und auf einmal kann ich über die IDE sagen,
56:38.320 --> 56:41.320
ich habe mehr überall, wo ich Zinsen verwende im System zusammen
56:41.320 --> 56:44.320
und kann die dann alle zusammen auch anpassen.
56:44.320 --> 56:49.320
Den einen Punkt, den du noch angesprochen hattest,
56:49.320 --> 56:53.320
war, dass man hat quasi die Kommunikation
56:53.320 --> 56:57.320
in der Software, die man auch in der Firma hat.
56:57.320 --> 57:00.320
Und da habe ich noch die kleine Anekdote dazu,
57:00.320 --> 57:03.320
dass ich das genau so erlebt habe bei dem Projekt,
57:03.320 --> 57:05.320
dass ich hierhin und wieder mal erwähne,
57:05.320 --> 57:08.320
dass auf Microfrontens aufgebaut war.
57:08.320 --> 57:11.320
Aber das war eben erstmal so ein Proof-of-Konzept.
57:11.320 --> 57:13.320
Das heißt, wir wollen erstmal schauen,
57:13.320 --> 57:16.320
das ist in den Microfrontens wirklich das Richtige dafür.
57:16.320 --> 57:18.320
Also haben wir einen wirklich sehr kleinen,
57:18.320 --> 57:22.320
eigentlich gutes Team, aber sehr klein draufgesetzt.
57:22.320 --> 57:26.320
Und es ist uns irre schwer gefallen,
57:26.320 --> 57:30.320
uns selbst als 40-Personen-Team anzusehen und so zu denken,
57:30.320 --> 57:32.320
weil wir hatten zwar Microfrontens.
57:32.320 --> 57:36.320
Und ja, die hatten schon irgendwie so einen Post-Message-Spaß,
57:36.320 --> 57:39.320
über den sie dann kommuniziert haben.
57:39.320 --> 57:43.320
Aber wenn man sich das einfach mal ein bisschen objektiv angeschaut hat,
57:43.320 --> 57:45.320
von oben, war das so, ja, wir hätten das auch alles zusammen
57:45.320 --> 57:47.320
in einem Repo schreiben können.
57:47.320 --> 57:49.320
Also das spricht ja alles mit allem.
57:49.320 --> 57:52.320
Ob das jetzt über ein Message-Spaß über eine Property ist.
57:52.320 --> 57:55.320
Okay, aber nur weil wir jetzt über ein Message-Spaß kommunizieren,
57:55.320 --> 57:59.320
macht das Ding immer noch nicht unabhängig,
57:59.320 --> 58:03.320
dass die eben die verschiedenen Microfrontens oder auf Services wie auch immer,
58:03.320 --> 58:07.320
dann wirklich so abhängig voneinander waren,
58:07.320 --> 58:10.320
dass dieses Prinzip nicht mehr Sinn gemacht hat.
58:10.320 --> 58:14.320
Aber habt ihr dann tatsächlich die Teamstruktur geändert
58:14.320 --> 58:17.320
nach diesen Events-Dorming-Sessions und gesagt,
58:17.320 --> 58:19.320
wir bauen das jetzt anders auf,
58:19.320 --> 58:22.320
sodass das eher für das Produkt oder für die Software passt?
58:22.320 --> 58:25.320
Ja, also natürlich Schritt für Schritt.
58:25.320 --> 58:28.320
So eine Änderung ist nie einfach.
58:28.320 --> 58:30.320
Aber wir haben dann wirklich,
58:30.320 --> 58:34.320
wir haben intern in der Engineering-Abteilung Stripes,
58:34.320 --> 58:36.320
die dann aus mehreren Teams bestehen
58:36.320 --> 58:41.320
und wir haben wirklich Teams zwischen den Stripes verschoben.
58:41.320 --> 58:45.320
Teams, neue Aufgaben, neu benannt.
58:45.320 --> 58:48.320
Was oftmals dann so, also wir haben geguckt,
58:48.320 --> 58:50.320
dass die Änderungen nie zu groß waren.
58:50.320 --> 58:53.320
Aber dann auch immer, wenn irgendeine Änderung anstand
58:53.320 --> 58:55.320
oder wenn irgendwie wieder die Frage war,
58:55.320 --> 58:57.320
okay, wie gehen wir da jetzt weiter vor,
58:57.320 --> 59:01.320
hat man sich dann schon, okay, wie passt das jetzt ins ganze Bild?
59:01.320 --> 59:05.320
Und dann schon Schritt für Schritt das so angepasst.
59:05.320 --> 59:10.320
Und es gibt natürlich dann eben auch Sonderaufgaben.
59:10.320 --> 59:12.320
Also wir haben praktisch Teams,
59:12.320 --> 59:14.320
die als Plattform Teams drunter arbeiten
59:14.320 --> 59:18.320
und sich um gewisse Infrastruktur-Themen kümmern.
59:18.320 --> 59:21.320
Das passt aber auch in unser Bild.
59:21.320 --> 59:23.320
Also da haben wir auch gesagt, okay,
59:23.320 --> 59:28.320
da kann man sich dann um gewisse Themen der Infrastruktur,
59:28.320 --> 59:31.320
Developer Experience oder andere Themen,
59:31.320 --> 59:34.320
die alle Teams betreffen.
59:34.320 --> 59:40.320
Aber dann gerade, ich glaube, ein interessantes Thema war bei uns,
59:40.320 --> 59:43.320
die Produkte, das ist noch mit das Einfachste.
59:43.320 --> 59:45.320
Also wir haben als Hauptprodukte den Broker
59:45.320 --> 59:47.320
und die Vermögensverwaltung,
59:47.320 --> 59:52.320
wobei die sich ja auch gerne co-teilen macht der Sinn.
59:52.320 --> 59:54.320
Wir haben die Linie klarer zu ziehen,
59:54.320 --> 59:56.320
aber der Hauptgewinn war,
59:56.320 --> 59:59.320
wirklich den Kunden raus zu ziehen
59:59.320 --> 01:00:04.320
und zu sagen, okay, Broker und die Vermögensverwaltung teilen sich einen Kunden
01:00:04.320 --> 01:00:06.320
und es gibt ganz, ganz viele Sachen,
01:00:06.320 --> 01:00:08.320
die passieren auf dem Kunden
01:00:08.320 --> 01:00:11.320
und haben jetzt erstmal nichts mit dem Produkt zu tun
01:00:11.320 --> 01:00:14.320
und das klarer zu definieren.
01:00:14.320 --> 01:00:17.320
Das ist einer der Hauptgewinne jetzt bei uns,
01:00:17.320 --> 01:00:20.320
weil das war vorher, ja, da passiert was aus dem Kunden
01:00:20.320 --> 01:00:22.320
und es gab aber jetzt kein Team,
01:00:22.320 --> 01:00:24.320
was so explizit dafür zuständig war
01:00:24.320 --> 01:00:27.320
und da haben wir jetzt gleich mehrere Teams,
01:00:27.320 --> 01:00:30.320
die sich daran fokussieren.
01:00:30.320 --> 01:00:33.320
Aber es ist natürlich immer ein Prozess,
01:00:33.320 --> 01:00:35.320
wo man so Schritt für Schritt hingeht,
01:00:35.320 --> 01:00:38.320
weil jetzt einfach die Teams umbenennen
01:00:38.320 --> 01:00:40.320
und den neuen Aufgaben geben,
01:00:40.320 --> 01:00:42.320
machen wir auch erst mal Chaos,
01:00:42.320 --> 01:00:44.320
weil sie haben bestehende Software,
01:00:44.320 --> 01:00:46.320
um die sie sich kümmern müssen.
01:00:46.320 --> 01:00:49.320
Da muss man aufgucken, wie geht das jetzt weiter.
01:00:49.320 --> 01:00:54.320
Und natürlich hat das auch seine Kosten,
01:00:54.320 --> 01:00:56.320
wenn man jetzt Teams umbenennen,
01:00:56.320 --> 01:00:59.320
verschiebt, andere Aufgaben gibt.
01:00:59.320 --> 01:01:03.320
Aber das habe ich bei uns früh gelernt,
01:01:03.320 --> 01:01:07.320
wenn man nie anfängt, wird es auch nie zu Ende
01:01:07.320 --> 01:01:10.320
und selbst in der kleineren Firma können
01:01:10.320 --> 01:01:13.320
gewisse Migrationen ewig dauern.
01:01:13.320 --> 01:01:15.320
Aber es gibt so viele Sachen,
01:01:15.320 --> 01:01:17.320
die wir irgendwann angefangen haben
01:01:17.320 --> 01:01:19.320
und nicht angefangen hätten,
01:01:19.320 --> 01:01:21.320
wenn wir es jetzt bitter bereuen.
01:01:21.320 --> 01:01:23.320
Es ist natürlich nicht alles perfekt,
01:01:23.320 --> 01:01:26.320
aber da gibt es schon sehr, sehr viele Sachen,
01:01:26.320 --> 01:01:30.320
die so ständig in Bewegung sind.
01:01:30.320 --> 01:01:34.320
Also ich rede gerade auch gegen Big Bang Migrationen.
01:01:34.320 --> 01:01:38.320
Man kann fast alles irgendwie so schleichend machen.
01:01:38.320 --> 01:01:40.320
Man muss halt eben aufpassen,
01:01:40.320 --> 01:01:43.320
dass es dann kontinuierlich iterativ passiert.
01:01:43.320 --> 01:01:45.320
Sonst hat man eine Migration,
01:01:45.320 --> 01:01:49.320
und hat dann den einen Teil vom System,
01:01:49.320 --> 01:01:50.320
der das alte System verwendet,
01:01:50.320 --> 01:01:52.320
den anderen Teil, der das neue verwendet
01:01:52.320 --> 01:01:56.320
und dann nicht wirklich viel gewonnen.
01:01:56.320 --> 01:01:58.320
Das gibt es leider auch.
01:01:58.320 --> 01:02:00.320
Ich würde an dem Punkt sagen,
01:02:00.320 --> 01:02:03.320
wir haben jetzt viele Einblicke auf jeden Fall bekommen
01:02:03.320 --> 01:02:07.320
zum Thema Event-Trip-Design
01:02:07.320 --> 01:02:09.320
und wie man das auch umsetzen kann.
01:02:09.320 --> 01:02:11.320
Kannst du vielleicht nochmal ganz kurz sagen,
01:02:11.320 --> 01:02:14.320
was sind so deine Key-Takeaways,
01:02:14.320 --> 01:02:17.320
warum sollte man jetzt anfangen
01:02:17.320 --> 01:02:19.320
mit Event-Triven-Architecture
01:02:19.320 --> 01:02:21.320
noch mal so als Summary,
01:02:21.320 --> 01:02:25.320
wenn man das jetzt noch nicht in Betracht gezogen hat
01:02:25.320 --> 01:02:27.320
für seine Software?
01:02:27.320 --> 01:02:29.320
Wir sprechen eigentlich von Domain-Triven,
01:02:29.320 --> 01:02:32.320
aber Event-Triven ist auch oft nah dran.
01:02:32.320 --> 01:02:35.320
Es fließen extrem viele Sachen zusammen,
01:02:35.320 --> 01:02:37.320
also auch hexagonale Architektur.
01:02:37.320 --> 01:02:41.320
Das muss ich jetzt nicht zwangshaliger mit Domain-Triven-Design verwenden,
01:02:41.320 --> 01:02:44.320
aber es lässt sich heutzutage ja alles irgendwie,
01:02:44.320 --> 01:02:47.320
weil die meisten sinnvollen Sachen sich ja doch irgendwie
01:02:47.320 --> 01:02:49.320
sinnvoll kommunieren lassen,
01:02:49.320 --> 01:02:51.320
sie ließ das so zusammen
01:02:51.320 --> 01:02:54.320
und in Kombination entfaltet sie es eben noch mehr.
01:02:54.320 --> 01:02:57.320
Wieso sollte man das Ganze verwenden?
01:02:57.320 --> 01:03:02.320
Für mich hat es extrem viele Themen
01:03:02.320 --> 01:03:06.320
oder Sachen erschlagen, die ich über meine Software-Entwickler-Karriere
01:03:06.320 --> 01:03:09.320
so erlebt habe, wo ich früher immer davor schon,
01:03:09.320 --> 01:03:11.320
wie gehört jetzt der Code hin?
01:03:11.320 --> 01:03:13.320
Wie passt es hier zusammen?
01:03:13.320 --> 01:03:15.320
Wo finde ich das im Code?
01:03:15.320 --> 01:03:17.320
Es ist einfach super zu sehen,
01:03:17.320 --> 01:03:20.320
wenn jetzt ein neuer Entwickler ins Team kommt.
01:03:20.320 --> 01:03:25.320
Man erklärt ihm, es gibt diese Schichten im Code
01:03:25.320 --> 01:03:27.320
und da ist die Logik drin
01:03:27.320 --> 01:03:29.320
und das ist genauso benannt wie das Business.
01:03:29.320 --> 01:03:31.320
Das heißt, wenn der Product Owner sagt,
01:03:31.320 --> 01:03:34.320
einer was an X, Y, dann kannst du da reingucken
01:03:34.320 --> 01:03:36.320
und du siehst, das funktioniert einfach.
01:03:36.320 --> 01:03:39.320
Das heißt einfach diese Entwicklergeschwindigkeit
01:03:39.320 --> 01:03:41.320
und dieses Verständnis.
01:03:41.320 --> 01:03:43.320
Das ist einfach extrem viel wert,
01:03:43.320 --> 01:03:45.320
wenn der Code einfach zu verstehen ist.
01:03:45.320 --> 01:03:47.320
Die Leute wissen, wo was zu finden ist.
01:03:47.320 --> 01:03:50.320
Dadurch wird man insgesamt schneller.
01:03:50.320 --> 01:03:52.320
Die Entwickler sind zufriedener.
01:03:52.320 --> 01:03:55.320
Man ist seltener frustriert von dem Berg an Code.
01:03:55.320 --> 01:03:58.320
Es ist natürlich, das kann auch wachsen,
01:03:58.320 --> 01:04:01.320
aber es fühlt sich nicht so schlimm an.
01:04:01.320 --> 01:04:04.320
Und dann halt eben auch auf Business-Ebene,
01:04:04.320 --> 01:04:07.320
das Team macht jetzt die Aufgabe, wo gehört das hin?
01:04:07.320 --> 01:04:10.320
Also viele von den Sachen lässt sich einfach viel einfacher erklären.
01:04:10.320 --> 01:04:13.320
Und wenn man das in so einem Konstrukt drin hat,
01:04:13.320 --> 01:04:16.320
ist auch einfach alles zu verstehen.
01:04:16.320 --> 01:04:20.320
Und ganz wichtig, man bringt damit auch die Leute zusammen.
01:04:20.320 --> 01:04:24.320
Sonst hat man ja gerne in Firmen irgendwelche Meuschen
01:04:24.320 --> 01:04:28.320
zwischen den Entwicklern und irgendwelchen Fachbereichen,
01:04:28.320 --> 01:04:30.320
die dann von unterschiedlichen Sachen reden
01:04:30.320 --> 01:04:33.320
und so bringt man die Leute auch näher zusammen.
01:04:33.320 --> 01:04:35.320
Vielleicht dann noch ein wichtiges Thema.
01:04:35.320 --> 01:04:39.320
Ich hatte beim Bounded Context und ihr bündigt das Language schon erwähnt,
01:04:39.320 --> 01:04:42.320
man kann unterschiedliche Sprachen haben.
01:04:42.320 --> 01:04:44.320
Und das ist kein Problem,
01:04:44.320 --> 01:04:48.320
weil zum Beispiel der Vertrieb, was der in einem Kunden sieht,
01:04:48.320 --> 01:04:51.320
kann was ganz anderes sein als der Kundenservice
01:04:51.320 --> 01:04:54.320
oder praktisch die Produktabteilung davon sieht.
01:04:54.320 --> 01:04:57.320
Und deswegen ist es oft wie für sinnvoller,
01:04:57.320 --> 01:05:01.320
nicht praktisch nur den einen Kunden im System zu haben,
01:05:01.320 --> 01:05:04.320
sondern mehrere Sichten auf den Kunden.
01:05:04.320 --> 01:05:07.320
Zum Beispiel im Customer Relations Management Tool,
01:05:07.320 --> 01:05:10.320
dass man dann da ein anderes Modell vom Kunden hat
01:05:10.320 --> 01:05:13.320
und nicht versucht, zwangsweise alles,
01:05:13.320 --> 01:05:16.320
was irgendwo über einen Kunden gehört, zusammenzuführen.
01:05:16.320 --> 01:05:19.320
Also dass man da auch unterschiedliche Sprachen haben kann,
01:05:19.320 --> 01:05:21.320
unterschiedlichen Bereichen
01:05:21.320 --> 01:05:24.320
und dann teilweise auch dazwischen übersetzen muss.
01:05:24.320 --> 01:05:27.320
Also dass diese ubiquitous Language nicht heißt,
01:05:27.320 --> 01:05:30.320
man muss zwangsweise alles auf ein Modell runterbrechen.
01:05:30.320 --> 01:05:33.320
Natürlich, wenn ich jetzt in einem Produkt trete,
01:05:33.320 --> 01:05:35.320
ist es normalerweise die gleiche Sprache,
01:05:35.320 --> 01:05:38.320
aber so ein Unternehmen hat ja ganz viele Bereiche
01:05:38.320 --> 01:05:41.320
und die haben oftmals ganz andere Anforderungen
01:05:41.320 --> 01:05:45.320
und das hilft natürlich auch, die zu verstehen.
01:05:45.320 --> 01:05:48.320
Das heißt, aus Entwicklersicht würde ich sagen,
01:05:48.320 --> 01:05:50.320
glücklichere Entwickler.
01:05:50.320 --> 01:05:54.320
Also das, was sich die Entwickler normalerweise wünschen,
01:05:54.320 --> 01:05:58.320
man kommt im Code so recht, kann schneller was entwickeln,
01:05:58.320 --> 01:06:01.320
sieht schneller, hey, meine Änderung ist live.
01:06:01.320 --> 01:06:04.320
Das macht Freude.
01:06:04.320 --> 01:06:07.320
Und glückliche Devs sind ja schnelle Features.
01:06:07.320 --> 01:06:09.320
Nicht wahr?
01:06:09.320 --> 01:06:11.320
Ja.
01:06:11.320 --> 01:06:15.320
Du hattest jetzt in und wieder mal so ein Buch erwähnt,
01:06:15.320 --> 01:06:19.320
welche Ressourcen auf Deutsch,
01:06:19.320 --> 01:06:21.320
heißt das Ressourcen auf Deutsch, ich glaube schon.
01:06:21.320 --> 01:06:24.320
Also welche Links hast du denn eigentlich für uns mitgebracht?
01:06:24.320 --> 01:06:27.320
Was sollte man jetzt so nochmal lesen
01:06:27.320 --> 01:06:31.320
und sich anschauen, wenn man dieses Thema nochmal tiefer einsteigen möchte?
01:06:31.320 --> 01:06:35.320
Genau, da gibt es mittlerweile unendlich viel.
01:06:35.320 --> 01:06:39.320
Das Ursprungsbuch ist nicht ganz einfach zu lesen.
01:06:39.320 --> 01:06:42.320
Ich habe es nie von A bis Z gelesen.
01:06:42.320 --> 01:06:44.320
So eine Bibel.
01:06:44.320 --> 01:06:46.320
Ja, das wird auch der Big Club Buch genannt.
01:06:46.320 --> 01:06:48.320
Das ist das Domain-Trip und Design,
01:06:48.320 --> 01:06:51.320
Tackling-Complexity in the Heart of Software von Eric Evans.
01:06:51.320 --> 01:06:53.320
Das ist schon der ganze Titel.
01:06:53.320 --> 01:06:55.320
Ah, ja, ja, das ist ja.
01:06:55.320 --> 01:07:01.320
Das Buch ist gut, aber es sagt einem jetzt nicht unbedingt,
01:07:01.320 --> 01:07:05.320
okay, das heißt jetzt das für dich.
01:07:05.320 --> 01:07:09.320
Weil man überlegt sich dann, okay,
01:07:09.320 --> 01:07:14.320
ja, es sind keine Codebeispiele, also es ist auf abstrakter Ebene
01:07:14.320 --> 01:07:16.320
und es ist jetzt nicht, ich mach mal,
01:07:16.320 --> 01:07:19.320
so macht man das im letzten Reakt, so macht man das in Kotlin
01:07:19.320 --> 01:07:22.320
oder mit dem Spring Framework oder mit der Bibliothek oder sowas.
01:07:22.320 --> 01:07:25.320
Ich habe es nachher als Nachschlagewerk verwendet.
01:07:25.320 --> 01:07:30.320
Eines der besten Bücher war dann erstaunlicherweise,
01:07:30.320 --> 01:07:32.320
leider auch ein langer Titel,
01:07:32.320 --> 01:07:36.320
Patterns, Principles and Practices of the Man-Triven Design.
01:07:36.320 --> 01:07:39.320
Die Beispiele sind in C-Sharp.
01:07:39.320 --> 01:07:42.320
Habe ich zwar auch mal was zum Programmiert,
01:07:42.320 --> 01:07:46.320
war jetzt aber auch nicht so wichtig, aber es gibt praktische Beispiele
01:07:46.320 --> 01:07:49.320
und das Buch ist erstaunlich ehrlich.
01:07:49.320 --> 01:07:52.320
Es gibt Punkte, wo man sich, also wirklich so, du fragst ja,
01:07:52.320 --> 01:07:53.320
wie mache ich das jetzt?
01:07:53.320 --> 01:07:56.320
Und dann liest man den Buch nach und da steht genau die Frage drin
01:07:56.320 --> 01:07:59.320
und dann steht drin die Community diskutiert darüber
01:07:59.320 --> 01:08:00.320
und es gibt zwei Ansichten.
01:08:00.320 --> 01:08:03.320
Hier sind die beiden Ansichten, such dir eine aus.
01:08:03.320 --> 01:08:05.320
Ja, das finde ich aber gut.
01:08:05.320 --> 01:08:07.320
Ich bin immer kein Fan davon, gerade wenn es jetzt, wie gesagt,
01:08:07.320 --> 01:08:09.320
Microfondens hatte ich das Thema
01:08:09.320 --> 01:08:12.320
und ich habe eben auch einige Talks darüber gesehen natürlich,
01:08:12.320 --> 01:08:14.320
weil ich mich ja informieren musste
01:08:14.320 --> 01:08:16.320
und wenn da nur die gute Seite dargestellt wird,
01:08:16.320 --> 01:08:19.320
dann rennt man eben eher in diese Probleme rein und weiß dann nicht,
01:08:19.320 --> 01:08:20.320
was es zu tun ist.
01:08:20.320 --> 01:08:22.320
Mir hat es auch eher geholfen, als Nia mal gesagt wird,
01:08:22.320 --> 01:08:24.320
ja, also dieses Problem wird auf jeden Fall auf dich zukommen.
01:08:24.320 --> 01:08:26.320
Und jetzt kannst du schon mal darüber nachdenken,
01:08:26.320 --> 01:08:29.320
du hast die zwei Lösungsansätze, wir wissen nicht, was besser ist,
01:08:29.320 --> 01:08:31.320
aber eins davon geht schon irgendwie.
01:08:31.320 --> 01:08:33.320
Müsst du halt irgendwie Committon im Team
01:08:33.320 --> 01:08:36.320
und dann immer das gleiche Schema machen
01:08:36.320 --> 01:08:38.320
und dann wird schon irgendwie funktionieren.
01:08:38.320 --> 01:08:43.320
Genau, dann habe ich noch zwei recht inspirierende Konferenzvorträge.
01:08:43.320 --> 01:08:47.320
Der eine ist Making Impossible States Impossible.
01:08:47.320 --> 01:08:49.320
Und da geht es wirklich darum,
01:08:49.320 --> 01:08:52.320
wie kann ich durchs Modulieren sicherstellen,
01:08:52.320 --> 01:08:56.320
dass ich nur was machen kann, was praktisch Sinn macht,
01:08:56.320 --> 01:08:59.320
weil sonst hat man das Ding, jetzt habe ich dann Integer,
01:08:59.320 --> 01:09:01.320
dann String und dann muss ich Validierung bauen,
01:09:01.320 --> 01:09:03.320
damit sichergestellt wird, dass das alles zusammenpasst.
01:09:03.320 --> 01:09:06.320
Und wenn mir zum Beispiel auf CSS geht,
01:09:06.320 --> 01:09:08.320
wo man alles noch richtig kombinieren kann
01:09:08.320 --> 01:09:10.320
und dann das System recht komplex ist,
01:09:10.320 --> 01:09:13.320
ich glaube, das war sogar in dem Vortrag das Beispiel,
01:09:13.320 --> 01:09:17.320
der hat versucht wirklich so CSS zu modulieren,
01:09:17.320 --> 01:09:22.320
aber so, dass man es wirklich dann idiotensicher zusammensetzen kann.
01:09:22.320 --> 01:09:27.320
Im Vortrag war es mit Elm, was ja auch eine ganz interessante Sprache ist
01:09:27.320 --> 01:09:29.320
und was ja auch viel beeinflusst hat.
01:09:29.320 --> 01:09:32.320
Das war so ein bisschen inspirierend, was so möglich ist.
01:09:32.320 --> 01:09:37.320
Und mittlerweile gibt es auch in vielen Sprachen Features,
01:09:37.320 --> 01:09:42.320
wie jetzt Sealed Classes, das heißt, die Vererbungsheraschie
01:09:42.320 --> 01:09:43.320
ist eingeschränkt.
01:09:43.320 --> 01:09:47.320
Das heißt, ich kann jetzt sagen, das ist meine Farbe
01:09:47.320 --> 01:09:49.320
und da gibt es nur fünf Farben drunter.
01:09:49.320 --> 01:09:51.320
Was anderes geht einfach gar nicht
01:09:51.320 --> 01:09:54.320
und damit kann man natürlich im Code viel einfacher darüber argumentieren.
01:09:54.320 --> 01:09:59.320
Der andere Vortrag ist Domain Modeling Made Functional
01:09:59.320 --> 01:10:03.320
von einer Konferenz in Berlin, die ich leider noch nicht besucht habe,
01:10:03.320 --> 01:10:06.320
aber die speziell auf DDD ausgelegt ist
01:10:06.320 --> 01:10:08.320
mit dem Namen Kandinsky.
01:10:08.320 --> 01:10:11.320
Ich gebe es jetzt auch schon seit ein paar Jahren.
01:10:11.320 --> 01:10:15.320
Und Domain Schiffen Design versteht sich recht gut
01:10:15.320 --> 01:10:17.320
mit funktionaler Programmierung,
01:10:17.320 --> 01:10:20.320
was ja auch ein bisschen trendet in den letzten Jahren
01:10:20.320 --> 01:10:23.320
und auch von vielen Leuten gern gesehen wird
01:10:23.320 --> 01:10:28.320
und was oftmals so Sachen einfacher machen kann
01:10:28.320 --> 01:10:30.320
in der richtigen Dosis angewendet.
01:10:30.320 --> 01:10:33.320
Genau, dann habe ich noch DDD Crew.
01:10:33.320 --> 01:10:36.320
Das ist so ein GitHub Repository, wo ein paar Leute
01:10:36.320 --> 01:10:40.320
ganz viele Ressourcen und Domain Schiffen Design sammeln,
01:10:40.320 --> 01:10:44.320
wo man auch einen ganz guten Überblick bekommt.
01:10:44.320 --> 01:10:46.320
Was gibt es da heute?
01:10:46.320 --> 01:10:51.320
Und da gibt es halt eben auch so auf der obersten Ebene,
01:10:51.320 --> 01:10:55.320
okay, wie erkunde ich jetzt das, was ich machen will,
01:10:55.320 --> 01:10:58.320
wie setze ich es dann in kleinen Teilen um,
01:10:58.320 --> 01:11:00.320
wie setze ich es strategisch um und so
01:11:00.320 --> 01:11:03.320
als ganz guter Ausgangspunkt.
01:11:03.320 --> 01:11:06.320
Ich selber habe einen kleinen Artikel dazu geschrieben,
01:11:06.320 --> 01:11:08.320
wie Kotlin ein das Leben vereinfacht,
01:11:08.320 --> 01:11:10.320
wenn man ValueObject schreibt,
01:11:10.320 --> 01:11:13.320
weil ich es als sehr entscheidendem Punkt doch erlebt habe,
01:11:13.320 --> 01:11:16.320
wenn man eine Sprache verwendet, die es einem einfach macht,
01:11:16.320 --> 01:11:18.320
das Ganze umzusetzen.
01:11:18.320 --> 01:11:21.320
Weil wenn ich jetzt für das gleiche Java verwendet hätte
01:11:21.320 --> 01:11:23.320
und dann machst du so ein Webber
01:11:23.320 --> 01:11:26.320
und dann sind das halt irgendwie der CnCode mehr,
01:11:26.320 --> 01:11:29.320
dann ist es halt viel, viel schmerzhafter für die Entwickler,
01:11:29.320 --> 01:11:31.320
das wirklich umzusetzen.
01:11:31.320 --> 01:11:34.320
Und wenn es halt eben die Sprache von sich ergibt,
01:11:34.320 --> 01:11:37.320
dann ist es viel einfacher, das jemanden zu verkaufen.
01:11:37.320 --> 01:11:43.320
Und glücklicherweise hat sich da in den letzten Jahren ja sehr viel getan,
01:11:43.320 --> 01:11:45.320
was bei den Programmiersprachen so passiert ist
01:11:45.320 --> 01:11:47.320
und die einem das Leben dann doch erleichtern.
01:11:47.320 --> 01:11:49.320
Sehr cool.
01:11:49.320 --> 01:11:53.320
Vielen, vielen Dank für den Einblick in die Liste der Ressourcen.
01:11:53.320 --> 01:11:54.320
Auf jeden Fall.
01:11:54.320 --> 01:11:57.320
Da kann man, oder Ressourcen,
01:11:57.320 --> 01:12:01.320
da kann man auf jeden Fall sich jetzt einmal kräftig durchlesen,
01:12:01.320 --> 01:12:03.320
einige Bücher lesen.
01:12:03.320 --> 01:12:06.320
Ich glaube, das ist sehr, sehr hilfreich.
01:12:06.320 --> 01:12:09.320
Auch vielen Dank für diesen praktischen Einblick
01:12:09.320 --> 01:12:13.320
in wie ihr Domain Driven Design umgesetzt habt
01:12:13.320 --> 01:12:15.320
bei Scalable Capital.
01:12:15.320 --> 01:12:17.320
Sehr, sehr interessant.
01:12:17.320 --> 01:12:22.320
Immer wieder interessant, diese Berichte der Art zu hören.
01:12:22.320 --> 01:12:25.320
Und ja, danke dir, dass du da warst
01:12:25.320 --> 01:12:27.320
und es darüber berichtet hast.
01:12:27.320 --> 01:12:28.320
Gerne.
01:12:28.320 --> 01:12:30.320
Damit sind wir am Ende der Sendung.
01:12:30.320 --> 01:12:32.320
Florian, cool, dass du dabei warst.
01:12:32.320 --> 01:12:35.320
Noch mal Danke für den Bericht
01:12:35.320 --> 01:12:39.320
und danke an die Zuhörerinnen und Zuhörer.
01:12:39.320 --> 01:12:43.320
Falls ihr bei euch auch mal Domain Driven Design ausprobiert habt
01:12:43.320 --> 01:12:47.320
in der Vergangenheit und da nochmal ein paar Erfahrungen teilen wollt,
01:12:47.320 --> 01:12:51.320
dann lasst uns das doch mal wissen auf Twitter oder Mastodon.
01:12:51.320 --> 01:12:55.320
Da sind wir unterwegs, ihr kennt es unter dem Handel Working Draft.
01:12:55.320 --> 01:12:59.320
Und wenn ihr sagt, ihr wollt uns gern ein bisschen unterstützen,
01:12:59.320 --> 01:13:01.320
dann schaut mal auf Patreon vorbei.
01:13:01.320 --> 01:13:03.320
Da heißt man auch Working Draft.
01:13:03.320 --> 01:13:05.320
Ihr findet die Links auch auf der Website.
01:13:05.320 --> 01:13:07.320
Danke fürs Zuhören.
01:13:07.320 --> 01:13:09.320
Und dann bis zum nächsten Mal.
01:13:09.320 --> 01:13:11.320
Florian, danke dir nochmal.
01:13:11.320 --> 01:13:14.320
Und gute Nacht und macht's gut.
01:13:14.320 --> 01:13:15.320
Ciao.
01:13:15.320 --> 01:13:22.320
Tschüss.
