Modelle & Architektur
Fachliche Abläufe und Softwaregrenzen – sichtbar vor der Umsetzung.
Die Planung enthält nicht nur eine Systemübersicht. Sie trennt den fachlichen Prozess von der Softwarearchitektur und beschreibt Kontext, Bausteine, Laufzeit, Verteilung und überprüfbare Abhängigkeitsregeln.
Einordnung
arc42 ist der Rahmen. Die Softwarearchitektur steckt in den konkreten Sichten.
Die Kontextsicht zeigt Beteiligte und externe Systeme. Die Bausteinsicht legt Module und erlaubte Abhängigkeiten fest. Laufzeit- und Verteilungssicht zeigen, wie die Anwendung reagiert und wie ein geprüfter Stand ausgeliefert wird.
Die folgenden Visualisierungen sind kuratierte, barrierearm lesbare Darstellungen der vorhandenen Modelle. Die versionierten BPMN-XML- und Markdown-Dateien bleiben der maßgebliche Projektnachweis.
BPMN-Geschäftsprozesse
Zwei Prozesse decken Entdeckung und Reservierungssimulation ab.
Fehlerpfade im Modell: Eine unbekannte Route führt zu einer echten 404 mit Rückweg. Blockiertes Video, Reduced Motion oder ein Medienausfall dürfen Inhalt, Links und Bedienung nicht unbrauchbar machen.
Schleife im Modell: Ungültige Eingaben führen mit konkretem Fehler und Fokus zurück zur Eingabe. „Ändern“ erhält Werte, „Neu“ leert sie und „Verlassen“ beendet die flüchtige Sitzung.
Softwarearchitektur
Vier Sichten machen unterschiedliche Entscheidungen überprüfbar.
KontextsichtProduktlaufzeit und Engineering bleiben getrennt
Öffentlicher Besucher
→Browser
Hotel & Demoformular
←Statischer Host
CI → Artefakt an Host · Reporting-Adapter → softwaretest.it
Name und Reisedaten verlassen den Browser nicht. softwaretest.it ist eine Engineering-Integration, keine Laufzeitabhängigkeit des Hotels.
BausteinsichtKleine Module mit klarer Richtung
Pages
→Components / Layouts
→Content
→Reservation Controller
→Reservation Domain
CI Jobs → Reporting Adapter
Inhalte und Reservierungsdomäne hängen nicht von weiteren Anwendungsmodulen ab. Der Reporting-Adapter darf nie in das Browserbundle gelangen.
LaufzeitsichtValidierung ohne Servertransaktion
- Gast → ControllerKategorie, Daten und Name
- Controller → Domainvalidate(input, today)
- Domain → ControllerFeldfehler oder normalisierte Werte und Nächte
- Controller → GastFokus und Fehler oder lokale Demo-Bestätigung
Edit und Reset bleiben lokale Zustandsübergänge; ein Neuladen beginnt leer.
VerteilungssichtQuellstand, Prüfungen und Ziele bleiben verbunden
- Lokale Entwicklung
- Repository
- isolierte CI
- Staging & Produktion
CI-Nachweise → softwaretest.it
Staging und Produktion führen denselben Anwendungskandidaten; umgebungsspezifische SEO-Konfiguration wird getrennt geprüft.
Prüfbare Regeln
Architektur wird erst verbindlich, wenn Verstöße erkennbar sind.
- ARCH-01
Die Reservierungsdomäne kennt weder Framework, DOM, Storage, Netzwerk noch Reporting.
- ARCH-02
Pages → Controller → Domain ist erlaubt; Rückimporte und Zyklen sind verboten.
- ARCH-03
Reporting lebt ausschließlich im CI-Toolbaum und nie transitiv im Produktbundle.
- ARCH-04
Über die Domaingrenze gehen reine Daten – keine Browser-Events oder HTML-Elemente.
- ARCH-05
Kategorien und zentrale Labels stammen aus einem kanonischen Inhaltsvertrag.
Traceability
Jede Ebene verweist auf die nächste.
Stabile IDs verbinden Anforderung, Prozess, Architekturregel, Capability, Workorder, Test und Nachweis. Dadurch ist eine Änderung nicht nur eine Codefrage: Ihr betroffener Prüf- und Dokumentationsumfang wird sichtbar.
- REQ
- BP
- ARCH / SEC
- CAP
- WO
- BDD / MT
- Evidence
Das Ergebnis ansehen
Die Planung führt in ein funktionierendes Produkt.
Sehen Sie sich die Luna-Hotel-Demo live an oder besprechen Sie mit uns, wie ein vergleichbar nachvollziehbarer Prozess für Ihr Produkt aussehen kann.
