Heute geht es um das Thema Architekturentwurf und die Architekturdokumentation. Herzlich willkommen bei unserer ersten echten Episode. Ich bin Sven und bei mir sind Benjamin und Sascha. Ihr dürft auch was sagen. Hallöchen. Hallo. Ja. Wie schon in der Hintergrundepisode erwähnt, kommt es im Produktbusiness eher selten vor, dass man ein neues Produkt von grundauf entwickeln muss. Trotzdem haben alle von uns das glaube ich schon mal gemacht, die Erfahrung gesammelt und zumindest für mich kann ich sagen, das waren nicht nur gute gewesen. Und deswegen fand ich es dieses Mal wichtig, dass wir zusehen, dass wir möglichst mit einer guten Erfahrung am Ende rausgehen. Wie war das bei euch in der Vergangenheit? Hattet ihr schon mal die Erfahrung, mit neuen Produkten von Grund auf oder kamt ihr mal später dazu? Ich hatte auch schon die Erfahrung, neue Sachen zu starten. Auch immer wieder spannend, aber nie so im Detail vorher geplant war eher so ein Proof of Concept, basierter Start. Probiert erstmal aus. Und refactored dann danach. Genau. Ja. Und bei Dir Benjamin? Ja, ich hatte die Erfahrung auch schon. Ich kann auch sagen, es waren nicht nur gute und zwar, wie ich leider sagen muss, trotz ausführlicher Planung und vielen Gedanken. Das stellt leider nicht sicher, dass es am Ende super wird. Genau. Ja. Und wie wollten wir diesmal rangehen? Wie haben wir. Wie sind wir am Anfang gestartet? Na ja, wie man das als Entwickler so macht. Wir haben erst mal ein paar Repositorys aufgesetzt, mit Technologien herumgespielt. Ich weiß nicht. Wir haben alle NoSQL-Datenbanken ausprobiert im Backend und Ähnliches. Sascha Was habt ihr gemacht? Irgendwas mit künstlicher Intelligenz habe ich in Erinnerung. Na Blockchains garantiert Blockchains. Ja, Blockchains, neuronale Netze, alles. Er hat die Buzzwords, die man heute so braucht, einfach mal ausprobiert. Ja, nein, haben wir natürlich nicht gemacht. Stattdessen haben wir mit etwas angefangen, was für die meisten Entwickler wahrscheinlich ein rotes Tuch eher sein wird. Wir haben uns ganz viel Gedanken über Architektur gemacht und haben dann vor allem dokumentiert. Ja dokumentieren klingt wirklich eher nicht so cool. Warum will man das überhaupt tun? Wovor will man sich da schützen? Naja, es führt ganz einfach dazu, dass man sich im Vorfeld über ganz viele Dinge Gedanken macht, über die man sich ansonsten erst im Nachgang Gedanken macht. Und im Nachgang meine ich dann solche Sachen wie "Oh, jetzt brauchen wir hier ja, ach verdammt, wenn wir das vorher vorgesehen hätten, dann wäre es einfach. Jetzt kriegen wir es da kaum noch rein." Und wenn man sich im Vorfeld schon mal ganz viele Gedanken macht, sich überlegt was brauchen wir alles? Was brauchen wir hier, was brauchen wir da, was kommt da auf uns zu, Dann Das schützt nicht vor solchen Situationen, aber man kann ganz, ganz viele solche Sachen umschiffen und hat es dann halt schon vorbereitet und vorgesehen. Zumal ja bei uns noch was Spezielles dazukommt. Wir machen ja nicht einen. Auch wenn ich immer, wenn wir immer vom neuen Produkt reden, hatte ich in der Intro Episode erzählt, dass es ja ein Produkt, was schon mit einem schon bestehenden interagieren wird. Und auch da gibt es ja dann die spannenden Punkte. Wie läuft da das Zusammenspiel zwischen den Produkten, Wo steht überhaupt dieses neue Tool in dem Gesamtkontext des existierenden? Wie sollen da die Schnittstellen aussehen? Und klar, am Ende geht es bei der Architekturdokumentation irgendwie darum, dass man möglichst die vielen Sackgassen, die man trotzdem noch haben wird, erfahrungsgemäß in der Softwareentwicklung aber zumindest auf ein Minimum zu reduzieren. Weil Sackgasse heißt immer verlorene Zeit. Und das ist genau das, was wir im Moment nicht wollen. Das heißt eigentlich die Architekturdokumentation, aus meiner Sicht auch so ein Stück weit eine Checkliste und ein Diskussionsleitfaden, um an möglichst vieles vorher zu denken, wohl wissend, dass es nie alles sein wird, woran man gedacht hat, gedacht haben wird. Ja, genau darauf läuft es hinaus. Letztendlich einfach auch eine Liste von Fragen, die man in der Dokumentation versucht zu beantworten und die einen dazu zwingen, über vieles nachzudenken. Gut. Ja. Und wie sieht so eine Architekturdokumentation aus bzw.. Über was macht man sich da eigentlich Gedanken? Und wer macht sich Gedanken darüber, über was man sich Gedanken machen muss? Also wir haben in dem Fall beschlossen, dass wir auf Arc42 aufsetzen. Das ist letztendlich ein Template für eine Architektur Dokumentation. Die wurde initial entwickelt von Gernot Starke und Peter Joschka. Die hat letztendlich im Grunde nur Kapitel zur Verfügung stellen mit hat dann noch ein paar Hinweisen, was gehört da rein und ein paar Beispieldokumenten. Beide haben halt viel Erfahrung mit Architektur aus verschiedenen Projekten, die sie da haben einfließen lassen. Und inzwischen haben dann auch durchaus noch mehr Leute daran mitgewirkt und ihre Erfahrungen einfließen lassen. Und das hat für uns verschiedene Vorteile gehabt. Zum einen brauchen wir uns, nicht selber Gedanken darüber machen, was wollen wir da jetzt eigentlich alles dokumentieren, sondern wir haben halt schon so ein Gerüst vorgegeben. Zum anderen … ich hatte noch ein zweites im Kopf und jetzt prompt vergessen. Zum anderen haben wir, bauen wir halt auch auf der Erfahrung auf, die andere da gesammelt haben. Die sagen: "Okay, das und das sind die Sachen, die begegnen einem einfach immer wieder, die muss man beantworten oder die sollte man beantworten." Und ja, mit nur bei mir waren es glaube ich drei neue Projekte. Wäre das ein bisschen wenig, um wirklich sinnvoll sagen zu können, was sind die Dinge, über die man sich vorher Gedanken machen sollte? Oft kommt man ja dann doch in so einen Modus, wo man sich denkt, ja, da denkt man später drüber nach. Ungefähr eine Idee haben wir schon. Und dann entstehen doch wieder so spontan Schwierigkeiten. Irgendwelche Blocker, die dann den Fortschritt doch irgendwie verzögern. Genau und untergliedert ist diese Architekturdokumentation in so ein paar Abschnitte. Es gibt noch ein paar mehr als die, die wir genutzt haben, aber das sagen sie auch in der Doku ganz explizit, dass man halt die Sachen füllen soll, die man für sich selber oder auch für das Produkt als notwendig ansieht. Da gibt es dann einmal den Bereich Einführung, und Ziele, wo es auch um Aufgabenstellungen Qualitätsziele geht. Technische und organisatorische Randbedingungen, die da gesetzt sein müssen. Kontextabgrenzung zum Beispiel zu anderen Systemen. Wo steht das System im Gesamtkontext? Lösungsstrategie, dann verschiedene Sichten, Bausteinsicht, Laufzeitsicht, Verteilungssicht, querschnittliche Konzepte, die sich über alles hinweg ziehen und Entwurfsentscheidungen, die da dokumentiert werden. Und da würde ich sagen, dann lass uns nochmal mal kurz in die einzelnen Abschnitte, reingucken und mal gucken, was wir da gemacht haben und ja, vielleicht auch, was für uns mehr nützlicher war als andere Sachen. Genau. Der erste Bereich war das Thema Anforderungen und Qualitätsziele. Bei Anforderungen. Ja, da heißt es auch in dem Dokument, man soll halt hingehen und soll die Anforderungen. Ich glaube, Sie sagen da die Top zehn Anforderungen oder so was die relevant sind für die Architektur aufführen. Finde ich ein bisschen schwierig, weil der Witz ist ja, dass man teilweise bei der Architektur vorher noch gar nicht weiß, welcher Anforderung jetzt wirklich eine große Auswirkungen auf die Architektur haben wird. Deswegen war ich da glaube ich, relativ ausführlich bei dem Kram, dem ich, den ich da reingehauen habe, da steht relativ viel drin. Aber am Ende sind es teilweise auch so ganz banale Anforderungen. Also zum einen natürlich funktionale Sachen, wo ich das Gefühl hatte, okay, das könnte sich auf den Technologie Stack auf den Lösungsweg auswirken. Und zum anderen so banale Sachen wie Internationalisierung ist ganz klar. Erwartet jeder, dass man so was im Softwareprojekt macht. Trotzdem schreiben sie die wenigsten auf. Und oft genug habe ich erlebt, dass es am Anfang genau nicht berücksichtigt wird. Und dann hat man nachher im deutschen Sprachraum Zahlen mit Punkt als Dezimaltrenner anstatt mit Komma, was aber am Ende nicht so gut ankommt. Ein anderes Beispiel was ich da reingenommen habe, war Kollaboration. Wir wollen an ein paar Stellen, dass die Webseite, die das Formular, auf dem man sich da gerade befindet, auch aktualisiert, wenn jemand anders gerade zeitgleich eine Änderung vornimmt. Und das sind natürlich definitiv Sachen, die Auswirkungen auf die auf die Architektur haben, auf das, was wir da am Ende bauen. Der zweite Punkt im einleitenden Kapitel waren dann die Qualitätsziele. Da gibt Arc42, das machen Sie insgesamt. In jedem Abschnitt geben Sie so Kommentare und es gibt auf der Webseite, die wir in den Shownotes verlinkt haben, gibt es auch Infos dazu, was man in die einzelnen Kapitel reinschreiben soll. Aber bei den Qualitätszielen geht es so ums Thema Ausfallsicherheit, Sicherheit, Wartbarkeit, Performance, Betriebbarkeit, Kompatibilität usw. Was haben wir da drin für Themen? Zum einen Thema Mandanten Trennung. Wir bauen eine SaSS Anwendung. Das heißt, wir müssen uns Gedanken machen, wie werden die verschiedenen Kunden voneinander getrennt? Und das muss. Das hat ziemlich erhebliche Auswirkungen darauf, wie man das Ganze aufsetzt. DSGVO. Konformität haben wir drin, Barrierefreiheit drin, Skalierbarkeit, Antwortzeiten usw. Das sind so die Sachen, die ich da reingesetzt habe. Fällt euch da spontan spontan was ein und ihr dürft auch Nein sagen? Wo er sagt Das hat mir. Das hat mir die Erkenntnis gebracht Gut, dass es drinstand. Wenn das da nicht gestanden hätte, dann. Also so, wenn das da nicht drin gestanden hätte, dann wäre alles schiefgegangen. Das würde ich jetzt sagen, nicht. Aber im Ganzen war es auf jeden Fall sehr hilfreich, weil wir über viele Dinge, glaube ich, sonst auch einfach zu spät nachgedacht hätten. Also das Thema, Internationalisierung zum Beispiel. Ja, das ist so. Du hast ja selbst schon gesagt, ist der Klassiker. Aber auch Mandantentrennung, DSGVO-Konformität sind halt zwei Dinge, wo wir halt relativ am Anfang Entscheidungen treffen müssen. Und wenn die dann falsch sind, wird es halt echt schwierig und. DSGVO Konformität. Na ja, bei der DSGVO-Konformität haben wir uns Gedanken über das Logging gemacht. Das ist ja so der Klassiker, dass man dann irgendwo plötzlich, weil es natürlich für die Entwicklung sehr einfach sein kann, Benutzernamen loggt und sich keine Gedanken darüber macht, dass das personenbezogene Daten sind. Selbst wenn es nur Benutzer sind. Und da haben wir uns wirklich in dem Fall schon Gedanken darüber gemacht, wie gehen wir damit um? Denn so für Bug-Tracking kann man sie vielleicht eine Weile aufbewahren, aber auf keinen Fall zu lange. Und darüber muss man sich halt vorher Gedanken machen, sonst steht man irgendwann da und stellt fest okay, so wie wir jetzt loggen, haben wir nur noch die Möglichkeit zu sagen, wir heben unsere Logs maximal eine Stunde auf und schmeißen sie dann weg, weil wir ansonsten Probleme kriegen. Jetzt mal drastisch gesprochen. Und ich bin mir ziemlich sicher, das hätten wir nicht so gemacht, wie wir es jetzt machen, wenn es nicht drin gestanden hätte und wir nicht darüber nachdenken müssen. Mandantentrennung war dann noch auch durchaus eine kleine Herausforderung, als dass wir da ja aus dem anderen Projekt eine Vorgehensweise im Kopf hatten, die wir aber so mit unserem da, wo wir unser Produkt dann hosten werden, gar nicht umsetzen können, so dass wir uns was Neues überlegen mussten. Und ja, auch da, wir haben die Gedanken jetzt gemacht, wir wissen, was wir wollen, wir berücksichtigen es gerade überall schon und. Kann man vielleicht nachher bei der kommt das irgendwann noch mal im späteren Teil. Das müsste bei den querschnittlichen Konzepten kommen oder bei den Lösungsstrategien. Also. Ja. Alles klar. Können wir da noch mal drüber reden? Das war ja schon ein spannender Weg, der tatsächlich auch einige Zeit an Diskussionen eingenommen hat. War bei dir, Sascha, im Frontend Bereich auch irgendwas bei bei den Anforderungen, Randbedingungen oder sonst, wo Du sagst, "Gut, dass ich das vorher wusste" oder bei Anforderungen, Qualitätszielen. Ja, ich stimme mit Benjamin überein, dass es so ist. Alles sehr interessant zu sehen im Vorhinein, wenn man einfach einen High-Level Overview bekommt. Und natürlich fließt das überall ein, so wie jede Werbeanzeige, die man auch sieht, irgendwie auch einen beeinflusst und das schon allein deswegen finde ich es sehr sinnvoll. Ähm, ich glaube aber, es geht auch ohne. Ähm, weil es eben auch nur so ein, High Level Overview ist und im Detail ja dann doch die Features nicht beschrieben sind. Und ähm und im agilen Entwickeln arbeitet man sich ja dann eh immer voran. Aber trotzdem diesen Gesamtüberblick zu haben und vor allem wo will man eigentlich hin? Ist total super. Und ich glaube zumindest Barrierefreiheit war so ein Thema, was da, wo wir uns zumindest vorher auch Gedanken gemacht haben, wie wir das dann umsetzen wollen. Insofern war es gut, das wir das als Qualitätsziel mit aufgeführt haben. Ja. Oder Übersetzungen. Also, wir haben einen SaaS-Service also für eine SaaS-Lösung haben wir uns entschieden? Wir hätten auch einfach denselben Weg gehen können, wie wir vorher gegangen sind und es im Backend speichern, ans Frontend ausliefern? War immer schwierig. Wer pflegt das jetzt ein? Ein PM oder wer auch immer kann jetzt? Wer macht Übersetzungen, wenn neue Sprachen wir hinzufügen? Dann will man, dass das ein externes Büro macht, am aktuellen Produkt da irgendwelche wilden, Excel-Ex- und Importer selbst entwickelt und genau ... Oder auch das Logging. Wir wollen ja Fehler im Frontend mit Fehlern im Backend verknüpfen um das einfach über den gesamten Stack nachvollziehen zu können. Das hätten wir wahrscheinlich dann später nicht so gut einbauen können. Jetzt haben wir aber schon Request-IDs und die Basis steht. Gut, dann gehen wir weiter zum nächsten Thema Randbedingungen. Das war auch noch was, was ich eher ausgefüllt hatte. Da geht es um organisatorische oder technische gesetzte Randbedingungen, die eingehalten werden müssen. Und da ist bei uns zum Beispiel schon mal der grundlegende und schwerwiegende Punkt, dass wir da reingeschrieben haben, wir wollen halt das Produkt auch wie unser Kernprodukt als, SaaS-Lösung, also Software as a Service und als On-Premises Lösung anbieten, weil damit scheiden natürlich eine ganze Menge Lösungswege und Möglichkeiten aus, wenn man dann halt beide Varianten bedienen will. Deswegen musste das da auf jeden Fall mit rein, damit das dann bei der ganzen restlichen Architektur berücksichtigt werden kann. Und ein anderes Thema war halt das Ziel der unabhängigen Entwicklung. Ich hatte ja in der Intro Episode schon gesagt, dass wir quasi ein neues Team aufgebaut haben und wir wollten halt auch, dass beide Teams maximal unabhängig voneinander arbeiten können und das würde nicht gehen, wenn beide im gleichen in der gleichen Codebasis rumhantieren würden. Deswegen war hier ganz klar das Ziel, das neue Produkt als technisch alleinstehendes Produkt, als Self-Contained-System zu bauen, damit die Entwicklungsteams wirklich, unabhängig voneinander arbeiten können. Genau da fällt mir gerade ein. Ich habe in unserer Aufzählung die Kontextabgrenzung, vergessen, als Verzeichnis, als Abschnitt. Willst du zur Kontextabgrenzung? Was sagen Benjamin oder du, Sascha? Das ich das vergessen habe sagt auch schon ein bisschen was. Er hat ein schönes Diagramm, was auch einfach mal so eine Kommunikation zwischen den einzelnen Diensten zeigt und. Und die Abgrenzung vom Kernprodukt zu dem neuen Produkt. Also insofern ist es schon hilfreich, sich das mal vor Augen zu führen. Aber irgendwie gefühlt, das ist nicht das, wo ich hinterher noch mal oft drauf gucke. Ja, es ist durchaus so. Also ich find diese ganzen Diagramme, die da auch noch so drin sind, durchaus hilfreich, um sich viele Sachen vor Augen zu führen. Und das hat auch einiges ausgelöst im Prozess des Werdens, was gemalt haben, rauf geguckt haben und dachten, was ist eigentlich mit und da fehlt doch noch. Das kann einem wirklich dabei helfen, sich noch mal vor Augen zu führen, wie komplex die ganze Thematik eigentlich ist, was so alles dazugehört. Aber es ist, ich denke auch, es ist nichts, wo wir später noch mal draufgucken werden, um dann festzustellen das haben wir richtig gemacht, das haben wir anders gemacht. Ups, die haben ja was vergessen. Es ist, glaube ich eher so, es hilft einfach bei der Architektur Dokumentation und hilft einem dann später. Das war es dann aber auch. Okay, aber dann kommt schon der nächste spannende. Das war nämlich das Thema Lösungsstrategie. Das ist, glaube ich, ein relativ umfangreiches Kapitel bei uns, wo es ja am Ende darum geht, quasi die Anforderungen, Randbedingungen usw., die weiter vorne aufgeführt haben, mit welchen Lösungswegen setzen wir die dann um? Wie wollen wir das erreichen? Habt ihr da da ein paar Beispiele, was da bei uns auftaucht) Also was wir auf jeden Fall drin haben, ist ein Stück weit Technologieauswahl, und zwar für verschiedene Bereiche Backend Frontend, aber auch im Operationsbereich, also dafür, wie rollen wir das Ganze aus? Ja, und auch für die REST Schnittstelle zwischen den Systemen. Ich denke, Technologieauswahl gehen, werden wir irgendwann später noch einmal im Detail drauf eingehen. Bei uns im Backend ist es halt so, dass wir gesagt haben okay, wir verwenden auf jeden Fall Kotlin als Programmiersprache, als Webframework, Ktor statt wie im Java Umfeld eigentlich üblich Spring. Und dann kommen noch so ein paar Details auf, die wir dann irgendwann später noch mal eingehen können. So mit JOOQ für den Datenbankzugriff. Kurzer Überblick fürs Frontend Sascha beim Technologie Stack. Ja, wir dachten wir machen mal was Neues oder eher was Altes. Vanilla JS und jQuery? Oh! Natürlich nicht. Wir haben einfach viel Erfahrung der letzten Jahre mit TypeScript, React gesammelt und uns auch ganz klar dafür entschieden. Ansonsten nutzen wir das Redux-Toolkit, auch die RTK-Query für REST-Requests fürs Routing nehmen wir den react-router-dom. Technologie ist immer das Erste, worüber man redet. Und jetzt habe ich gesagt, wofür das Kapitel Lösungsstrategie war. Und jetzt erzählt mir mal, wie weit haben denn die Anforderungen und die Qualitätsziele und die Randbedingungen zu der Auswahl dieses Technologie Stacks beigetragen? Teilweise ja. Also ich meine letztendlich so was wie welche Programmiersprache verwenden wir oder dann auch im Frontend? Wir wollen da mit React arbeiten oder im Backend mit Ktor. Das ist ja so ein Stück weit die Basis dafür. Aus den Anforderungen ergibt sich irgendwie auch, dass wir den Backend brauchen, dass wir einen Frontend brauchen. Für beides brauchen wir natürlich irgendwie Technologie. Da haben wir halt auch auf Sachen zumindest zum Teil auf Sachen gesetzt, die wir, mit denen wir schon Erfahrungen haben, was halt dann auch klar ist irgendwie. Ansonsten geht es dann halt zum Teil in die Details rein. Also Beispiel Backend. Wir haben uns entschieden, wir verwenden PostgreSQL als Datenbank, also eine relationale Datenbank. Wir hätten ja auch das irgendwie über eine NoSQL Datenbank machen können, was vermutlich in vielen neuen Projekten dann heute eher gemacht wird. Für uns ist es halt so, wenn man sich da mal die Anforderungen anguckt, was da so drinsteht und wie bestimmte Sachen funktionieren sollen. Dann bietet sich einfach eine relationale Datenbank an. Es ist einfach für das, was wir da machen, sinnvoll und deswegen haben wir es auch ausgewählt. Wenn die Anforderungen da anders gewesen wären, hätten es auch gut sein können, dass wir da irgendwie Mongo verwenden oder was auch immer. Irgendwas anderes als eben Postgres. Das ist dann konkret Postgres geworden. Ist es dann auch wieder so eine Sache? Erfahrung haben wir halt schon in einem anderen Produktprojekt eingesetzt und es bringt dann jetzt so bringt für uns keinen Vorteil zu sagen Ja, jetzt in dem Projekt verwenden wir den MSQL-Server oder MySQL oder ähnliches. Insgesamt hat Postgres für uns natürlich auch noch den Vorteil gebracht, dass wir halt doch geballte Erfahrung im Team haben. Aber wie du schon sagst, das Datenmodell hat auch klar gezeigt, dass wir da auch einen Vorteil haben. Ja, ich glaube, im Frontend war es ähnlich. Da war jetzt nix. Nix von den Anforderungen, was wirklich die Technologie Auswahl beeinflusst hat. Weil am Ende ist es halt eine Single Page application, die irgendwie Queries, und Backend stellt und Ergebnisse zurückschickt. Ganz genau. Ganz genau. Internationalisiert also. Kollaboration war dann schon doch auch maßgeblich ein Thema, wo wir uns Gedanken gemacht haben. Da haben wir uns dann für ein Texteditor entschieden, der das ja auch schon mitbringt. Hätten wir das nicht als Anforderung gehabt, wäre es vielleicht auch was anderes geworden, wie jetzt, zu dem wir auch schon im anderen Produktnutzen noch. Na? Haben wir sonst noch so Sachen in Lösungsstrategien jenseits der Technologien, wo wir sagt Mensch, gut, dass wir uns darüber Gedanken gemacht haben. So eine Analytics natürlich. Haben wir uns für eine Proxy Lösung entschieden. Ja, Guter Punkt. Ja, Ja. Dass alles an unser Backend geht und das dann erst. Ja, genau. Ein guter Punkt war auch eine Sache, die glaube ich vorne bei den Anforderungen, was mit Beistand das heißt, gesagt haben. Wir wollen halt die Möglichkeit haben, fürs Produktmanagement auch nachzuvollziehen, wie Nutzer das Produkt nutzen, damit wir es dann zielgerichtet entsprechend optimieren können. Und wie du schon sagst, da gibt es ja auch verschiedene Lösungsansätze. Also im Endeffekt spielt es halt auch bei vielen Punkten dann eine Rolle. Also bei den Lösungsstrategien haben wir im Endeffekt dann auch Tabellen drin, wo wir wirklich auf jede Anforderung eingehen und sagen, wie wollen wir das umsetzen. Und beim Thema Sicherheit taucht dann zum Beispiel auch wieder ein Backend Technologie aus. Wir verwenden JOOQ, um die Datenbankzugriffe zu machen. Hätte ich sowieso bevorzugt. Hat für uns an der Stelle den Vorteil, dass gleich SQL Injection ausgeschlossen ist. Und von daher hat die Technologieauswahl natürlich an vielen Stellen ganz eng was mit den Anforderungen zu tun. Ja auch wenn sie an vielen Stellen auch dem geschuldet ist, dass wir gesagt haben, wir wollen auch möglichst hier mit Sachen arbeiten, wo wir schon Ahnung von haben, um schnell voranzukommen, und nicht erst mit einem neuen steckt, der uns das Blaue vom Himmel verspricht, wo sich dann in der Realität doch herausstellt, dass es so schön nicht ist. Wer dann im Laufenden in der laufenden Entwicklung konfrontiert sind. Ja, und auch das kommt ja von den Anforderungen, denn da stand ja irgendwo auch drin, dass wir einen gewissen Zeithorizont haben, wann wir was fertig haben wollen. Guter Punkt. Ja, das war bei den. Und daraus, daraus ergibt sich das einfach, auch wenn wir, wenn es halt so gewesen wäre, dass wir gesagt hätten ja, ist jetzt egal, es kann 3456 Jahre dauern. Vielleicht hätten wir an ein paar Stellen andere Entscheidungen getroffen und hätten gesagt na ja, auch dann lass uns doch mal das probieren, Das könnte super sein. Na ja, es war bei den Randbedingungen, aber da stand halt mit dran. Das war halt einfach eine vorgegebene Zeit, in der wir was releasen wollen. Damit war zum einen Feedback von den Kunden sammeln und natürlich das wir darüber dann auch die Entwicklung durch Umsätze wieder finanzieren können. Gut. Ja und dann kommen da drei sone Ansichten. Die Bausteinansicht, die Laufzeitsicht und die Verteilungssicht. Ich glaube. Kann. Kann ich am ehesten was sagen. War fürs Backend am meisten zu zeichnen. Also erst mal bei der. Bei der Bausteinansicht geht so ein bisschen um so eine. Ja, und um einen Blick auf aus der Vogelperspektive auf das Projekt. Ja, man guckt sich halt erst mal an wie. Wie sieht es wirklich ganz von außen aus, auch mit so ein paar äußeren Systemen, mit denen man noch zusammenarbeitet. Und dann sucht man bei Bedarf noch ein bisschen genauer auf in bestimmte Komponenten rein. Nicht auf der obersten sich, weil dann halt eine Komponente wirklich unser neues Produkt und dann kann man da auch noch mal so ein bisschen reingucken, was sind da vielleicht noch für einzelne Dienste mit drin? Und, das kann halt auch dazu führen, dass man sich ein paar Stellen einfach noch, mal ein bisschen Gedanken darüber macht, was habe ich denn hier für Komponenten drin? Und vor allem wie sehen die Schnittstellen von den Komponenten aus? Denn das ist eine Sache, muss man natürlich nicht so machen, aber es hat vorgeschlagen, vorgeschlagen, dass man eben die Schnittstellen von den einzelnen Komponenten dokumentiert. Also was ist das für ein Protokoll, wofür dient diese Schnittstelle usw. Und so fort. Und ja, hilft noch mal, um sich ein paar Sachen ein bisschen strukturiert zu überlegen. Fürs Frontend war da eigentlich nicht viel zu tun. Und das ist auch ein Punkt, den ich mich oft bei diesem, bei dieser Architekturdokumentation gefragt habe. Aus welcher Perspektive sieht man das jetzt aus der Applikation Sicht oder wirklich, nur aus der Frontend Stack sicht oder aus der Backend Stack sicht? Weil selbst wenn man, wenn man es aus der Frontend Stack sicht betrachtet, dann könnte man da ja auch ein Diagramm zeichnen. Bestimmte Services kommunizieren miteinander und die Frage Was will man eigentlich erreichen mit dieser Architektur Dokumentation? Ja, ich glaube, da kommt man in den Bereich rein. Was bildet man überhaupt in so einer Architektur Dokumentation ab? Da würde ich mich am Ende noch mal dazu kommen, weil man darf glaube ich nicht in die Gefahr reinlaufen, dass man zu detailliert wird. Das ist ja das, was ich früher noch an der Uni gelernt habe mit UML Diagramme zeichnen, um eine Software zu entwerfen bis runter auf Klassen Ebene. Das ist halt einfach Unfug, weil das bricht sofort zusammen, sobald man die ersten Zeilen Code schreibt, sondern es geht halt wirklich um die Metaebene. Da wo ich den Grundstein lege, den ich im Nachhinein nicht ohne Weiteres mehr ändern kann. Und das betrifft dann tatsächlich eher doch eher den Betrieb Sport. Und bei uns ist das ein bisschen schwierig, weil da halt die Trennung zwischen Becken und Frontend auch relativ hart ist und aus Frontend Sicht klar, der Kram läuft halt im Browser und da, wo ich kein Verteilungsdiagramm für die Single Page Applikation läuft im Browser Punkt, Aus, Ende. Egal wie viele Services die intern noch hat. Aber wenn man das Gesamtprodukt betrachtet, dann ist die Verteilung halt schon superspannend, um zu sehen, was für Dienste gibt es überhaupt, auf welchen Infrastrukturknoten laufen die, wie werden die betrieben usw.. So ist das dann auch bei den nächsten sich genauso. In der Laufzeitsicht haben wir so ein paar Diagramme drin. Wie sieht die Initialisierung aus? Also es kommt ein neuer Kunde dazu, der das Produkt nutzt. Wie ist jetzt also der Fluss? Was passiert an irgendwelchen Stellen? Da haben wir auch noch mal ein bisschen ausführlicher ausgeführt. Wie sieht eigentlich die Anmeldung aus? Weil da auch verschiedene Systeme involviert sind und weil wir auch ich weiß nicht, wie viele Runden dazu gedreht haben, wie das jetzt alles genau laufen soll. Und da ist es dann auch tatsächlich durchaus mal hilfreich, da später rein zu gucken, wenn irgendwas nicht so ganz richtig funktioniert und man nicht so ganz versteht, warum und was an welcher Stelle passiert. Wenn man sich die Diagramme anguckt, dann sieht man einfach auch, wie kompliziert und komplexes ist und kann dann vielleicht ein bisschen besser verstehen, warum an irgendeiner Stelle ein Fehler auftritt. Gut verteilt sich hatte ich eben schon. So ein bisschen angewidert habe ich vorgegriffen. Wir haben ja kein Problem. Ja, im Prinzip. Genau. Was läuft wo? Hatten wir auch irgendwo was drin? Welche Repository gibt es? Welches Tool liegt da? Das ist in der Verteilung sicher mit drin. Auch in der Verteilung. Sehe ich. Ja, da gibt es am Anfang so ein paar Stories und rund einem Artefakt und da ist das mit drin. Ja, was heutzutage auch spannend in Zeiten von Microsoft ist usw. Da hat man halt einfach mehrere Sachen. Auch wenn wir jetzt nicht exzessiv Microservices machen, weil wir da der Meinung sind, am Ende wird es vom gleichen Team gepflegt und dann macht es halt nur Sinn, wenn es wirklich andere weitere Betriebsvorteile zum Beispiel bringt, eine bestimmte Sachen Microservice rauszuziehen. Aber nichtsdestotrotz gibt es einfach mehrere Tools, mehrere Repository mit mehreren Buildchanges und von daher schon ganz gut, sich auch da vorher Gedanken zu machen. Wie will man das in der ersten Inkarnation aufsplitten? Gut so, dann kommt eines der auch wieder umfangreicheren, zumindest in meiner Wahrnehmung. Das sind die querschnittlichen Konzepte. So nennt sich das. Und wie der Name schon sagt, geht es ja da darum, im Prinzip die Sachen abzubilden, die sich irgendwie so durch die ganze Anwendung durchziehen. Was ab, dann haben wir dafür Beispiele. Also fürs Becken zwei große Punkte, die, die mir da auch sehr wichtig waren. Einmal funktionale Programmierung, also Objekte sind unveränderlich und so was wie ein war. Verwenden wir, wenn es nötig ist, dann aber bitte im kleinst möglichen Scope, und auch so das Thema Fehlerbehandlung, dass nicht überall Exceptions fliegen sonst wohin. Sondern dass wir versuchen, das sauber funktional abzufangen mit entweder dem Kotlin result oder auch dem davon von Error. Und wir haben. Da kommt er schnell wieder durch. Aber bin ich dabei? Sascha war aus Frontend Sicht was drin gehabt bei den Querschnittskonzepten? Bei uns war das eigentlich ähnlich. Ich fand es auch super, dort einfach so ein paar Rahmenbedingungen festzulegen. Wie soll das denn entwickelt werden? Wie werden Tests geschrieben? Wie. Wie machen wir einen Komponentenschnitt? Genau. Machen wir jetzt überall REST-Requests oder machen wir das nur in bestimmten Schichten? Wo behandeln wir ihn? State ist ja immer global, ist in der Komponente. Sachen haben wir da festgelegt oder auch, dass wir einfach nur async await nehmen wollen und eben kein Promise. Und ich finde das super, auch fürs Onboarding. Wenn jemand neu ins Team kommt, kann er sich da auch einlesen und kriegt dann sofort den Überblick, wie wir, die wir die ganze Applikation halt auch gestalten wollen. Genau einfach so gewisse Best Practices, die wir da entsprechend berücksichtigen wollen. Na ja, was ich noch an spannenden Punkten fand, war das Thema maximale Zustandslosigkeit im Backend. Muss halt einfach darum geht, die Anwendung auch skalierbar zu gestalten. Und Stichwort perfekter App. Da haben wir schon gesagt, wir haben noch mal eine eigene Episode zu machen. Aber auch Themen wie Authentifizierung, Feature, Tools und so. Also dass einfach eine ganze Menge drin, was einen als Entwickler bewegt und was dann teilweise auch beim Ausfüllen der anderen Abschnitte Fragen aufgeworfen hat, die dann an der Stelle beantwortet worden. Dann gehen wir zu einem. Letzten Abschnitt, der jetzt für uns relevant war, zu den Entwurfs entscheidungen. Magst du noch was erzählen? Benjamin? Also, worum geht es an der Stelle? Ich kenne das aus anderen Projekten. Wenn die ein bisschen älter werden, dann kommt irgendwann der Moment, wo jemand meint Ach, das hier, das ist doch. Es ist doch so nicht gut. Sollten wir mal umbauen und dann gibt es auch tolle Ideen. Und dann gibt es immer irgendeinen, der ankommt und sagt Ja, aber da gab es doch bestimmt mal gute Gründe, um das so zu machen, wie es jetzt ist. Ähm, ist immer so mein Lieblingsargument. Mir geht es dann immer so, dass ich denke, erstens glaube ich das nicht unbedingt, denn sehr oft passieren Dinge einfach so, ohne dass sich jemand groß Gedanken macht. Oft ist es auch irgendwas. Das ist dann gedacht als Ja, ich mache das jetzt mal erstmal so, das ist jetzt quick and dirty, das müssen wir noch mal sauber machen, aber es passiert dann eben nie. Ein anderer wichtiger Punkt dabei ist natürlich Es magister ja sein, dass es mal gute Gründe gab. Das heißt aber nicht, dass die immer noch gut sind oder dass es nicht inzwischen bessere Gründe gibt, es anders zu machen. Und dafür sind die einfachsten Entscheidungen da, dass man halt für bestimmte Sachen, bei denen man halt wirklich sagt, die sind uns wichtig, dass man da halt dokumentiert, was haben wir entschieden, auch wer hat es entschieden, und was waren die Gründe dafür? Und da gibt es halt auch verschiedene Wege, wie man das machen kann. Wir haben uns da auch für so ein Modell entschieden. Das ist so ein Wir, heißt das ADR, glaube ich. Architektur, Design, Record, wo man halt bestimmte Hinweise gibt. So was war praktisch das Problem, was man sich angeguckt hat, Wofür hat man sich entschieden und was sind auch die Konsequenzen daraus? Denn die Konsequenzen aus einer Entscheidung sind ja nicht unbedingt alle gut, sondern es kann ja immer auch sein, dass man sich für irgendwas entscheidet, wo man dann schon selbst weiß, okay, das bedeutet, an der und der Stelle müssen wir das und das beachten, sonst kriegen wir Probleme. Sogar fast immer so sein. Ja, genau. Wenn man ehrlich ist, wird es immer so sein. Aber das sind halt trotzdem Sachen, wo es dann einfach auch gut ist zu zeigen, das war uns bewusst, Darüber haben wir uns Gedanken gemacht und wir haben uns aus den und den Gründen trotzdem dafür entschieden, das so zu machen. Ja, interessant ist auch immer dann durchaus mal auszuführen, was waren denn die Alternativen, die wir uns angeguckt haben? Denn das ist ja auch genau so eine Sache. Gerade wenn es vielleicht um Technologie Auswahl gibt, kann es sein. Dann hat sich Technologie A und B angeguckt, hat sich für A entschieden. Inzwischen gibt es aber C und D und die sind in beider Hinsicht besser. Dann kann man halt auch später noch mal überlegen, lohnt sich es jetzt vielleicht, da umzusteigen oder ähnliches? Ja, von daher ist diese Dokumentation einfach auch sehr, sehr wichtig für die Zukunft. Ab da konkrete Beispiele, was wir da für Sachen drin haben. Die so währenddessen aufgekommen sind. Mir fällt da sofort das Paket ein, das Contract Testing, wo wir dann irgendwie. Okay? Ja. Festgestellt haben, es ist super, aber es bietet eigentlich nicht die Sicherheit, die wir suchen. Und dass Testing da einfach noch einen Mehrwert bietet, nämlich dann wirklich die Sicherheit, dass es auch funktioniert und nicht nur der Rest core. Na, das heißt, da haben wir prompt einen Punkt, den wir in der Architekturdokumentation beschlossen hatten, wo sich jetzt in der Realität dann auch schon herausgestellt hat, dass das halt keine ideale Entscheidung war. Ich weiß. Ich habe mir das dann noch in die in das Kapitel aufgenommene Unterscheidung. Noch nicht. Das steht noch auf einer To Do Liste von mir. Steht noch auf der Liste. Aber gut, das ist ja angerissen hast Testing wollte mir auch noch mal eine eigene Episode zu machen. Da können wir noch mal auf die Vor und Nachteile da im Detail eingehen. Was ich noch in Erinnerung habe, ist das Thema Server Send Events versus Websockels. Also wie wollen wir diesen Collaboration Sport quasi technisch umsetzen? Da haben wir uns auch die verschiedenen Varianten mit ihren Vor und Nachteilen angeguckt und uns dafür einen Weg entschieden. Würde ich sagen. Gehen wir auch erst im Detail drüber, wenn es die erst mal dann auch wirklich umgesetzt und angewendet haben. Ja, und auch ein anderes Thema Wie wollen wir Anhänge zum Beispiel speichern? Dass wir die in einem Paket ablegen wollen und nicht in der Datenbank. Das waren so Sachen, über die wir im Laufe der Zeit diskutiert hatten und die weitere dann eingepflegt haben. Für mich. Ein großer Punkt war auch noch das Thema Messagebroker. Ich meine, ursprünglich war ja mal quasi Kafka gesetzt, einfach weil wir es halt auch im Produkt mit drin haben. Und da haben wir uns dann ja auch im Grunde ausgelöst durch die Hostinganbieter und da ist das, was die als Service anbieten, gedacht. Okay, sollten wir vielleicht doch noch mal hinterfragen, ob wir wirklich Kafka nehmen und haben uns dann ja am Ende stattdessen dafür entschieden, Rabbit im Cube einzusetzen. Das ist auch genau so ein Punkt, wo da in der Architekturdokumentation eben, auch einiges an Konsequenzen drin steht. War Zeit für uns. Eine neue Technologie ist da, müssen wir uns erst mal einarbeiten. Dann haben wir halt auch ein paar bestehende Services, die wir halt auch bei uns in der Umgebung noch mal einsetzen wollen, die bisher alle darauf basieren, dass sie mehr Nachrichten von Kafka verarbeiten. Und die müssen natürlich dann so umgebaut werden, dass sie auch mit Rabbit umgehen können. Also von daher ist das halt auch eine Entscheidung gewesen, die einiges an Auswirkungen hat, auch langfristig. Und gerade da ist es dann wirklich sehr, sehr gut, wenn man das dokumentiert hat und auch die Gründe dafür dokumentiert hat. Aber da bei uns die langfristige, langfristige Peace of Mind, dass wir da eine Komponente haben, um die wir uns nicht kümmern müssen, sondern um die sich der Rechenzentrum sbetreiber kümmert, hat da den Ausschlag gegeben. Quasi an der Stelle. Wobei wir gleich noch mitbekommen haben, dass wir doch an einigen Stellen auch Vorzüge sehen in der Lösung. In dem Kubus ist Kafka für unseren Anwendungsfall. Ja, definitiv. Definitiv. Gut. Ja. Na, dann haben wir ja quasi jetzt einmal so die Abschnitte, die für uns maßgeblich waren, sind wir mal durchgegangen und wir haben die ganze Zeit hier davon geredet. Da schreibt man Abschnitte und da zeichnet man Grafiken wie hatten das technisch stattgefunden? Weil als Entwickler will man das sicherlich nicht in Word machen. Latex ist auch ein bisschen out of date und schon gar nicht, wenn man in irgendwelchen Grafikprogramm rummalen. Wie haben wir das gelöst? Also erst mal grundsätzlich. Für das Dokument haben wir ASK verwendet. Es hat einfach ein Format, ähnlich wie Mark Down kann nur deutlich mehr und, für die Grafiken haben wir Plandom verwendet. Es hat im Grunde eine ganz einfache Entscheidung. Man hat dann halt auch die Grafiken im Text drin. Einfach ein textuelles Format. Man sieht dann auch, kann sich Views angucken, wenn man das Ganze in gepflegt. Das ist halt ganz anders als bei einem Grafikprogramm, wo man dann rumzeichnet und Ähnliches hat. Die Hürde ist viel geringer das anzupassen, weil ich halt einfach in meine Entwicklungsumgebung reingehe, eben was an der Grafik ändere in der gleichen Datei, wo auch der Text drumrum drinsteht. Und wie du schon sagst, ich sehe dann hinterher auch den Diff und habe das auch versioniert. Wenn ich erst ein Grafikprogramm aufmachen muss dadrin zeichnen, dann muss ich den Kram noch in irgendeinem Format exportieren. Die exportierte Datei muss ich irgendwo ablegen. Ich spiele da auf dich Ladig. So war das da ja früher gewesen. Das ist dann einfach ein echtes Hindernis. Dann überlegt man sich zweimal, ob es wirklich so richtig ist, jetzt diese Grafik noch mal anzupassen. Ja, also man muss natürlich sagen, bei dem Grafikprogramm hat man den Vorteil, dass man es schöner hinkriegt. Man kann halt jede Box genau dahin schieben, wo man sie haben will. Das geht mit Planung mal nicht da ganz im Gegenteil. Manchmal kriegt man Ergebnisse, wo man irritiert draufguckt und denkt Warum ordnest du das jetzt so an? Da gibt es dann auch ein paar Tricks, wie man das Design beeinflussen kann. Ich kann nur raten, da nicht zu viel zu machen. Dann verschwendet man nämlich sehr, sehr viel Zeit. Irgendwann im Endeffekt, wenn man auf die Grafik guckt und denkt, sie drückt das aus, was ich haben will, ist ganz schön, dann reicht das auch aus. Genau das ist ja genau der Scooby Plan. Ich will möglichst schnell eine Grafik haben und die soll. Die muss nicht so aussehen, dass ich mir sie als Poster übers Bett hänge. Zumindest nicht mein Anspruch und. Sondern es geht eher darum, schnell und pragmatisch das darzustellen, was man eigentlich ausdrücken will. Ja. Dann hatte ich ja schon angedeutet, dass wir damit gut gearbeitet haben. Also gehostet auf GitLab, was dann auch den Vorteil hat, dass nativ mit ASC, auch ganz gut umgehen kann. Und unsere Änderungen liefen dann halt auch so ab, dass wir da immer auf Brandschutz gearbeitet haben, dann Merge-Request s erstellt haben, wo wir dann halt auch immer sagten, also in der Anfangsphase haben wir wirklich, gesagt, sollte sich jeder angucken, selbst wenn es Frontend Themen waren, haben wir alles aus dem Becken rausgekauft geguckt und umgekehrt. Ist vielleicht ein bisschen übertrieben. Es hat dann aber schon den Vorteil, dass jeder irgendwie mal ein bisschen was davon mitgekriegt hat, was eigentlich das andere Team da so Relevantes plant. Ja genau. Und dadurch war ich auch im Alltag involviert, ohne dass ich jedes Mal das ganze Dokument durchlesen musste, sondern konnte immer gezielt den Merge-Request s auf die Fragen mit eingehen. Und ich muss ja sagen Merge-Request s. Ich oute mich jetzt schon und das ist ja ein Grund, der der Name Merge-Request ist schon ein Grund zu GitLab zu gehen. Kann mir irgendjemand erklären, warum die Dinger woanders Pull-Request heißen? Ich habe es noch nie kapiert. Gute Frage, weil es vielleicht um Push und Pull geht. Aber ich werde ja nicht aufgefordert, den Kram zu pullen. Ich werde aufgefordert, ein anderes Thema. Kann man machen zu machen. Ich glaube nicht. Da bräuchten wir dann nur jemanden dabei, der uns das erklären kann. Welch kommt es aus der Zeit, wo man das Lokal noch gemacht hat? Den Radio. Das heißt man pult erst mal die Changes, guckt sich den Diff an? Es sind. Ja, das kann natürlich sein. Stimmt. Wo man noch nicht die coolen Tools, wo man es online gemacht hat, sondern sich das Lokal angeguckt hat. So wird es sein. Hm. Eigentlich bin ich alt genug, um das zu wissen. Aber gut, genau. Ja, also wie gesagt, ich fand den Weg super mit das Über GitLab und mit Metrik festmachen. Das hat sich nach hinten raus ein bisschen gezogen. Also ich glaube, wir hatten ursprünglich gehofft, dass wir im September durch sind. Wir hatten, glaube ich, Mitte September angefangen. Am Ende hat die Architektur Dokumentation bis in den November rein geblutet, um es mal so martialisch zu formulieren, weil dann halt doch noch diverse Detailthemen offen waren und die Merge-Request ein bisschen hin und her gingen. Da hatte ich auch den Eindruck bei euch, dass das dann nach hinten raus so ein bisschen die Ungeduld zugenommen hat. Ja, wir haben auch nebenbei schon angefangen, CPUs aufzusetzen, GitLab mehr oder weniger auszuprobieren. Wie funktioniert es das sie die Pipelines und einfach ein bisschen Code schreiben und gucken wo kann ich starten? Und haben nebenbei dann noch das Dokument abgeschlossen? War es ein guter Punkt. Ich habe gar nicht nachgeguckt, was da so an Zeit reingeflossen ist, aber ich würd mal sagen, also September und erste Hälfte vom Oktober habe ich den Eindruck, dass man schon sehr konzentriert an dem Thema gearbeitet. Ja fast ausschließlich. Ja und das schon krass mit vier Leuten, wo man dann so dachte Meine Güte, und wir machen bisher nichts, als virtuelles Papier zu produzieren. Im Backend waren wir auch ein bisschen länger dran als Frontend, was halt einfach der Tatsache geschuldet ist, dass da schon mehr drin war, was fürs Backend relevant ist. Naja, man muss ja auch die ganzen Diagramme zeichnen. Naja. Genau. Und die mussten gut aussehen. Aber. Aber ich hatte wirklich bis zum Ende Freude an den Diskussionen, die weiter geführt haben und hatte wirklich den Eindruck, dass es auch echt Wert bringt. Ich glaube, ansonsten hat man es auch nicht gemacht bei den Themen, die wir nicht wichtig fanden. Die hätten wir dann auch abgebrochen. Aber das fand ich schon echt gut, auch wenn es einen genervt hat, dass man das Gefühl hatte Verdammt, das ist noch nicht vorbei, Wir wollen jetzt jetzt Features produzieren. Also ich zumindest. Produzieren lassen. Gut, damit sind wir schon bei den Erkenntnissen. Da komme ich jetzt mal mit ketzerischen Fragen. Ja, wenns ein. Wenn du nur einen Abschnitt aus dem Dokument behalten dürftest oder ihr nur einen Abschnitt aus dem Dokument behalten dürftet, was wäre da? Der wurde sagst Das ist der wichtigste für mich. Der, der. Der bringt mir am meisten oder hat mir bei der Erstellung am meisten gebracht oder da würde ich noch am häufigsten reingucken. Fangen wir mal mit Sascha. Also für mich war das der Logging abschnitt von Fehlern. Also im Moment fühlen wir es ja noch nicht, weil wir nicht so viele Fehler haben, und vor allem auch keine Kunden, die den Fehler produzieren. Aber ich denke das wird super und da freu ich mich schon richtig drauf, das auch zu nutzen, um Sachen zu debuggen und dabei richtig Bock. Und was war da das? Fehler einbauen, Sascha. Und was war der Mehrwert der Architektur? Dokumentation? Na ja, wir haben uns wirklich intensiv Gedanken darüber gemacht, Wie können wir da den größten Mehrwert auch für Kunden bieten, so dass sie den Fehler übermitteln können, dass wir ihn gut tracken können. Ja. Und bei dir, Benjamin? Der wichtigste Abschnitt. Nee, nee, darf auch. Muss ich so weit runter gehen auf dem Unterkapitel, denn für mich werden die querschnittlichen Konzepte als Ganzes. Da steckt halt enorm viel drin, was für uns an Gedanken gemacht haben. Auch Kommunikation zwischen Beck und Frontend. Und wie machen wir die es? Wie machen wir das bei der Authentifizierung und Autorisierung? Ich weiß nicht, wie viele Meetings wir dazu hatten und wie oft ein gewisser Sven bei mir ankam und dachte Ah, ich habe da nochmal was gelesen, das sollten wir doch so machen und nicht so. Und dann konnte ich wieder mal gucken, ob das überhaupt so geht und wie und warum. Und Diagramme neuzeichnen und so. Aber das hat in Summe enorm viel gebracht. Okay. Auch mein zweiter Lieblingsabschnitt. Ganz klar. Und ja, da darf natürlich die gegenteilige Frage nicht fehlen. So im Nachhinein betrachtet gibt es, wenn da ein Abschnitt oder wenn ihr einen Abschnitt rausschmeißen müsstet, jeder aus dem Dokument, welcher wäre das, wo er sagt, der ist im Prinzip am wenigsten natürlich an Anforderungen, sagt nicht Anforderungen. Nein, nein, das wäre für mich der Anhang A Glossar. Da steht nämlich nichts drin. Ne? Komm jetzt hier ein von denen, die wir doch durchgesprochen haben. Okay, dann wäre es, glaube ich, am ehesten die Verteilungssicht. Okay. Also da ist doch. Ich. Ich bin mir bei den Sachen auch nicht wichtig, nicht sicher, ob da nicht sehr, sehr vieles ist, was sich dann später noch ändern wird, wenn es dann doch anders läuft. Da hätte ich zumindest mal das Gefühl, dass wir mehr Sachen da gemacht haben, wo wir zu detailliert gewesen sind für die Architektur Dokumentation. Hmmm. Okay. Und bei dir, Sascha, Gibt es auch so was? Ja. Tue ich mich schwer, weil viele nicht betroffen und die wenigen Punkte, die dann runter betroffen haben, die waren dann doch schon irgendwo nützlich. Aber wenn du mich fragst und nicht unbedingt was auswählen müsste. Und natürlich. Dann ist es wahrscheinlich die Technologie Auswahl, weil viele Sachen waren einfach klar für uns, TypeScript Tests usw. und so fort. Und wir haben es natürlich noch mal noch mal drüber nachgedacht, ob es doch das Richtige ist und sind dann teilweise auch wieder abgekommen von unserer ersten Entscheidung und haben was Neues ausprobiert. Aber das hätten wir wahrscheinlich trotzdem gemacht, auch ohne das aufgeschrieben zu haben. Da kann ich total nachvollziehen, dass man da wahrscheinlich die Sachen, wo des Schreibenden home run war, weil man nicht lange darüber nachdenken musste, einfach hingegangen ist und gesagt hat Super, schreibe ich jetzt auf, da weiß ich jetzt nicht, was da reinkommt. Ich lange drüber zu überlegen. Und da war dann auch der Merge-Request schnell durch. Gut. Ja. Denn noch so eine Frage. Wo haben wir aufgrund des Architekturdokuments Entscheidungen getroffen, an die wir sonst nicht gedacht hätten? Es ist vielleicht schwierig zu rekapitulieren im Nachhinein. Aber fällt euch da was ein? Also ich hatte jetzt gar nicht unbedingt was zum Thema, dass wir da wirklich Entscheidungen getroffen haben, sondern eher was wo, wo wir wirklich intensiv über was nachgedacht hätten, was uns sonst wahrscheinlich später auf die Füße gefallen wäre. Und das ist so beim Thema Datenbank. Also halt die Mandanten Trennung, wie machen wir das? Und dann eben eben auch, resultierende Fragen, die sich daraus ergeben. Also Situationen, die wir ja aus unserem anderen Produkten Kunde XY sagt. Wir haben ja totalen Mist gebraucht, wir müssen noch mal den Stand von gestern 12:00 wieder einspielen. Und wenn man den Kunden in der eigenen Datenbank hat und dann einen entsprechenden, Backup von ungefähr der Zeit einspielen kann, dann geht das. Wenn man alle Kunden in einer Datenbank hat und auf anderem Wege getrennt. Dann geht das nicht ganz so einfach. Und da haben wir halt doch schon recht umfangreich dokumentiert, was können wir da machen, was haben wir für Optionen? Es ist jetzt nicht so, dass wir praktisch eine fertige Lösung haben, sondern wir haben hier etwas, das und das können wir machen und auch wie können wir umgehen, wenn wir irgendwie Migrationen haben usw. und so fort. Und was sind dabei für Aktionen, die wir machen, welche, die potenziell problematisch sind? Und ich bin mir ziemlich sicher, ohne das Architekturdokument hätten wir uns darüber gar keine Gedanken gemacht. Groß. Und wenn dann die Situation gewesen wäre, hätten wir erstmal dagestanden gedacht Oh Gott, oh Gott, oh Gott, oh Gott, das können wir gar nicht. Und hätten dann in kürzester Zeit irgendwas uns aus den Fingern saugen müssen. Und so können wir dann zumindest später nachgucken, sagen Was haben wir uns denn dafür Gedanken gemacht? Okay, machen wir. Wir hätten es wahrscheinlich sogar so gemacht wie vorher am alten Produkt, wo wir halt für im Bestandsprodukt, wo wir für jede, für jeden Kunden die eigene Datenbank haben. Und hier haben wir dann halt gemerkt, okay, das ist einfach nicht der ideale Weg für eine schöne SaSS Anwendung, weil das heißt dann, wenn ich 1000 Kunden habe, dann muss ich 1000 Datenbanken aufsetzen und das ist einfach was, was nicht gut skaliert. In keinster Weise mit der Anzahl der offenen Datenbank, Connections mit dem, was einem Rechenzentrum sbetreiber überhaupt an Lösungen anbieten. Und insofern war das genau einer der Punkte, wo man sich ein paar Vorteile durch ein paar Nachteile erkauft hat. Aber wohl überlegt an der Stelle. Sascha bei dem Thema Entscheidungen getroffen, an die man sonst nicht gedacht hätte. Nein, das ist mir nicht bewusst. Klar, Logging ist interessant gewesen und auch wichtig. Oder Barrierefreiheit. Aber das sind Sachen, an die hätten wir auch so gedacht, dass es Bestandteile werden vielleicht nicht so im Detail drüber nachgedacht, aber wir hätten sie nicht vergessen. Werden es genau werden gemacht. Wahrscheinlich werden die ersten Storys, die ersten User Storys in die Umsetzung gegangen wären. Na. Genau so hatte das schon was, wo er im Nachgang nochmal reingeguckt hat. Mehrfach. Zum einen, was das Thema Datenmodell angeht, da hatten wir uns da ja auch schon einige Gedanken darüber gemacht. Zuerst mal grundsätzlich wie ist das aufgebaut? Und als wir angefangen haben, das zu modellieren in der Datenbank, habe ich mehrfach reingeguckt. Dann gab es auch so ein paar Sachen, gerade am Anfang, als wir angefangen haben zu entwickeln, wo dann ich mir Merge-Request angeguckt und dachte Moment, das hatten wir doch aber eigentlich mal anders geplant, wo ich dann noch mal reingeguckt habe, bevor ich geschrieben habe, wir wollten doch eigentlich. Weiß noch, was es für Themen waren. Ja, also ich weiß, dass beim Logging irgendwie was war. Dann hatten wir halt auch, ganz, ganz am Anfang, so bei dem ersten REST-Request, wo es dann darum ging, was anzulegen. Das ist dann doch wieder ein ziemlich klassischer Request war und wir ja eigentlich gesagt hat, dass wir mit Commands da arbeiten wollen und das sind halt die Sagen. Also ich fand es schon ganz lustig, dass wir mit der Architektur Dokumentation durch waren, dann angefangen haben zu entwickeln und sie an ein paar Stellen einfach offenbar sofort wieder vergessen haben und alles so gemacht haben, wie wir es sonst auch gemacht haben. Wie wir es immer gemacht haben. Aber da war es dann halt durchaus trotzdem ganz gut, eben mal reingucken zu können und zu sagen Ja, haben wir doch. Aber anders uns mal überlegt, was ja nicht heißt, dass man es dann so machen muss. Man kann dann ja auch nicht, Das kann ja einfach auch genauso was sein. Erster Kontakt mit der Praxis Und wir stellen fest, er klang gut, als wir darüber nachgedacht haben. Funktioniert aber nicht. Wäre ja auch legitim. War in dem Fall nicht so. Also von daher. Ich habe durchaus schon ein paar Mal reingeguckt. Und Sascha, sei ehrlich. Also per Definition war für mich ein Thema, wo ich reingeschaut habe. Guter Punkt. Ja. Dass wir mit Mittätern und genau das ist einfach so ein Format, was nicht so intuitiv reinkommt. Ja, und wo wir uns wohl einfach mal gefragt hatten, wie machen andere das heutzutage? Wie ist das Restnarrativ? Nenne ich es mal die per Definition? Ja genau. Guter Punkt. So, ja. Und dann noch abschließend die Frage Was glaubt ihr, was für eine Halbwertzeit wird das Dokument haben? Wie lange wird es relevant sein? Ja, gute Frage. Ich glaube, die kann man auch gar nicht so eindeutig beantworten. Das eine ist ja das Thema Ding. Das sagte Sascha ja vorhin auch schon. Wenn ein neuer Mitarbeiter kommt, dann hat da was, wo er erst mal reingucken kann. Ich denke, dass das noch lange möglich sein wird, dass man dieses Dokument sich durchlesen kann, um einen Überblick zu kriegen, auch wenn man dann bestimmt Sachen findet, wo man dann wenn dann in den Code reingucken sagt, Das ist aber nicht so wie da beschrieben was angeht, was die Frage angeht, wie oft wir noch Änderungen machen werden. Ich denke, das hängt ein bisschen davon ab, wie lange wir das Gefühl haben, es bringt irgendwas. Also für mich ist es am ehesten das Thema Architektur Entscheidungen, wo ich mir vorstellen könnte, dass wir immer mal wieder was anpassen und erweitern, Gerade wenn wir halt größere Entscheidungen treffen, wo wir sagen, wie machen wir denn jetzt das, dann kann sich das noch lohnen. Kann das noch sinnvoll sein, das da hinzuzufügen? Aber. Ich kann vielleicht rückblickend noch mal antworten fürs Core Produkt. Da hatten wir. Wann war das? Anderthalb Jahre ist es bestimmt her. Ja, haben auch September das Jahr davor gewesen sein. Da hatten wir uns Gedanken gemacht, wie wir eine neue Search Engine Alternative einbauen können zu dem, was wir bisher quasi in der Bestandsdatenbank integriert hatten. Und da hatten wir auch so eine Architekturanalyse gemacht, und da haben wir das letzte Mal, gerade im letzten November, also, ein Jahr 14 Monate nach Erstellung des Dokuments, wieder ein Meeting, wo wir wieder in dem Dokument drin herumgewühlt haben und wo die Information, da ist vor allem die Laufzeitsicht gewesen. Wie finden bestimmte Prozesse statt, wie soll die Indizierung ausgelöst werden usw.. Da hat man uns damals viel Gedanken gemacht, wie die verschiedenen Services da zusammenspielen und da war das immer noch hilfreich und Grundlage für unsere Diskussion und die Weiterentwicklung. Auch wenn das Dokument natürlich, nachdem die Entwicklung erst mal begonnen hat und und ich war jetzt, wie du sagtest, Benjamin nicht mehr kontinuierlich weiterentwickelt wurde. Koljah Na, da sind wir bei der Architektur Dokumentation durch. Und dann hatte ich mir überlegt, wir haben ja hier einen neuen Podcast und ein neuer Podcast braucht natürlich eine Kategorie, die jedes Mal mit drin ist, eine Sektion. Und da haben wir jetzt die Erkenntnis der Woche Was ist eure Erkenntnis der Woche dürfen auch die letzten zwei Wochen sein, also irgendwas, was mit der Entwicklung des aktuellen Produktes zu tun hat. Irgendwas, was er tolles Neues festgestellt habt, erfahren habt, Erfolgserlebnisse, whatever. Was ist eure Erkenntnis der Woche? Ich kann dazu ganz gut was bringen, was ich in der letzten Retrospektive auch gebracht hat. Property-basiertes Testing ist schon eine ziemlich gute Sache. Wort ist. Na du machst halt im Endeffekt so was das für eine Funktion aufrufst und rufst sie mit ganz, ganz vielen verschiedenen Eingabewerten auf, die im Zweifelsfall auch zufällig generiert werden. Und auch mit Kotest, was wir da als Testing Library einsetzen, hat man da schöne Mittel, um dann auch Objekte zu erzeugen, wo man dann halt, sagt weiß nicht, ich habe ein User mit Daten, Benutzername, Vorname, Nachname, das befülle ich einfach mit irgendwelchen zufälligen Werten. Dann kann man halt auch Cases da erzeugen, um dann halt genau Problemfälle nachzustellen. Und dann kannst du einen Test, der so ein Objekt in die Datenbank schreibt, einfach mal ausführen, ohne großen Aufwand mit 50 verschiedenen Nutzern, die irgendwie zufällig generiert werden, wo dann auch echte Cases drin sind. Und das bringt einen ziemlich schnell zu einer sehr hohen Testabdeckung, die man auch anders gar nicht erreichen würde. Oft ist es halt so, dann ruft man so eine Funktion auf mit genau einem Objekt. Und jetzt im dümmsten Fall ist es dann so, dass – weiß ich nicht – Die Datenbank so eingestellt ist, dass sie mit Umlauten nicht umgehen kann. Und bei dem Objekt, das man zum Testen verwendet, ist nun natürlich genau kein Umlaut drin. Dann klappt es, bis der erste User versucht sich anzumelden und es nicht geht, weil ein Umlaut in seinem Namen ist. Also das ist da einfach schon eine sehr, sehr schöne Sache. Wurde das früher nicht als Monkey-Testing oder so was bezeichnet, wo einfach zufällig irgendwelche Werte generiert und ins System reingeschoben werden? Aber das heißt, an der Stelle ist es so, dass das Framework, also Kotest unterstütze dich dabei halt viele Objekte mit verschiedenen Properties zu erzeugen und dann da reinzureichen. Zu deiner Kenntnis der war. Betrifft eigentlich auch das Testing. Wir machen ja gerade im Grunde unsere ersten Schritte seit ein paar Wochen mit react-testing. Klar, vorher viel mit enzyme getestet und einfach entschieden, jetzt auf diesen neuen Zug aufzusteigen, das einfach Sinn macht. Und ja, es ist ja so ein Integration Test basierter Ansatz, aber trotzdem ist es manchmal gut, dann doch eine Dependency wegzumachen, weil dann der Test einfach nur so langsam wird. Je mehr man davon natürlich hat. Und manchmal ist es auch nicht notwendig, dass alles da drin gerendert wird. Und das sind so Learnings, die wir gerade noch recht häufig haben. Den Scope dann von so einem Integrationtest richtig richtig zu setzen. Gut. Danke. Na denn. Sind wir schon am Ende. Und ja, zum Ende kann ich noch sagen Wir freuen uns über dein Feedback sowohl zu unseren technischen Erlebnissen und Entscheidungen, als auch zu unserem Podcast selber. Feedback geben kannst du über unsere Website unter buildingaproduct.orgavision.com geben, auf LinkedIn oder auf Twitter. Die Links dazu findest du auf der Webseite. Bis zum nächsten Mal. Schau.