Verteilungssicht
Eine Verteilungssicht ordnet Softwarebausteine konkreten Laufzeitumgebungen und Infrastrukturressourcen zu. Netzwerk- und Betriebsgrenzen werden dadurch sichtbar.
- KnotenWo das Artefakt läuft.
- DatenspeicherGemeinsamer Zustand.
- SystemgrenzeExternes liegt außerhalb.
Einordnung
Warum das wichtig ist
Ob ein Ausfall oder Release Kunden trifft, hängt davon ab, wo Software läuft und was sie teilt. Die Verteilungssicht ordnet Bausteine Knoten, Datenspeichern und externen Diensten zu. Der Ablauf eines Rollouts hat einen eigenen Baustein.
Dieser Baustein beschreibt Laufzeitzuordnung. C4 ordnet System- und Softwareebenen; Deployment & Rollout behandelt den kontrollierten Versionswechsel.
Auf einen Blick · Bausteine auf Knoten verteilt
Verteilung des modularen Shops
Der modulare Shop läuft als Anwendung auf zwei Instanzen und nutzt eine verwaltete Datenbank. Die Zahlungsanbindung führt zu einem externen Anbieter.
So liest du das Bild
- Knoten Kästen „Shop-Instanz A“ und „Shop-Instanz B“ mit gleicher Version und Konfiguration.
- Datenspeicher Kasten „Shop-Datenbank“, die beide Instanzen für Bestellungen nutzen.
- Systemgrenze Kasten „Zahlungsanbieter“ im Bereich „Extern“, angebunden über „Zahlung autorisieren“.
Breites Diagramm · bei Bedarf seitlich verschieben
Diagramm als Text lesen
- Browser: Kundenanfragen (Extern)
- Shop-Instanz A: Monolithisches Artefakt mit Bestell-, Zahlungs- und Versandmodulen (Shop-Umgebung)
- Shop-Instanz B: Gleiche Version und Konfiguration (Shop-Umgebung)
- Shop-Datenbank: Bestellungen und Zahlungskennungen (Shop-Umgebung)
- Zahlungsanbieter: Autorisierung und Statusabfrage (Extern)
- Browser → Shop-Instanz A: HTTPS-Anfrage
- Browser → Shop-Instanz B: HTTPS-Anfrage
- Shop-Instanz A → Shop-Datenbank: Bestellung speichern
- Shop-Instanz B → Shop-Datenbank: Bestellung lesen und ändern
- Shop-Instanz A → Zahlungsanbieter: Zahlung autorisieren
- Shop-Instanz B → Zahlungsanbieter: Zahlungsstatus abfragen
Nutzen & Grenzen
Hilft, wenn
- Betriebsübergaben und Netzfreigaben profitieren von einer gemeinsamen Sicht auf Knoten und Kommunikationswege.
- Verfügbarkeits- und Wiederanlaufplanung braucht reale Fehlerdomänen und Replikatverteilung.
Grenzen
- Zwei Instanzen in derselben Zone bieten begrenzte Unabhängigkeit; Zonen, gemeinsame Speicher und Plattformdienste mitprüfen.
- Eine statische Sicht altert mit der Infrastruktur; sie wird regelmäßig gegen die aktive Konfiguration abgeglichen.
- Sie zeigt den Ort, nicht den Ablauf des Rollouts; Struktur zeigt C4, Wiederanlauf behandelt Recovery.
In der Praxis
- Umgebung und Version ausweisen. Benenne die betrachtete Umgebung, den Geltungsbereich und den geprüften Stand. Trenne Sollzustand von tatsächlich laufender Topologie. Das Ergebnis verhindert, dass Leser Entwicklungs- und Produktionsannahmen vermischen.
- Knoten und Verbindungen darstellen. Ordne Anwendungen, Speicher, Gateways und Dienste konkreten Laufzeitorten zu. Beschrifte Kommunikationsrichtung und relevante Protokolle. Damit werden Netzwege und Abhängigkeiten nachvollziehbar.
- Fehlerdomänen und Redundanz prüfen. Markiere gemeinsam genutzte Komponenten und bewerte, welche Ausfälle die Instanzen gleichzeitig betreffen. Vergleiche die Darstellung mit Wiederanlaufannahmen. Das Ergebnis zeigt, wo echte Redundanz besteht und wo ein Engpass verbleibt.
Ausführliche Erklärung lesen
Eine Verteilungssicht zeigt, auf welchen Knoten Software und Datenspeicher laufen und wie sie miteinander kommunizieren. Sie ergänzt Strukturdiagramme wie das C4-Modell um konkrete Laufzeitumgebungen, Verbindungen, Replikate und Infrastrukturdienste. Gemeinsame Ausfallbereiche können so zusammen mit Anforderungen an Wiederherstellung betrachtet werden.
Geltungsbereich, Umgebung und Stand müssen erkennbar sein. Zwei Instanzen sind umso unabhängiger, je weniger kritische Knoten und Dienste sie gemeinsam nutzen. Netzprotokolle und Verantwortlichkeiten unterstützen Betriebsübergabe und Prüfung. Der Abgleich mit der tatsächlichen Deploymentkonfiguration hält die Sicht belastbar und zeigt die laufende Topologie samt Abweichungen vom Soll. Die Redundanzbewertung berücksichtigt neben räumlicher Trennung auch gemeinsame Daten- und Plattformdienste. Der dargestellte Stand muss Betrieb und Architektur dieselbe Lage vermitteln. Logische Softwareverteilung und physische Infrastruktur können getrennte Sichten erhalten; eine nachvollziehbare Zuordnung verbindet beide Ebenen.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wie viele Instanzen des Shops zeigt die Sicht, und was nutzen sie gemeinsam?
Lösung mit Begründung ansehen
Zwei Instanzen, A und B. Beide greifen auf dieselbe Shop-Datenbank zu.
AnwendenAuf eine neue Lage übertragen
Der Shop bekommt eine dritte Instanz. Was ändert sich in der Sicht, was nicht?
Lösung mit Begründung ansehen
Es kommt ein weiterer Knoten mit gleichem Artefakt hinzu; der Browser erreicht ihn per HTTPS-Anfrage, und seine Kanten führen zur Shop-Datenbank und zum Zahlungsanbieter. Die Systemgrenze und der externe Anbieter bleiben unverändert.
BewertenEine Alternative abwägen
Zwei Instanzen statt einer: Was gewinnt man, was kostet es?
Lösung mit Begründung ansehen
Mit zwei Instanzen kann eine ersetzt werden, während die andere Bestellungen verarbeitet. Dafür müssen beide kompatibel zur gemeinsamen Datenbank sein, und der Betrieb wird aufwendiger.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- C4 – Deployment diagram (öffnet in neuem Tab)Ordnet Softwareinstanzen der Infrastruktur einer konkreten Umgebung zu.
- arc42 – Deployment View (öffnet in neuem Tab)Erklärt Infrastrukturknoten und die Zuordnung von Softwarebausteinen.
- PlantUML – Deployment diagrams (öffnet in neuem Tab)Zeigt eine textuelle Notation für Knoten, Artefakte und Verbindungen.