Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
- Qualitätsszenarien entstehen in Zusammenarbeit von Architektin und Kunde, nicht im Alleingang.
- Die Frage “Was passiert, wenn das System ausfällt?” liefert mehr als die Frage nach der gewünschten Verfügbarkeit.
- Das System wird fachlich in vier Module zerlegt, nicht technisch in UI, Logik und Persistenz.
- Jede Box im Diagramm braucht eine definierte Bedeutung, hier ein eigenes Projekt in der Versionskontrolle.
- Die Abhängigkeiten zwischen den Modulen sollen eine Build-Reihenfolge ermöglichen.
Behandelte Kernfragen
- Wer definiert nicht-funktionale Anforderungen, wenn der Kunde keine messbaren Vorgaben macht?
- Wie fragt man nach Verfügbarkeit und Konsistenz, ohne nur ein “natürlich” als Antwort zu bekommen?
- Warum sollte die grobe Struktur des Systems fachlich und nicht technisch sein?
- Wie geht man mit einer Funktion wie dem Reparaturstatus um, die Informationen aus zwei Modulen braucht?
- Kann man ein Modul wie die Terminplanung einkaufen, und was bedeutet das für die Architektur?
- Was bedeuten die Pfeile in einem Architektur-Diagramm: Aufrufrichtung oder Informationsfluss?
Glossar wichtiger Begriffe
- Qualitätsszenario: Eine messbare Beschreibung einer Qualitätsanforderung, etwa dass 90 Prozent der Nutzer eine Reparatur innerhalb von zwei Minuten beauftragen können.
- Bounded Context: Ein abgegrenztes Domänenmodell, in dem ein Begriff wie Reparatur eine eigene, auf den Kontext zugeschnittene Bedeutung hat.
- Core Domain: Der Teil der Fachlichkeit, der das Unternehmen im Geschäft differenziert und deshalb besonders gut umgesetzt werden sollte.
- Supporting Domain: Ein Teil der Fachlichkeit, den man implementieren muss, um die Core Domain zu unterstützen.
- Generic Subdomain: Ein Teil der Fachlichkeit, der für den Geschäftserfolg unerheblich ist und deshalb eingekauft werden kann.
- Kontextdiagramm: Die Darstellung des Systems mit seinen Nachbarsystemen, die hier um die interne Modulstruktur ergänzt wird.
Genannte Technologien
- arc42: Template für Architekturdokumentation
- Domain-Driven Design: Ansatz, aus dem die Begriffe Core Domain, Supporting Domain und Generic Subdomain kommen.
- Event Storming: Workshop-Format, um komplexe Fachlichkeit gemeinsam zu erschließen.
- Domain Storytelling: Methode, um fachliche Abläufe als Geschichten zu modellieren.
- Git: Versionskontrolle, in der jedes Modul ein eigenes Repository bekommt.
- Message Bus: Asynchrone Kommunikation zwischen Modulen, die durch die Pfeilsemantik nicht ausgeschlossen werden soll.