Was vorher fertig sein muss
Stakeholder mit ihren Architektur-Anforderungen sind identifiziert, sodass Views auf konkrete Konsumenten zugeschnitten werden koennen.
Top Quality Attributes mit Szenarien liegen vor, sodass Views die richtigen Aspekte (Modul, Komponente, Allocation, Behavior) priorisieren.
Was vor Start vorliegen muss
Whiteboard oder Modellierungstool; View-Templates pro Viewtype (Module, Component and Connector, Allocation); Cross-View-Beyond-Vorlage; Glossar; ADR-Repository.
Ein Architekt mit V-and-B-Erfahrung; Engineering Leads pro Subsystem; ein Reviewer aus Operations; Stakeholder-Vertreter fuer Validierung; Scribe.
Stakeholder-Anforderungen pro Gruppe; bestehende Architektur-Artefakte; QA-Szenarien; Komponentenliste aus dem Canvas; Sprachkonventionen (Glossar).
2-3 Tage initial, danach gepflegtes lebendes Dokument
Viewpoint-Bibliothek auswaehlen (z. B. SEI Software Architecture in Practice). Pro Viewpoint Template anlegen. Naming-Konvention fuer Views festlegen.
Die eine Frage, die diese Methode beantwortet
Welche Views adressieren welche Stakeholder mit welchem Quality-Anliegen, und welche Cross-View-Information bindet sie zu einem konsistenten Bild?
Marker: Sektion
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Sektion 1: Viewpoint-Auswahl | 60 min | Aus dem Set (Module, Component-and-Connector, Allocation, Deployment, Behavior) die fuer Stakeholder und QA noetigen Viewpoints auswaehlen. Pro Viewpoint Zielgruppe und Zweck dokumentieren. | Nicht alle Viewpoints sind Pflicht. Mindestens Module, Component-and-Connector, Deployment. Weitere bei Bedarf. |
2Sektion 2: Module View | 2-3 h | Strukturelle Code-Organisation: Module, Layers, Subsysteme. Abhaengigkeiten zwischen Modulen. Modulverantwortung. | Module View zeigt statische Struktur, nicht Runtime. Wenn Diskussion in Runtime-Verhalten kippt, gehoert das in C-and-C-View. |
3Sektion 3: Component-and-Connector View | 3-4 h | Runtime-Komponenten und ihre Konnektoren (REST, Kafka, Filesystem). Datenfluesse, Protokolle, QoS-Eigenschaften. | Wichtigster View fuer Performance- und Availability-Szenarien. Hier zeigen sich Engpaesse. |
4Sektion 4: Allocation Views | 2-3 h | Deployment (Mapping auf Infrastruktur, Cloud-Regionen, Container), Work Assignment (Mapping auf Teams), Implementation (Mapping auf Repos). | Deployment-View kritisch fuer Operations und SRE. Work Assignment hilft bei Team Topology-Diskussionen. |
5Sektion 5: Behavior und Beyond | 2-3 h | Bei Bedarf Behavior Views (Sequence, State, Activity) fuer kritische Workflows. Beyond-Sektion: Glossar, Architecture Drivers, Quality Attribute Scenarios, ADR-Liste, Variabilitaet, Mapping zwischen Views. | Cross-View-Beyond ist das Bindeglied. Ohne diese Sektion bleiben Views isoliert und widerspruechlich. |
6Sektion 6: Review und Pflege | fortlaufend | Reviews mit Stakeholder pro View. Versionierung. Aenderungs-Pipeline: ADR-Anstoss -> betroffene Views aktualisieren -> Re-Review. | Architekturdoku ohne Pflege veraltet schnell. Quartalsweise oder release-getriggerte Review-Cadence festlegen. |
Was am Ende rauskommt
Architekturdokumentation mit mehreren Views (Module, Component-and-Connector, Allocation, ggf. Behavior), Cross-View-Beyond-Sektion mit Glossar, Drivers, QA-Szenarien, ADR-Referenzen und View-Mappings. Pro View Diagramm plus Begleittext.
Architekturdoku im Git oder Wiki versioniert. Pro View Aenderungsdatum und Autor. Beyond-Sektion verlinkt ADRs. Quartals-Review-Eintrag mit Reviewern und Outcome.
Kompakte Arbeitsvorlage für Views and Beyond mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Views and Beyond Arbeitsvorlage
## Ziel
Dokumentiert Architektur über stakeholderrelevante Views plus Cross-view-Information.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Architecture Views:
- Cross-view Notes:
- Rationale:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Architekturdokumentation - Workspot Booking API v2 (Views and Beyond)
**Gewaehlte Viewpoints**
- Module View (Engineering)
- Component-and-Connector View (Architekten, Performance-Reviewer)
- Deployment View (Operations, SRE)
- Behavior View Buchungsflow (QA, Product)
**Module View (Auszug)**
Layer Domain Model -> Layer Application Service -> Layer Adapters. Subsystem `booking-core` enthaelt Module Booking, Inventory, Pricing. Abhaengigkeit gerichtet von Adapters zu Domain.
**C-and-C View (Auszug)**
- Komponente `booking-api` (Spring Boot) mit Konnektoren REST (HTTPS, JSON) zu Partner-Clients und gRPC zu internal-graphql.
- Komponente `notification-worker` konsumiert Kafka topic `bookings.events`.
- Cache `availability-cache` (Redis) mit TTL 60 s.
**Deployment View (Auszug)**
- AWS eu-central-1 (primary): ECS Fargate 8 Tasks, RDS Postgres 14 Multi-AZ.
- eu-west-1 (DR): Read-Replicas + warm standby ECS.
- Kafka MSK Cluster cross-region.
**Behavior View Buchungsflow**
Sequence: Client -> Partner Gateway -> Booking API -> Inventory Service -> Booking API -> Cache Update -> Notification Worker.
**Beyond-Sektion**
- Glossar (Buchung, Reservierung, Workspace, Owner, Partner).
- Architecture Drivers: QAS-01 Performance, QAS-02 Availability (siehe QAW).
- ADRs: ADR-014 bis ADR-018.
- Cross-View-Mapping: Komponente `booking-api` aus C-and-C View entspricht Modul `booking-core` aus Module View und Service `booking-api-task` aus Deployment View.
- Review-Cadence: quartalsweise plus bei jedem Major Release.Symptome erkennen, gegensteuern
Doku enthaelt nur Komponentendiagramme, Deployment und Module fehlen.
Mindestens drei View-Typen pflicht. Stakeholder-spezifische Beduerfnisse adressieren. Wenn Operations keine Deployment-Sicht hat, ist die Doku unvollstaendig.
Module View zeigt andere Subsysteme als C-and-C View, niemand merkt es.
Cross-View-Mapping in Beyond-Sektion. Pro Element Verweis auf alle Views, in denen es auftaucht. Inkonsistenzen werden sichtbar.
Diagramme stimmen nicht mehr, neue Komponenten fehlen.
Review-Cadence pflicht. Bei jedem Major Release Re-Review. Diagramme als Code (PlantUML, Mermaid) erleichtern Aktualisierung.
Views existieren isoliert, Begruendung und Bezug fehlt.
Beyond-Sektion zwingend. Glossar, Drivers, ADR-Verweise, View-Mappings. Verbindet Views zu konsistenter Doku.
Views enthalten jede Methode, jede Tabelle, niemand liest sie.
Architekturdoku ist Big Picture, kein Codespiegel. Detail in Codebase oder API-Docs. Views auf Strategic Level halten.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.