Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
So, dann herzlich willkommen zu einer weiteren Episode von Software-Architektur im Stream.
Heute soll es weitergehen zu dem Thema mit dem Bauen einer Architektur.
Ich hatte da ja letztes Mal ein Beispiel angefangen.
Und bevor wir damit tatsächlich loslegen, verschiedene Sachen.
Also die eine Sache ist, vielen Dank für das Feedback, auch in den YouTube-Kommentaren und auch ansonsten zu der Folge.
Das hat mich halt erstmal sehr gefreut.
Wie geht es hier weiter?
Also die eine Sache, heute werden wir darüber reden, wie wir diese Lösung strukturieren können, wollen.
Moment mal.
Heute wollen wir darüber reden, wie wir diese Lösung strukturieren können.
Das heißt, wir bauen das, was man wahrscheinlich am ehesten als traditionelle Software-Architektur sehen würde.
Sprich, wir strukturieren tatsächlich das System.
Das ist das, was wir heute vorhaben.
Dann haben wir am 18. eine weitere Episode zu Software-Architektur als Beruf.
Die wird am 18. live gehen.
Ich kann leider am 18. nicht dabei sein.
Da bin ich, bin halt freitags um 12. verhindert.
Und eine Sache, die sich ja herauskristallisiert hat, ist, dass eine wesentliche Anforderung in diesem System das Thema Benutzerfreundlichkeit ist.
Das haben wir beim letzten Mal ermittelt.
Und da ist irgendwie die Frage, wie wollen wir das eigentlich umsetzen?
Beim letzten Mal gab es halt den Vorschlag, dass man allgemein bei so einem Architekturvorgehen sich ja vielleicht einen Consultant von der INNOQ holen könnte.
Und tatsächlich werden wir das tun.
Das heißt, wir werden am 25. meine Kollegin, die Aminata, hier haben.
Und wir werden mit ihr über das Thema, wie setzen wir denn eigentlich Benutzerfreundlichkeit um?
Wir haben da mal ein paar Qualitätsszenarien.
Was machen wir mit diesen Qualitätsszenarien?
Sind die überhaupt sinnvoll?
Und da an dieser Stelle weitersprechen.
Das ist halt für mich persönlich wichtig.
Weil ich glaube, dass Benutzerfreundlichkeit einer der Aspekte ist, die häufig eben gerade nicht vernünftig umgesetzt werden, aber für den Erfolg einer Software eigentlich ganz zentral sind.
Das ist also das, was da passiert.
Ich muss nochmal eine Sache kurz nachschauen.
Es gab halt einen Kommentar, auf den ich nochmal eingehen wollte bei YouTube.
Den fand ich halt besonders spannend.
Den muss ich aber nochmal raussuchen.
Genau, der müsste hier sein.
Achso, da steht, genau, ein Kommentar war, Benutzerfreundlichkeit hängt meines Erachtens oft stark von Detailfestigung im Rahmen des UI-Designs ab.
Ich finde, durch Architekturmaßnahmen hat man da recht wenig Einfluss drauf.
Wäre interessant zu hören, welche Konsequenzen das für die Architektur hat.
Genau darüber werden wir sprechen.
Und im Übrigen, das ist auch ein Teil eigentlich der Nachricht, die ich halt überbringen möchte.
Wenn ich als Software-Architekt mich um die, den Erfolg des Projekts kümmere, dann kann ich das nicht nur mit der Strukturierung des Systems tun, sondern ich muss eben andere Maßnahmen ergreifen.
Und genau das werden wir in dieser Benutzerfreundlichkeitsfolge dann diskutieren.
Und ich wäre überrascht, wenn da irgendwie rauskommt, wir sollen das System in einer bestimmten Art und Weise strukturieren.
Dann kam halt die Aussage von dem Jonas Stegmaier, Performance beeinflusst die Benutzerfreundlichkeit einer Software sehr stark.
Mit Beispielen das stimmt, nicht?
Also das ist tatsächlich richtig, wenn ich halt eine Software benutze, die halt sehr, sehr langsam ist, dann würde ich der auf keinen Fall in der Benutzung eine, eine gute Note geben.
Aber Benutzerfreundlichkeit ist tatsächlich ein getrenntes Qualitätsziel von Performance.
Also Performance habe ich als Qualitätsziel und das ist eben getrennt von Benutzerfreundlichkeit.
Ich kann ein System bauen, was halt benutzerunfreundlich ist, aber sehr schnell.
Also das ist, glaube ich, klar.
Und das Umgekehrte geht irgendwie auch.
Naja, das geht vielleicht irgendwie nicht so gut aus den schon skizzierten Gründen.
Aber das sind irgendwie zwei getrennte Sachen.
Und ich muss gestehen meine Annahme ist, dass man irgendwie sagt, naja, wir wollen eigentlich Benutzerfreundlichkeit erreichen.
Und jetzt ersetzen wir dieses Ziel durch Performance.
Weil Performance können wir ja mit klassischen Architekturmaßnahmen irgendwie umsetzen.
Und das finde ich, ehrlich gesagt, schwierig und ist genau das, wovor ich so, so ein bisschen warnen wollte.
Und wenn wir uns nochmal angucken, ich schau mir hier kurz um, auf die Qualitätsszenarien vom letzten Mal zumindest so exemplarisch.
Dann ist da sowas wie ein Kunde bewertet das System vergibt im Schnitt vier von fünf Punkten.
Oder sowas wie die Einarbeitung, dass die halt irgendwie nur eine Stunde dauert.
Und das ist nun wirklich etwas, wo ich mir nicht vorstellen kann, dass man das durch Performance löst.
Und wenn ich jetzt diese Ziele priorisieren sollte, das hier ist vermutlich ein ziemlich wichtiges Ziel.
Weil dadurch kann ich irgendwie sagen, die Kunden finden die Anwendung einfach super.
Wir reden in dem konkreten Beispiel ja über so ein Fahrradreparatursystem.
Die reparieren, lassen gerne bei uns Fahrräder reparieren.
Das bringt uns irgendwie Umsatz und Geld.
Das ist also eine super Sache, weil sie das System super finden.
Und das ist eben nur mittelbar durch Performance beeinflusst, würde ich jetzt mal behaupten.
So, und dann kam noch ein weiteres Feedback.
Auch von dem Jonas Stegmaier bei bei YouTube.
Und der hat geschrieben, durch wen sollten nicht-funktionale Anforderungen definiert werden?
Wenn der Kunde keine messbaren Anforderungen angibt.
Also, meine Antwort darauf wäre: irgendwie der Kunde.
So, und dann sagt Jonas halt weiter, naja, wenn der Kunde keine messbaren Anforderungen angibt, macht es Sinn, selbst messbare Anforderungen zu definieren.
Also, ich würde behaupten, und das müssen wir gleich nochmal detaillieren, und ich fand die Frage halt deswegen gut, weil ich das tatsächlich beim letzten Mal hätte diskutieren müssen, aber es nicht getan habe.
Aus meiner Sicht ist das eine Kollaboration.
Ich kann von einem Kunden nicht erwarten, dass er oder sie sich jetzt irgendwie hinstellt und auf so eine Idee hier kommt, wie ich sie jetzt skizziere.
Ein Kunde bewertet das System, er vergibt im Schnitt 4 von 5 Punkten oder sowas wie hier, nicht?
Ein frisch registrierter Kunde will eine Reparatur beauftragen, 90% der BenutzerInnen schaffen das, können das innerhalb von 2 Minuten tun.
Da ist Wissen drin, was wir haben, nicht?
Als Software-ArchitektInnen.
Nämlich, wie kriegen wir es halt hin ein vernünftiges Qualitätsszenario aufzuschreiben?
Und das fachliche Wissen, worauf es denn nun ankommt, das kommt vom Kunden.
Das bedeutet, es ist eine Kollaboration.
Nicht?
Also, ich würde jetzt nicht erwarten…
Also, ich kann nicht erwarten, dass mein Auftraggeber mir sagt, hier sind die Qualitätsszenarien, implementiere mal.
Sondern ich kann erwarten, dass mir diese Person im Gespräch zur Verfügung steht und dass wir irgendwie das aufschreiben können.
Und dann gemeinsam irgendwie sagen, ja, das hört sich für mich irgendwie realistisch an.
So, und dann kommt er halt weiter.
Kunde sagt, das System muss immer perfekt funktionieren.
Das ist ein guter Punkt.
Und das ist genau das, was ich hab beim letzten Mal irgendwie vergessen hab zu erzählen.
Was ein bisschen implizit in diesen Qualitätsszenarien drin ist.
Also, man stelle sich jetzt mal vor, wir haben eine Diskussion.
Und wir…
Also, ich stelle mir jetzt mal vor, ich bin sozusagen in der Kundenrolle.
Und der zuständige Software-Architekt, die zuständige Software-Architektin kommt zu mir und sagt, wie zuverlässig soll denn das System sein?
Also, ich glaube, das Erste, was ich mich fragen würde, ist, warum zum Teufel werde ich das gerade gefragt?
Das soll halt ein zuverlässiges System sein.
Die wissen ja möglicherweise noch nicht mal, wie man irgendwie Software entwickelt.
Und sagen werde ich, das soll halt im hohen Maße zuverlässig sein.
Also, logisch.
So, und was ist hier die andere Sache?
Also, keine schlechte User Experience.
Genau, es soll also auch sehr benutzerfreundlich sein.
Logisch.
Und Jonas steigt dann weiter ein auf dieses Thema mit Verfügbarkeit.
Für mich ist da Kommunikation ganz wichtig.
Und die Art und Weise, wie ich irgendwie frage.
Eine Frage, die ich zum Beispiel wichtig finde, ist, was passiert, wenn das System ausfällt?
Was passiert, wenn das System eine Minute ausfällt?
Was passiert, wenn das System fünf Minuten ausfällt?
Was passiert, wenn das System eine Stunde ausfällt?
Und ich habe aus dieser Diskussion tatsächlich in einem realen Szenario, das allerdings schon länger her, dann die Aussage bekommen, also, wir können einen Tag ohne dieses System auskommen, weil wir dann irgendwie das auf Zetteln erstmal festhalten und das halt später nachpflegen können.
Okay, gut.
Und was der Jonas dann im Weiteren sagt, ist, während der Arbeitszeit, wie sich später herausstellte, das heißt also, die nächste Frage, die man zum Beispiel stellen könnte, ist, was passiert, wenn das System nachts um zwei ausfällt?
So.
So, da können halt irgendwelche Ergebnisse rauskommen, nicht?
Also, eine Möglichkeit wäre, dass man sagt, naja, nachts um zwei sind halt bei uns die Lagermitarbeiter gerade am Wirbeln und sorgen halt dafür, dass die Frühlieferungen rauskommen.
Wenn das System dann ausfällt, ist es irgendwie super schlecht.
Oder es kommt irgendwie raus, naja, also der erste Mitarbeiter, die erste Mitarbeiterin kommt morgens um sieben in die Firma und dann schalten die halt den Rechner ein.
Wenn es nachts um zwei ausfällt, merkt es niemand.
Und das ist, glaube ich, die Art und Weise, wie man da irgendwie sozusagen hinkommen muss, nicht?
Also, Fragen, die ich halt stellen würde, wäre, was passiert, wenn das System ausfällt?
Ich würde versuchen, das zu fragen nach Feiertagen, Wochenenden, nachts, tagsüber und so weiter.
Und eben insbesondere die Frage, was passiert dann?
Nicht die Frage, ist es okay, ob das System ausfällt, sondern was passiert dann?
Und dann kann man es ja daraus sozusagen ableiten, nicht?
Das System fällt irgendwie eine Minute aus, Menschen sterben, wow.
Das System fällt einen Tag aus.
Wir haben eigentlich nicht ernsthaft ein Problem.
So, und das ist das, was so ein bisschen, also nicht, was hier so ein bisschen rauskommt.
Also hier ist eben implizit die Annahme, dass wir eine Diskussion geführt haben, nicht?
Also hier steht ein Mitarbeiter im Shop, will das System zwischen neun und 18 Uhr nutzen.
Es steht zu 99 Prozent zur Verfügung.
Das heißt, die implizite Annahme ist, vor neun Uhr arbeitet nicht jemand ernsthaft mit dem System.
Nach 18 Uhr irgendwie auch nicht.
Und selbst dann ist es halt okay, wenn das halt so medium toll verfügbar ist.
Weil, also wir reden über ein System, wo ich halt Reparaturen mit einem, für ein Fahrrad einschedule.
Das heißt, wenn der Rechner gerade nicht funktioniert, schreibe ich es halt erstmal auf und ich pflege es später nach.
Und es ist jetzt irgendwie unwahrscheinlich, so kann ich mir das erklären, dass ich da ein großes Problem habe.
Und hier ist noch die andere Geschichte.
99 Prozent Verfügbarkeit sagt mir ja nur.
Also das kann man ausrechnen, wenn ich halt 365 Tage habe.
Hier ist es weniger.
Also weil wir jetzt von neun bis 18 Uhr rechnen, dann darf das System bei 365 Tagen irgendwie so dreieinhalb Tage ausfallen.
Und es ist unwahrscheinlich, dass es gut ist, wenn das System halt dreieinhalb Tage im Jahr ausfällt und dann die restlichen 362 Tage halt funktioniert.
Deswegen habe ich hier irgendwie das andere hingeschrieben, nicht?
Das heißt also, der Dialog, der jetzt irgendwie passiert.
Also das andere, was hier steht, ist das System im Shop fällt aus.
Es steht spätestens nach 30 Minuten wieder zur Verfügung.
Das heißt, die Annahme ist, dass man nur 30 Minuten mit Zettel und Bleistift überbrücken kann.
Wo man jetzt noch irgendwie drüber diskutieren könnte, nicht?
Ernsthaft?
Wirklich?
Ist das tatsächlich so?
Und dann könnte man halt eine Diskussion führen und könnte halt sagen, naja, okay, also wenn eine Reparatur angenommen wird, dann kann ich das vielleicht länger.
Aber wenn ich das jetzt irgendwie abhole, muss ich ja dem Menschen das Geld abknöpfen.
Dafür brauche ich halt diese Information.
A, okay.
Das heißt, ich könnte jetzt das nochmal weiter detaillieren und könnte halt sagen, okay, die Information, wie viel diese Reparatur tatsächlich gekostet hat, wenn das Fahrrad abgeholt wird, das ist sogar noch wichtiger.
Das muss halt, da darf es halt höchstens zwei Minuten ausfallen oder so.
Können wir jetzt auch aufschreiben, nicht?
Spätestens nach zwei Minuten kann man den Preis abholen.
Dann kann man den Preis einer erfolgten Reparatur wieder ermitteln.
So, und jetzt habe ich wieder was fachlich über dieses System gelernt, nicht?
Also Annahme von Reparaturen nicht so kritisch wie irgendwie dieses Ermitteln von dem Preis.
Und eine profane Möglichkeit, das zu lösen, ist, dass ich halt an der Stelle, wo die Reparatur fertig ist, irgendwie so ein Ding ausdrucke.
Das halt ans Fahrrad klebe und da steht irgendwie dran, diese Reparatur hat übrigens 10 Euro gekostet.
Dann habe ich das halt in gewisser Weise erledigt.
Oder ich habe irgendwo eine Tabelle, die fest abgelegt ist, wo das irgendwie drauf drin steht oder weiß der Teufel was.
Da kann man sich halt was ausdenken, nicht?
Also das kriege ich halt irgendwie hin.
So, und genau.
Und deine Anforderungen anfangen schon korrekt.
Das schreibt der Jonas Stegmaier noch.
Das ist etwas, was wir nicht betrachtet haben.
Glaube ich, das ist irgendwie so was, dass das System eben tatsächlich zuverlässige Informationen liefert.
Da könnte man jetzt also auch noch mal reinpiksen.
Das heißt also, die Antwort auf die Frage, wer schreibt das?
Wer erstellt diese Szenarien?
Ich führe irgendwie einen Domänenexperte, eine Domänenexpertin, aber nicht im Alleingang, sondern das müssen wir irgendwie gemeinsam tun.
Und das ist meiner Ansicht nach genau der Vorteil von diesen Qualitätsszenarien.
Das heißt, meine Hoffnung, also diese Qualitätsszenarien machen nur dann Sinn, wenn irgendwie ein Auftraggeber sagt, ja, wenn das so ist, dann bin ich glücklich.
So, und das ist ja gerade die Funktion.
Und das bedeutet, wenn ich sie irgendwie im Alleingang aufschreibe, macht das eben keinen Sinn.
Deswegen also dort kollaborativ.
Und wie gesagt, ich glaube, geschickte Fragetechniken sind wichtig.
Wenn man sich irgendwie hinstellt und sagt, soll unser System konsistent und verfügbar sein, ist die absolut zu erwartende Antwort, ja, natürlich, es soll konsistent und verfügbar sein.
Ach so, genau, Konsistenz ist das andere.
Da.
Tatsächlich eine Diskussion, die ich diese Woche hatte, die kann man auch, egal, können wir nachher vielleicht irgendwie auch nochmal führen.
In dem konkreten Fall war es so, dass wir gesprochen haben über eine Datenbasis für Machine Learning.
Ich habe also Bewegungsdaten, die dann irgendwie, also Daten von irgendwelchen Dingen, die da passieren, irgendwelche Buchungen und dann gibt es halt Machine Learning.
Und dann gibt es halt Machine Learning System, was halt basierend auf diesen Daten irgendwelche Sachen ausgeben soll.
So, und jetzt ist halt die Frage, also die Frage, die ich nicht stellen würde, ist, sollen die Daten konsistent sein?
Natürlich sollen die Daten konsistent sein.
Die Frage, die ich, glaube ich, sehr wohl stellen kann, ist, wenn ich jetzt hier eine neue Buchung habe, wie lange darf es dauern, bis sie halt in dem Machine Learning System auftaucht?
Und diese Frage kann ich auch stellen, zum Beispiel bei Reports.
Ich habe also jetzt irgendwie in einem Shop etwas gekauft.
Wie lange darf es dauern, bis diese Sache aus dem Shop in einem Report irgendwo auftaucht?
So, und da kann irgendwie die Antwort sein, üblicherweise kommt der Chef morgens in die Firma, guckt sich die Reports an und signiert dann über den letzten Tag und was er irgendwie tut.
Dann reicht es also offensichtlich aus, dass das am nächsten Morgen irgendwie da ist.
Oder die Aussage ist, wir gucken halt sehr detailliert da drauf und versuchen halt online.
In diesem Internet sehr schnell, innerhalb von Stunden oder so, neue Aktionen zu fahren, wenn wir halt sehen, dass irgendwelche Peaks da sind oder irgendwelche Dinge halt da sind.
Das heißt, die Information muss halt innerhalb von fünf Minuten oder sowas da sein.
So, und das ist die Information, die relevant ist.
Die Frage, die da, glaube ich, zentral ist, ist, wie lange darf es dauern, bis diese Information von hier nach da kommt?
Und auch dort, also genau, ich habe mir mal eine Diskussion geführt.
Ich habe mal eine Diskussion geleistet oder nur eine, ja, es waren eigentlich eher Zwischenfragen, die mich überrascht haben, wo irgendwie als Aussage kam, ja, also die Lieferung und die Rechnung, wenn die Bestellung abgeschickt wird, muss das halt instantan da sein.
Ich habe Schwierigkeiten, mir das vorzustellen.
Also meine Erlebniswelt, wenn ich bei einem E-Commerce-System irgendwas bestelle, ist, dass die Rechnung irgendwann kommt, möglicherweise sogar erst, nachdem die Lieferung losgeschickt worden ist, per E-Mail.
Und sicherlich nicht.
Direkt in dem Moment, wenn die Bestellung abgeschickt worden ist.
Und analog würde ich vermuten, dass es einige Zeit, dass es okay ist, wenn es halt zehn Minuten dauert, bis irgendwie im Lager gesagt wird, übrigens, da ist diese neue Bestellung, liefer die mal aus.
So, aber das und, also nicht, mich würde das überraschen, was aber eben bedeutet, wenn die Aussage, wenn diese Aussage tatsächlich stimmen sollte, dass also diese Informationen instantan da sein sollen.
Dann habe ich halt was über die Domäne.
Weil für mich ist es halt als Laie schwer vorstellbar, dass man halt sagt, wenn ich hier etwas bestelle auf der Webseite, muss das halt innerhalb von, weiß ich nicht, zehn Sekunden im Lager sein.
Kann ich mir nicht vorstellen, aber wer weiß.
Also vielleicht lerne ich da was über die Domäne an der Stelle noch.
Und das ist genau das, was ich mit den Qualitätsszenarien hinbekomme.
So, das dazu.
So, jetzt habe ich vom, genau, jetzt habe ich also vom letzten Mal sozusagen die Sachen nochmal kurz wiederholt.
Und was wir, was ich, achso, und ich gucke nochmal kurz in den Chat, den hatte ich jetzt nämlich gerade nicht offen.
Achso, da steht, wie war das noch in einer frühen Folge, wo man Filme nicht ausleihen konnte, wenn das Guthaben nicht reicht.
Und es meinte, 50 Cent drüber wäre noch in Ordnung.
Immer die Fachlichkeit fragen.
Genau, das, sowas, ich weiß gar nicht, ob das eine Folge war, aber das kommt mir irgendwie auch bekannt vor.
Also das sind genau diese Sachen.
Ich würde halt diese Fachlichkeit nachfragen und versuchen, die halt zu verstehen.
Und ich glaube eben diese, also das ist vielleicht auch so ein Klassiker, nicht?
Also in agiler Softwareentwicklung sind Storys nicht unbedingt Anforderungen, sondern eigentlich Versprechen für Kommunikation.
So ein bisschen ist das halt bei den Qualitätsszenarien ähnlich, nicht?
Ich muss es halt irgendwie versuchen zu verstehen.
Gut.
Genau.
Mal kurz schauen, ob hier noch irgendwas ist.
Nein.
So, heute wollen wir uns jetzt irgendwie darum kümmern, wie wir unser System fachlich strukturieren.
Und nein, wie wir unser System strukturieren.
Und ich will das System fachlich strukturieren.
Und darüber haben wir, glaube ich, ausreichend gesprochen an verschiedenen, also es gibt verschiedene Episoden davon.
Von dem, dem Stream, die halt darüber diskutieren.
Und es gibt verschiedene Ansätze, die wir, die man dort nutzen kann, prinzipiell, nicht?
Also wir haben sowas wie Event Storming, wir haben sowas wie Domain Storytelling.
Das sind alles Ansätze, über die wir über die wir halt reden könnten.
Und die uns irgendwie dazu bringen könnten, dort irgendwie uns nochmal eine komplexe fachliche Logik zu erschließen.
Ich will hier, also mein Ziel ist ja jetzt nicht unbedingt, die perfekte Architektur zu bauen, sondern ich will konzeptionell da durchführen.
Und deswegen mache ich jetzt mal sozusagen einen leichtgewichtigen Ansatz.
Und zwar überlege ich mir so ein bisschen ich will ein fachliches Modul haben.
Und ich versuche das an der, anhand dieser, dieser Stories, die wir hier haben zu strukturieren.
Das heißt, meine Idee ist.
Ich möchte mein System so aufteilen, dass ich Fachlichkeiten jeweils in einem Modul implementiert habe.
Das heißt also, ich strukturiere die Fachlichkeit und damit gehe ich jetzt erstmal nicht davon ab, also mache ich bewusst keine technische Aufteilung.
Das heißt also, was ich ja jetzt theoretisch machen könnte, wäre, ich könnte mich jetzt irgendwie hinstellen und könnte sagen, wir haben eine technische Aufteilung, wir haben eine UI, wir haben eine Logik und wir haben.
Eine Persistenzschicht, das finde ich auf dieser grob-granularen Ebene nicht hilfreich.
Unser System soll eine bestimmte fachliche Funktionalität erbringen.
Wir müssen die, im Prinzip ist das eine Konsequenz aus dem, was wir letztes Mal diskutiert haben.
Wir haben halt diese Anforderungen.
Wir müssen halt diese Anforderungen, in diesem Fall sind es ja fachliche Anforderungen, nicht Qualitätsszenarien, die müssen wir halt irgendwie umsetzen.
Wir müssen darauf eine Antwort geben und darauf können wir nur eine Antwort geben, wenn wir das Zeug da irgendwie fachlich strukturieren.
Das heißt also, ich versuche mir zu überlegen.
Kann ich anhand dieser Fachlichkeit irgendwie dieses System strukturieren und ich habe hier erst mal sowas wie, dass ich ein Fahrrad zur Reparatur anmelden will.
Die Story nehme ich mir jetzt hier mal raus.
Moment, ich muss mal kurz schauen.
Genau, da habe ich tatsächlich eine Kopie gemacht und.
Wenn ich das tue, so ist die Annahme, möchte ich eigentlich nur sagen sowas wie ich möchte gerne am elften dritten oder sagen wir mal, ist es länger Zeit hin, also am achtzehnten dritten eine Reparatur haben und mein Name ist Eberhard und irgendwie soll ein Fahrrad repariert werden.
So, das wäre das, was ich hier hätte und daraus, wenn ich das halt irgendwie haben möchte.
Dann muss ich irgendwie dort auch, muss mal kurz schauen, den Reparaturtermin beispielsweise berechnen, nicht das heißt also, ich sage jetzt, ich will ein Fahrrad abgeben zur Reparatur und dann würde ich eben ein Reparaturtermin berechnen und was haben wir noch, dann kann ich halt irgendwann dieses, genau, das ist sozusagen so ein bisschen Funktionalitäten, die so aus Kundenperspektive sind.
Ich habe mir halt überlegt, dass ich.
Ich versuche hier zu sagen, diese Sachen, die halt irgendwie oben sind, das sind so die Dinge, die halt sozusagen aus Kundenperspektive da passieren und jetzt kommt auf der anderen Seite ist es jetzt so, dass wir, ja, was haben wir hier eigentlich?
Ich würde behaupten, wir haben hier sowas wie eine Terminplanung, das heißt, es geht darum zu sagen, wann ich diese Fahrräder halt eigentlich repariere.
Und da habe ich letztendlich einen großen Kalender und diesen Teil des Systems könnte ich vielleicht sogar für meine Arbeit auch benutzen, also ich mache ja bestimmte Dinge, ich bereite diesen Stream vor, ich berate irgendwelche Leute und ich könnte jetzt irgendwie sagen, okay, ich habe ja diese Themen, wann fange ich an, daran zu arbeiten und wann komme ich voraussichtlich dazu, irgendein Thema zu bearbeiten.
Das heißt also, dass wir hier Fahrräder haben, ist vielleicht gar nicht so wichtig, es geht nur darum, Arbeit zu strukturieren.
Und was wäre so aus Sicht des Fahrradmechanikers halt dort irgendwie relevant ist?
Genau, den hatte ich jetzt hier sozusagen unten geplant, der würde jetzt tatsächlich sagen, okay, ich bekomme hier so einen Reparaturplan, den ich mit diesem System erstelle, das heißt, ich sehe halt, okay, eingeplant für den am 18. ist das Fahrrad von dem Eberhard und noch diverse andere Fahrräder.
Und das wäre jetzt dieser tägliche Reparaturplan, den der sich halt überlegt und er würde dann halt irgendwie auch sagen, okay, ich möchte die nächste Reparatur beginnen, also eben irgendwelche Themen, die wir hier eingeplant sind, auch tatsächlich umsetzen und ich möchte, was möchte ich denn noch das war es eigentlich.
Genau, so.
Dann haben wir hier so etwas, wo ich halt sage, ich möchte den Fahrraddefekt aufnehmen.
So, das heißt also, in meinem Beispiel wäre es jetzt so, dass ich sagen würde, okay, an dem Fahrrad ist die Schaltung defekt.
Das würde ich jetzt dort irgendwie aufnehmen und, ach so, voraussichtliche Kosten berechnen.
Ja, lass uns das mal mit aufnehmen.
Vielleicht ist das gar nicht schlecht.
Das ist eigentlich tatsächlich ein Punkt, nicht?
Also das ist irgendwie, so Fahrraddefekt aufnehmen, etwas, was eher jemand macht, der so FahrradmechanikerIn oder Shop-MitarbeiterIn ist.
Das heißt, da würde jetzt irgendwie rauskommen, okay, das hat halt einen Schaltungsdefekt.
Und das ist übrigens auch erst die Stelle, wo ich jetzt sowas wie ein, das hatte der Jan gerade gesagt.
Die voraussichtlichen Kosten halt tatsächlich berechnen könnte, nicht?
Also, das wäre jetzt die Stelle, wo ich halt irgendwie sage, okay, cool, du hast eine Schaltung.
Welche Art von Schaltung ist denn das?
Das ist so eine Schaltung, weiß ich nicht, eine Campagnolo-Schaltung.
Dann kostet das halt irgendwie 200 Euro, das Schaltwerk auszutauschen, allein das Schaltwerk.
Und dann kostet es halt irgendwie 20 Euro, das irgendwie tatsächlich ranzumontieren.
Das wären also Sachen, die ich hier erst berechnen kann.
Also, hier wüsste ich halt andere Dinge, nicht?
Also, hier wüsste ich zum Beispiel, dass es eben um eine Reparatur geht und dass damit die Schaltung kaputt ist.
Und dann könnte ich hier auch noch solche Sachen machen, wie dass ich den, die Reparatur protokolliere.
Hier könnten wir jetzt also anfangen können, also Reparaturprotokoll wäre jetzt genau das.
Da gehört irgendwie genau sowas drin.
Wie ich habe ein neues Schaltwerk gekauft.
Ich habe das alte Schaltwerk ausgebaut.
Das hat 10 Minuten gedauert und kostet halt deswegen 10 Euro.
Ich habe ein neues Schaltwerk eingebaut, hat irgendwie auch 10 Minuten gedauert und hat 10 Euro gekostet.
Und ich habe mir irgendwie angeguckt die Bremsklötze waren halt auch irgendwie hin.
Und deswegen habe ich halt gleich neue Bremsklötze eingebaut.
Und die haben 25 Euro gekostet.
Und die habe ich halt irgendwie auch eingebaut.
Da ist halt so ein bisschen die Annahme, ich gucke mir halt das Fahrrad irgendwie an und schaue nochmal nach, ob bestimmte sozusagen sicherheitsrelevante Themen denn nun auch noch gemacht werden müssen.
Das heißt, wir haben jetzt eigentlich hier mehr gemacht, als ursprünglich geplant war.
Und die Annahme ist, dass wir das halt, ja, einfach sozusagen getan haben.
Ich mache jetzt mal eine Legende dazu.
Das hier wären so Daten, die wir da halt hätten.
Und das hier wäre so der Modulname, sage ich jetzt mal.
Und ich habe jetzt diesem Ding den Namen Reparatur durchführen gegeben.
So, und jetzt ist halt die Frage, die der Theo Grip gerade gestellt hat, ist, was ist mit dem Anmeldung der Reparatur durch den Status der Reparatur?
Genau, das ist eine, also könnten wir jetzt hier hin tun, nicht?
Das heißt, wir könnten jetzt sagen, die Reparatur ist geplant für den 18.03.
So, und wenn sich jetzt hier eine Änderung ergibt, weil halt irgendein hochpriorisiertes Ding reinkommt oder weil halt irgendein Mechaniker rauskommt, ausfällt oder sonst, oder eine Mechanikerin, dann könnte ich halt hier das sozusagen ermitteln.
Aber vielleicht will ich ja auch etwas wissen darüber, wie die Reparatur durchgeführt wird gerade.
Nicht?
Also das heißt, was ich mir jetzt wünschen, vielleicht wünschen würde wäre, ich gucke mir als Kunde das halt irgendwie an und ich sehe, entweder die Reparatur wird durchgeführt oder die Reparatur wird durchgeführt.
Also die Reparatur ist eingeplant für den 18.03. oder am 18.03. steht halt drin, wir haben übrigens jetzt deine Schaltung repariert und außerdem deine Bremsklötze und das kostet halt so und so viel Geld oder aber wir haben irgendwie die Schaltung erstmal nur bestellt, solche Geschichten.
So, und das sind die Informationen, die wir jetzt hier drin haben.
Und das ist jetzt für etwas, ich halte das für ein allgemeines Pattern sozusagen.
Also das ist etwas, wo ich irgendwie in einer bestimmten Sicht Informationen habe, die ich jetzt hier irgendwie sozusagen erstmal aufgeteilt habe.
Also hier ist es halt so, dass ich sage, es geht eigentlich nur um den Termin und wann ich es machen möchte.
Und hier haben wir jetzt eben so etwas, wie wir das vielleicht in die Reparatur reingucken und dann schauen, was tatsächlich passiert ist.
Und das hier ist jetzt nicht jetzt so ein bisschen quer.
Und ich glaube, daraus gibt es zwei mögliche Antworten.
Die eine Antwort wäre, dass man diese Funktionalität gemeinsam in diesen beiden Modulen umsetzt.
Das heißt also, hier kriege ich einen Status raus, der halt irgendwie sagt, ist am 18.03. eingeplant.
Und hier kriege ich halt einen Status raus, der halt sagt, wir haben übrigens die Schaltung jetzt ausgewechselt und irgendwelche Dinge halt getan.
Aber bedauerlicherweise ist es halt so, dass die Bremsklötze noch nicht da sind.
Die müssten aber eigentlich noch eingebaut werden.
Und deswegen dauert das noch.
So, das wäre eine Möglichkeit.
Und jetzt will ich ja so etwas irgendwie gemeinsam anzeigen.
Also ich will eine Webseite haben, wo ich den Status der Reparatur sehen kann auf einer Seite.
Und hier sind aber zwei Module.
Wie gehe ich damit um?
Erstmal, ich glaube, diese fachliche Aufteilung ist trotzdem sinnvoll.
Weil wir dadurch den Vorteil haben, weil ich denke, dass wir hier zwei unterschiedliche Informationsdichten sozusagen haben.
Und wir hier diese Sachen eben fachlich aufteilen können.
Und ein bisschen geht das in diese Richtung von Bounded Contexts, wo ich eben sage, ich habe ein Domänenmodell, was eine bestimmte Funktionalität erreicht.
Und ich erwarte, dass ich in diesen Domänenmodellen identische Dinge habe.
Also Dinge, die gleich benannt sind.
Also die Reparatur.
Aber unterschiedliche Informationen, die damit einhergehen.
Und ich habe halt in dem linken System jetzt die Reparatur eigentlich als Termin.
Was eigentlich bedeutet Arbeitsplanung.
Was ich also auch für mich als Eberhard Wolff, der Berater, nutzen könnte.
Und rechts habe ich jetzt irgendwie das Wissen, dass eine Reparatur bedeutet, dass ich irgendwie Ersatzteile habe, dass ich die einbaue, dass es Zeit kostet und so weiter.
Das ist also etwas, was wirklich für Mechaniker relevant ist.
Diese beiden Systeme jetzt zusammenzupacken, macht, glaube ich, keinen Sinn.
Das heißt, diese Teilung ist, glaube ich, sinnvoll.
Eine Möglichkeit dafür zu sorgen, dass es halt trotzdem diese Webseite gibt, ist, indem man halt sagt, diese Webseite wird gemeinsam hergestellt von diesen beiden Systemen.
Das heißt also, das erste System würde halt oben sagen, die Reparatur ist am 18.03. angefangen worden.
Und dann würde halt der untere Teil, würde halt der rechte Teil mit der Durchführung sagen, und wir haben halt übrigens folgende Dinge gemacht.
Das wäre eine Möglichkeit, dass man das sozusagen so kollaborativ darstellt.
Die andere Möglichkeit wäre, dass man irgendwie sowas sagt wie, es gibt den…
Wir haben ein neues System, das halt nur dazu da ist, den Status der Reparatur anzuzeigen.
Und das ist also der Reparaturstatus.
Tatsächlich fällt mir nicht ein, wie ich den sonst benennen würde.
Und der hat jetzt eben sozusagen die Benutzer-Sicht, die Kundensicht auf diese ganzen Geschichten.
Das heißt, der kriegt jetzt von hier die Information über ein Datum.
Der kriegt von hier die Information darüber, was in dieser Reparatur drin ist.
Und dann können wir…
Das wäre halt sozusagen eine Alternative.
Ich finde das in diesem Fall nicht sonderlich sinnvoll.
Ich finde die andere Idee besser.
Ich glaube, die baue ich jetzt irgendwie auch nochmal ein.
Also diese Idee, dass ich eben sage, der Status wird eben in beiden ermittelt.
Dieser Ansatz wäre zum Beispiel ein Ansatz, den ich wählen würde, wenn ich so Statistiken haben möchte oder sowas.
Also einen sehr begrenzten und auch sehr anderen Blick auf diese Sachen.
Wenn ich zum Beispiel in der Statistik irgendwie sagen möchte, was fällt mir denn ein?
Wie viele Schaltungen habe ich irgendwie eingebaut?
Da brauche ich ja nur irgendwie Plus 1.
1, Plus 1, Plus 1.
Das heißt, eine ganze Menge an Informationen.
Also zum Beispiel, wie teuer war das?
Wie lange hat es gedauert?
Und so weiter.
Das interessiert mich alles nicht.
Und ich will das vor allem irgendwie summieren.
Ich will irgendwie eben eine Statistik darüber machen.
Das ist, glaube ich, eine deutlich getrennte Sicht von dem Reparaturstatus selber.
Und das würde für mich nur als Domänenmodell rechtfertigen.
Also es geht ja darum, dass wir Domänenmodelle haben wollen, also unterschiedliche Modelle haben wollen.
Und hier würde ich eben sagen…
Den Status abfragen.
Dafür brauche ich halt exakt diese Informationen, die hier drinstehen.
Vielleicht etwas weniger, weil ich nicht ausschließen will, dass hier in diesem Protokoll Dinge drinstehen, die jetzt eben nicht kundensichtbar sein sollen.
Aber die sind so identisch, dass ich eben eher dazu neigen würde, das mit dort zu implementieren und eben nicht noch ein eigenes Modul dafür zu bauen.
Also schmeißen wir das.
Schmeißen wir das mal weg.
Jan sagt jetzt noch, vielleicht können wir die Terminplanung auch einkaufen, Supporting Domain.
Also wir brauchen auch noch…
Sorry, da steht halt…
Moment, ich muss mal kurz durch die Kommentare durchgehen.
Voraussichtliche Kosten berechnen.
Genau, das wäre halt etwas, was ich jetzt auch hier sehen würde.
Haben wir das gesagt?
Ja, haben wir gesagt.
Genau, das muss halt auf dieser Ebene…
Das muss ich halt auf dieser detaillierteren Ebene betrachten.
Gehört zur Anmeldung der Reparatur auch den Status der Reparaturabfragen.
Das haben wir gerade diskutiert.
Zum gleichen Modul.
Wir brauchen also auch die Möglichkeit, den Kunden zu kontaktieren.
Zum Beispiel Gepäckträger defekt, nicht sicherheitsrelevant, kann natürlich offline zum Beispiel Telefon erfolgen.
Genau, das wäre jetzt etwas, worüber ich tatsächlich nicht…
Guter Punkt, nicht?
Wir brauchen also eine Möglichkeit, den Kunden…
Wir brauchen also eine Möglichkeit, den Kunden zu kontaktieren.
Ist das ein Problem, das ich hier in diesem IT-System abfrühstücken würde?
Ich würde behaupten, nein.
Also, was hier konkret passiert, ist Folgendes.
Der Mechaniker sitzt an dem Fahrrad, stellt fest, die Bremsklötze sind völlig unten.
Wenn ich den jetzt irgendwie losschicke mit diesem Fahrrad, dann sollte die Person…
Also, dann ist die Person halt nicht sicher.
Ich will also die Bremsklötze austauschen.
Nimmt das Telefon und guckt jetzt in diesem System nur die Kundeninformationen nach und ruft eben an und sagt, hey, haben wir übrigens…
So, das kann ich noch protokollieren, nicht?
Also, ich könnte jetzt protokollieren, wenn ich das will, Kunde informiert und könnte halt irgendwie sagen, das waren irgendwie 0 Euro, weil das gehört irgendwie mit zum Service oder vielleicht berechne ich es.
Keine Ahnung.
Insofern könnte das da drin sein, aber ich bin nicht sicher, ob das tatsächlich eine Funktionalität ist, weil der wesentliche Akt, nämlich, dass ich das Telefon genommen habe und die Person angerufen habe, die ist ja gerade außerhalb des IT-Systems.
Also, deswegen bin ich mir nicht sicher, ob das so richtig mit dazu gehört.
Vielleicht können wir die Terminplanung auch einkaufen.
Das führt zu einer wichtigen, glaube ich, Allgemeingeschichte.
Das will ich nicht ausschalten.
Das will ich nicht ausschließen.
Und das ist aber, ehrlich gesagt, eine Sache, wo ich festgestellt habe, dass ich persönlich so ein bisschen blind bin.
Also, will heißen, ich bin nämlich Software-Architekt.
Das heißt, ich bin nämlich darauf spezialisiert, Software zu bauen.
Ich finde es gut, wenn man Software nicht baut, sondern sie einkauft.
Ich kann das aber nicht ernsthaft bewerten.
Das heißt, das wäre halt etwas, wo ich andere Personen sehen würde.
Und vielleicht an der Stelle noch ein Hinweis.
Da ist hier jetzt die Verwendung von diesen Begriffen Support.
Supporting Domain, das ist etwas aus Domain-Driven Design.
Da gibt es eben diese Aufteilung in im Wesentlichen Generic Subdomains, Supporting Domains und Core Domains.
Und Core Domains sind die, die mich im Geschäft differenzieren.
Die also so sind, dass, wenn ich die halt gut implementiere, dass sie dann irgendwie einen Geschäftsvorteil generieren.
Supporting sind die, die ich implementieren muss, um die anderen zu unterstützen.
Und Generic sind die, die halt tatsächlich generisch sind.
Die ich also einfach einkaufe.
Die halt, wie soll ich sagen, für den Geschäftserfolg egal sind.
Dazu würde bedeuten, dass wenn ich es einkaufe, die Terminplanung eine Generic Subdomain wäre, aus meiner Wahrnehmung heraus und aus meiner Interpretation der Begriffe.
Ich finde es wichtig, die Begriffe sauber zu benutzen.
Deswegen wollte ich darauf nochmal irgendwie hinweisen.
Und das wäre vielleicht eine Option.
Kann ich nicht beurteilen, müsste man sich angucken.
Und ich habe tatsächlich Überraschungen erlebt, was es so an spezialisierten Modulen gibt.
Also auch so im Bereich von von Geschäftslösungen.
Von daher guter Punkt.
Aber an irgendeiner Stelle wird das sowieso alles absurd, weil wahrscheinlich gibt es eine vorgefertigte Lösung für Fahrradläden.
Nehme ich mal an und Reparaturplanung.
Von daher ist das sowieso die Frage, was wir uns hier geben wollen.
Und vielleicht noch eine Bemerkung zum Thema Core Domain.
Also, wie wird dieses System erfolgreich?
Also eine mögliche Antwort wäre, indem wir in der Core Domain besonders gut davor sind.
Was ist denn unsere Core Domain?
Also Terminplanung, Reparatur durchführen?
Weiß ich nicht.
Ich finde dieses Beispiel, ich habe das nicht danach ausgewählt, aber ich finde dieses Beispiel ganz spannend, weil wenn man mich jetzt fragt, wie kriegen wir dieses System zum Erfolg?
Dann würde ich sagen, ich kriege dieses System zum Erfolg, indem es halt besonders benutzerfreundlich ist.
Weil dann finden die Benutzer das irgendwie super.
Und ich habe beim letzten Mal gesagt, daraus kann irgendwie auch so eine Software-as-a-Service-Lösung werden.
Dann können wir also ein Software-as-a-Service machen.
Dann können wir halt sagen, guck mal hier, in meinem Fahrradladen, die Leute sind alle super zufrieden damit.
Das willst du bestimmt auch kaufen.
Und dann haben wir einen Erfolg.
Ich würde behaupten, das ist ein bisschen unabhängig.
Unabhängig von den Core Domains.
Also ich würde hier behaupten, aber ich habe das System sozusagen in meinem Kopf nicht vollständig durchspezifiziert oder nicht vollständig durchdacht.
Ich würde halt hier behaupten, dass uns diese Idee von sowas wie Core Domain oder Generic Subdomains, um halt zu sehen, dass wir dieses Projekt erfolgreich aus der Tür bekommen, nicht der Schlüssel ist.
Sondern das, was wir dann hoffentlich von Aminata mitbekommen, das wird uns halt helfen, dieses System wirklich erfolgreich zu machen.
Aus unserem Architekturentwurf kommen die Anforderungen an die eventuell einzukaufenden Produkte.
Vielleicht gibt es diese ja nicht, sagt Jan gerade.
Ja, also es steht, glaube ich, außer Frage, dass man eine Terminplanung kaufen kann.
Und dann kann ich halt möglicherweise an einigen Stellen Kompromisse eingehen.
Also von daher, ich glaube, das ist genau ein Teil von diesem Generic Subdomain-Geraffel.
Dass ich an der Stelle sage, ich will eben gerade nicht diese hochspezialisierte, exakt für mich passende Lösung haben, sondern ich will etwas haben, was ungefähr passt.
Und wenn es nicht genau passt, ist es halt auch fein.
Und bei der Terminplanung, vielleicht ist das halt tatsächlich ausreichend.
Also kann ich mir sehr gut vorstellen.
Und dann würge ich das halt irgendwie in den Rest des Systems rein.
Könnte sinnvoll sein.
Also ist ja auch etwas, was…
Was so ein bisschen üblich ist.
Wir haben ja die, wie soll ich das jetzt sagen, die viele von den Standardsoftware-Produkten, die man hat benutzt, gerade so im ERP-Bereich sind halt so, wie sie sind.
Und die sind ja eben gerade nicht so, dass man sie anpassen wollen würde, beziehungsweise da wird es dann halt leicht teurer dafür zu Projekte abbrechen.
So, zurück zu unserer weiteren Aufteilung.
Ich habe, genau, wir haben jetzt hier noch Reparatur bezahlen.
Und da würde ich halt sagen, da geht es halt tatsächlich nur darum, einen Betrag zu bezahlen.
Und das würde ich jetzt mal sagen, ist was Eigenes.
Also da sage ich jetzt, okay, das mache ich irgendwie.
Und das passt irgendwie nicht zu dem, was wir hier haben.
Da habe ich zwar die ganzen Preise, aber ich würde es halt, glaube ich, tendenziell trennen.
Ich kann ab hier irgendwie so ein Ding, wo ich als Datum eigentlich eben tatsächlich nur noch einen Geldbetrag habe.
Also ich sage halt, ich bezahle jetzt.
Also 10 Euro und dann hat sich das halt.
Oder, also hier ist es, glaube ich, deutlich teurer.
Hier sind es irgendwie, weiß ich nicht, 150 Euro oder so.
Aber ich habe hier keine Informationen mehr über die Reparatur an der Stelle.
Und deswegen kann das eben ein sozusagen rundes, also bei mir ja eckig, aber ein rundes neues Modul sein.
Und dann habe ich hier das Einplanen von der Reparatur.
Das wäre auch wieder etwas in der Terminplanung.
Und dann würde ich hier eben den Kunden über das Ende der Reparatur informieren.
Das würde ich hier sehen bei der Reparatur durchführen, weil ich eben an dieser Stelle jetzt irgendwie sage, okay, alle die Sachen, die wir halt haben möchten, die sind halt jetzt erfüllt.
Jan merkt gerade an, wir wollten noch die Buchhaltung und die Kasse anbinden.
Genau, das wäre jetzt der nächste Schritt.
Also die Drittsysteme, die haben wir anzubinden.
Das ist noch ein Thema.
Dann habe ich hier noch Fahrrad zur Reparatur abgeben.
Das würde ich hier mit sehen, weil ich jetzt eben genau an der Stelle bin, wo ich sozusagen, wo das, wo aus dem Termin eine Reparatur wird, so ein bisschen.
Und dann habe ich hier noch Ersatzteile bestellen und Werkzeuge bestellen.
Und da muss man ein bisschen Platz schaffen.
Da wäre halt meine Aussage.
Das, das vielleicht auch was Eigenes ist.
Und zwar eben die Materialbeschaffung, die jetzt sowas kennt wie eine Bestellung von Bestellung bei einem Großhändler.
So, das wäre jetzt also so eine grobe fachliche Aufteilung.
Und genau, ich habe hier das Reparatur, das Fahrrad abholen wäre dann eben auch etwas, was ich hier bei diesem.
Das Reparatur-Ding irgendwie sehen würde.
So, so würde also mein System aussehen.
Dann kann ich das hier einmal löschen.
Und das kann ich später auch nochmal hübsch machen.
So, und wir haben jetzt so eine allgemeine fachliche Aufteilung.
Und der Jan hat es ja schon gesagt.
Irgendwie brauchen wir da noch was.
Und ich habe hier aus dem arc42 mal so ein Diagramm rausgeholt.
Das ist so eine fachliche Aufteilung.
Das heißt, ich habe hier diese Scope-und-Kontext-Diagramm.
Den haben wir letztes Mal erstellt und wir können jetzt hier eigentlich den nächsten Level erzeugen.
Das heißt, wir können jetzt irgendwie sagen, wir haben innerhalb unseres Systems irgendwelche Module, die irgendwie miteinander reden.
Und dann sollten wir sinnvollerweise vielleicht auch die Drittsysteme daran anschließen.
Und das können wir jetzt tun.
Nicht.
Also wir haben jetzt irgendwie identifiziert, dass wir diese vier Systeme haben oder Module, sollte ich halt irgendwie sagen.
Und das hier ist irgendwie alles informelles Zeug, was also wobei stimmt ja gar nicht nicht.
Also da stehen ja schon irgendwie zumindest so ein paar Sachen irgendwie drin.
Ich bin mir aber nicht sicher, ob ich das zum Beispiel.
Also wenn das, wenn man das jetzt bei einer Prüfung jemandem in die Finger geben würde, würde diese Person wahrscheinlich sagen.
Netter Versuch, aber das ist halt kein vernünftiges, strukturiertes Diagramm, was nicht schlimm sein muss, weil kann ja trotzdem sein, dass es uns irgendwie hilft.
Aber wir brauchen jetzt irgendwie noch mehr.
Also wir brauchen jetzt irgendwie eine Idee davon, wie wir das tatsächlich in Software gießen.
Und dazu will ich jetzt eigentlich gerne irgendwas fehlt.
Jetzt habe ich zweimal die Bezahlung, weil ich zu doof war.
Das Material beschaffen.
Funktionen der Beschaffung.
Das sieht gut aus.
So, dann kann man es hier auch reintun.
So, das heißt, ich habe jetzt diese vier Module.
Und was ich jetzt gerne machen möchte, ist erst mal irgendwie definieren, wie die miteinander zusammenhängen.
Und dazu habe ich mir jetzt überlegt, dass wir Pfeile malen.
Haha, Architektur.
Box und Pfeile, wer kennt’s?
Und bei hier ist es jetzt eben so, dass ich bei den Pfeilen als Semantik haben möchte, die Aufrufrichtung und ich möchte die ausgetauschten Informationen dorthin schreiben.
Das ist eine Legende, also nicht Legende zu dem Diagramm.
Das hat den Vorteil, dass ich mich jetzt hier nicht sklavisch an irgendeinen Standard halten muss.
Und by the way.
Das ist jetzt übrigens nicht.
So was wie upstream downstream aus dem DDD, sondern das ist was anderes.
Also das ist halt mein eigener Spaß sozusagen.
Und jetzt können wir mal schauen.
Dass wir hier eine Beziehung aufbauen und ich muss den Type mal festlegen.
Das ist der da gestrichen.
Da habe ich das gemacht.
Ich weiß gar nicht warum.
Das, was ich hier austauschen möchte, ist eben der Termin und ja, von der Reparatur durchführen zur Bezahlung.
Da habe ich den Preis, den ich irgendwie austauschen und von.
Der Reparatur durchführen hin zur Materialbeschaffung hätte ich jetzt die Materialbestellung, die da halt irgendwie ausgetauscht wird.
Und dann bin ich sozusagen hiermit erst mal fertig.
So, was ich jetzt sinnvollerweise noch machen sollte, ist, ich sollte mir irgendwie eine Idee, eine Idee generieren, wie ich jetzt eigentlich meine Umsysteme da rein bekomme.
So, jetzt ist die Frage, warum man Browser nicht mehr möchte.
Das ist ja sehr, sehr pro ist ja jetzt wieder.
Also ich möchte jetzt dich da nicht.
Ich möchte.
Jetzt hier.
Was genau?
Bevor ich das jetzt.
Drittsysteme sollte ich anschließen.
Genau das wäre der nächste Punkt.
Bevor ich das tatsächlich tue, würde ich gerne nochmal die roten Boxen definieren.
Und ich habe mir überlegt.
Das sind Komponenten und zwar sind das separierte Projekte in der Versionskontrolle.
So, das heißt also, ich habe jetzt hier gesagt, es gibt ein Projekt Terminplanung, ein Projekt Reparatur durchführen, ein Projekt Bezahlung und ein Projekt Materialbeschaffung.
Das sind drei Git-Repositories.
Und die Alternative wäre, dass ich sowas hier habe.
Komponente gleich separiertes Verzeichnis im Source Code.
Ich finde das hier total wichtig, weil.
Häufig genug ist es irgendwie so, dass ich so ein Architektur-Diagramm sehe und dann irgendwie die Frage stelle.
Die relativ in meinen Augen relativ unschuldige Frage.
Was sind eigentlich diese Boxen?
Und dann stellt sich halt heraus, dass diese Boxen in Wirklichkeit keine Semantik haben.
Und das finde ich halt super gefährlich, weil ich rede irgendwie ganz viel über solche Diagramme.
Und wenn diese Diagramme keine keine Semantik haben, dann rede ich halt gerade über nichts.
Also dann dann das, was ich da gerade tue, hat dann eigentlich in Wirklichkeit keine Bedeutung.
Und das ist relativ desaströs.
So, jetzt muss ich mal kurz gucken.
Da sind irgendwelche Fragen.
Das wird wohl Event getrieben.
Ich weiß nicht, ob das Event getrieben wird.
Gute Frage vielleicht.
Sollen Komponenten Aufrufrichtungen sollen Komponenten nach Informationen fragen oder sollen sich aktiv sollen aktiv neue Informationen publiziert werden?
Und verbaut gefragt, haben wir durch die Aufrufrichtung jetzt schon implizit gesagt, dass die Module sich direkt aufrufen?
Ist etwas wie ein Message jetzt schon ausgeschlossen?
Das finde ich ist eine gute Frage.
Tatsächlich ist es so, dass ich über synchrone Calls nachgedacht hatte.
Sprich nicht die Terminplanung sagt halt hier ist der Termin.
Mach man der Reparatur daraus.
Die Reparatur sagt dann dem.
Hier ist der Preis sorgt man dafür, dass bezahlt wird und die Reparatur durchführen.
Sagt in der Materialbeschaffung sorgt man dafür, besorgt man dafür, dass dieses halt gekauft wird.
Das könnte man natürlich auch irgendwie mit Messages noch umsetzen.
Man kann ja sagen, ich schicke jetzt einen Request los.
Aber ein bisschen war da ein synchrones Denken bei.
Ich würde es aber auf dieser Ebene eigentlich noch nicht ausüben.
Weil wir noch nicht auf dieser technischen Ebene sind.
Wir sind auf der konzeptionellen Ebene.
Was ich damit auf jeden Fall implizieren wollte ist, ich möchte gerne, dass tatsächlich Materialbeschaffung und Bezahlung gebaut werden können.
Reparatur das irgendwie nutzt und Terminplanung das irgendwie nutzt.
Dass ich also sozusagen eine Build-Reihenfolge habe.
Und die kann ich ja nur dann haben, wenn eben die technischen Abhängigkeiten in diese eine Richtung gehen.
Ich glaube, das ist so ein bisschen das, worum es da, ja darum ging es eigentlich für mich.
Und ich habe jetzt hier eben so einen gerichteten Graphen.
Was aber jetzt beispielsweise bedeutet, dass die Terminplanung vielleicht bei der Reparatur nachfragen muss, ob die aktuelle Planung noch okay ist.
Solche Geschichten.
Das ergibt sich irgendwie da draus.
Und dadurch haben wir dann ja vielleicht tatsächlich sowas wie MessageBus stärker ausgeschlossen.
Eher als Richtung des Informationsflusses.
Also verbaut die Frage gerade.
Also sind die Pfeile eher als Richtung des Informationsflusses zu interpretieren.
Ja, vielleicht ist das besser.
Also lass uns das mal machen.
Lass uns sagen, es gibt einen Informationsfluss.
Finde ich übrigens gut, weil das weist eben darauf hin, dass das ist irgendwie schlau, aber mal diese Semantik tatsächlich zu definieren.
Und irgendwie das mal hinzumalen.
Und wie gesagt, ich finde es halt krass erschreckend, wie viele Architektur-Diagramme, die ich irgendwie sehe, wo Boxen und Pfeile sind.
Und irgendwie die Aussage, und wenn man irgendwie nachfragt, kommt irgendwie die Aussage.
Also ja, das ist eigentlich noch schlimmer.
Es kommt nicht die Aussage, hör mal zu.
Wir wissen es nicht genau.
Es wird so getan, als wüsste man es.
Aber in Wirklichkeit weiß man es halt nicht, was das nun genau bedeutet.
So, jetzt muss ich mal schauen.
Ich würde jetzt hier noch einmal sagen, das ist halt sozusagen die Grenze des Systems.
Und jetzt wollen wir…
Wir haben irgendwo diese ganzen lustigen Umsysteme definiert.
Da sind sie.
Das heißt, die würde ich jetzt einmal kopieren.
Kann ich die kopieren?
Kann ich natürlich.
Und hier irgendwie hinschmeißen.
Und dann würde ich außerdem gerne noch die Farbe ändern.
Und irgendwie sagen, dass das eben die externen Systeme sind.
Und jetzt können wir mal schauen, dass wir die entsprechend da hin strukturieren.
So, und da würde ich jetzt irgendwie sagen, der SMS-Versand und die E-Mail-Systeme, die sind dazu da, dass ich Updates schicke über den Zustand der Reparatur.
Das ist also etwas, was eben Reparatur durchführen benutzt.
Dann habe ich die Kasse und das Online-Payment-System.
Die würde ich jetzt mal behaupten, offensichtlich genutzt werden von der Bezahlung.
Und dann habe ich irgendwie noch diese, genau, dann habe ich das Rechnungswesen.
Und das würde ich jetzt sagen, dass ich hier…
Das würde ich hier auch dementsprechend anschließend an die Reparatur durchführen.
Weil ich hier ja eben die Information habe, was genau sich geändert hat.
Oder was genau repariert worden ist.
Und das will ich in der Rechnung drin haben.
Ich will da mit drin stehen haben, ich habe einen Bremsklotz reingebaut und was weiß ich.
Und hier will ich halt nur sagen, ich habe irgendwie 250 Euro bezahlt.
Deswegen sind das eben unterschiedliche Informationen.
Und ich kann das mal kurz…
Also ich habe das hier Rechnungselemente.
Tatsächlich genannt.
Und da unten nennen wir die Informationen über die Updates.
So, und dann habe ich hier noch den Webshop und die User-Database.
Und das sind also die…
Da würde ich jetzt folgende Beziehungen sehen.
Also erstmal, ich würde die gemeinsam sehen.
Sonst muss ich halt irgendwie zu viele Pfeile malen.
Und ich würde jetzt behaupten, dass…
Ich über das…
Da war die Idee, dass ich innerhalb des Websystems eine Information, Seiten einblenden kann, die es mir zum Beispiel ermöglichen, Reparaturen zu schedulen.
Oder die es mir beispielsweise ermöglichen, den Reparaturstand zu sehen und so weiter.
Also dass ich dort eben Webseiten einbinde.
Und da würde ich jetzt sagen, ich brauche dementsprechend dort die Möglichkeit zu…
Das ist leider nicht so schön.
Zu…
Reparaturen durchführen, Terminplanung und auch zur Bezahlung, die ich ja möglicherweise online durchführe.
Entsprechend, dass ich dort Beziehungen habe.
Dass ich also die Möglichkeit habe, in all diesen drei System-Webseiten jeweils anzuzeigen innerhalb des Webshops.
Und damit haben wir es sozusagen.
Und genau, jetzt…
Jan sagt noch Bezahlung, Rechnungswesen.
Rechnung ist bezahlt.
Weiß ich nicht.
Ist das so?
Also könnte halt auch eher im Hintergrund laufen.
Zwischen Kasse, Online-Payment und dem Rechnungswesen.
Das wäre halt irgendwie auch denkbar.
So, und so hätte ich jetzt eine Idee, wie mein System aufgebaut wäre.
Ich würde jetzt also…
Also wenn ich das so umsetze, habe ich jetzt gesagt, es gibt vier Projekte in der Versionskontrolle.
Dieses Projekt…
Und ich habe gesagt, wie diese einzelnen Systeme verbunden sind.
Das heißt Termin…
Diese…
Terminplanung, Reparatur durchführen und Bezahlung würden irgendwelche Seiten anzeigen.
Die haben…
Die im Webshop angezeigt werden.
Ich habe hier dann das Rechnungswesen, den SMS-Versand, E-Mail-Versand, Kasse, Online und so weiter.
Die anderen externen Schnittstellen.
Und ich habe damit meinen Kontext jetzt irgendwie sozusagen erstmal sauber bekommen.
Und wäre da sozusagen durch.
Jan sagt noch Reparatur nach User-DB, Kontaktinformation für Rückruf ermitteln.
Vielleicht nicht.
Ich bin mir nicht sicher, wie wir das genau definiert haben.
Denn ich glaube, dass wir hier nur die Informationen über den Benutzer-Account haben.
Nicht die Informationen über den Kunden.
Das wäre also vielleicht eher etwas, was aus dem Webshop kommt.
Also dieses Ding hier ist etwas, wo drin steht, weiß ich nicht, ewolff, Passwort.
Und nicht unbedingt die Telefonnummer, meine Telefonnummer.
Die Telefonnummer steht halt wahrscheinlich möglicherweise erst im Webshop.
Gut.
Das dazu.
Ich schaue nochmal kurz, ob ich irgendwo irgendwelche Fragen gesehen habe.
Das sieht aber nicht danach aus.
Dann sind wir, glaube ich, an der Stelle erstmal fertig.
Kurz nochmal ein Hinweis auf die Folgefolgen.
Nächste Woche gibt es eine weitere Episode von Software-Architektur als Beruf, habe ich gesagt.
Und am 25. gibt es dann eben die Folge, wo wir uns darum kümmern wollen, wie wir in diesem…
Ich glaube, die Hauptherausforderung lösen, nämlich die Benutzerfreundlichkeit mit meiner Kollegin Aminata.
Dann würde ich sagen, vielen Dank, schönes Wochenende und bis dann spätestens übernächsten Freitag.
Bis dahin.