Welcher Akteur meldet laut Darstellung den Bestand an den Shop?

Das Lagerteam. Die Kante „Bestand pflegen“ führt vom Lagerteam zum Shop; das Lagerteam steht in der Zone Extern.

Der Shop soll künftig Bestellbestätigungen über einen externen Mailanbieter versenden. Was ändert sich im Systemkontext?

Der Mailanbieter käme als weiterer externer Knoten mit einer Kante vom Shop hinzu. Die internen Module bleiben unsichtbar, weil nur die Außenbeziehung zählt.

Das Team will die sieben Module zusätzlich im Systemkontext zeigen. Welchen Nachteil hat das?

Der Vorteil ist mehr Detail. Der Nachteil: Die Grenze zwischen innen und außen verschwimmt, und das Bild beantwortet nicht mehr die Frage, mit wem der Shop spricht. Interne Module gehören in eine eigene Sicht.

KonzeptKapitel I · Grundlagen · Baustein 2 von 7

Systemkontext & Systemgrenze

Ein Systemkontext zeigt das betrachtete System als eine Einheit und benennt seine externen Akteure. Interne Bausteine bleiben auf dieser Ebene verborgen.

Von Michael Meierhoff · Meierhoff Systems

SystemEine Einheit, deren Inneres verborgen bleibt.
AkteurePersonen und Systeme außerhalb der Grenze.
BeziehungenWas zwischen Shop und Außenwelt fließt.

Einordnung

Warum das wichtig ist

Ohne Systemgrenze bleibt unklar, wofür der Shop selbst einsteht und wo Abhängigkeiten zu anderen beginnen. Dann werden Schnittstellen zu Zahlungsanbieter oder Transportpartner übersehen. Die interne Aufteilung zeigen andere Bausteine.

Dieser Baustein erklärt Außenbeziehungen und Systemgrenze. Für interne Module siehe Softwarearchitektur und Modulgrenzen.

Auf einen Blick · System als Black Box im Umfeld

Das System steht als Black Box in der Mitte; Nutzer und externe Systeme sind über ihre Interaktionen verbunden.

Shop-Beispiel · Bausteine und Beziehungen

Systemkontext des Shops

Der Shop nimmt Bestellungen von Kunden an und tauscht Informationen mit Zahlungsanbieter, Versanddienstleister und Lagerteam aus. Das interne Versandmodul bereitet Lieferungen vor; der externe Transportpartner befördert sie. Ebenso pflegt das Lagerteam den Bestand von außen, während das Lagermodul im Shop die Reservierungen verwaltet. Alle internen Shop-Module liegen innerhalb einer einzigen Systemgrenze.

So liest du das Bild

System Der Kasten Shop im Bereich System – ohne interne Module.
Akteure Die Kästen Kunde, Zahlungsanbieter, Versanddienstleister und Lagerteam im Bereich Extern.
Beziehungen Die Pfeilbeschriftungen bestellt, Zahlung anfragen, Sendung anmelden und Bestand pflegen.

Der Shop erscheint als ein System; ausschließlich externe Akteure stehen außerhalb seiner Grenze.

Nutzen & Grenzen

Hilft, wenn

Ein neues Vorhaben braucht eine gemeinsame Abgrenzung von Lieferumfang und externen Abhängigkeiten.
Beteiligte verwenden denselben Systemnamen für unterschiedliche Verantwortungsbereiche und müssen den Geltungsbereich klären.

Grenzen

Der Systemkontext zeigt nicht, wie der Shop innen aufgeteilt ist; dafür braucht es eine Architektursicht mit Bausteinen.
Ein Pfeil zum Zahlungsanbieter belegt weder Erreichbarkeit noch Datenformat; die Zusagen stehen im API-Vertrag.
Die Grenze hängt vom Betrachtungsgegenstand ab: Was für den Shop extern ist, liegt für den Anbieter im eigenen System.

In der Praxis

System und Zweck abgrenzen. Formuliere, welche fachliche Leistung betrachtet wird und welche Aufgaben innerhalb der Verantwortung liegen. Das Ergebnis ist ein eindeutiger Bezugsrahmen für die Umgebungssicht.
Akteure und externe Partner bestimmen. Erfasse Rollen und Systeme, die Eingaben liefern, Ergebnisse nutzen oder den Ablauf beeinflussen. Trenne sie von internen Bausteinen; Architektursichten können deren interne Struktur anschließend erklären.
Austauschrichtungen beschriften. Benenne für jede Beziehung Auslöser, fachlichen Inhalt und Rückmeldung. Verweise technische Zusagen auf den API-Vertrag, damit die Kontextkarte nicht Protokolldetails mit fachlicher Verantwortung vermischt.

Ausführliche Erklärung lesen

Die Kontextsicht benennt den betrachteten Gegenstand, seine Nutzer und die externen Systeme, mit denen es fachlich zusammenarbeitet. Ihre Grenze fasst die eigene Verantwortung zusammen. Alles außerhalb kann für einen Geschäftsablauf wichtig sein, bleibt aber unter einer anderen Zuständigkeit.

Beziehungen werden über Richtung und fachlichen Zweck verständlich: Wer fordert welche Fähigkeit an, wer liefert Informationen und welches Ergebnis wird zurückgegeben? Die interne Zerlegung wird in einer eigenen Architektursicht beschrieben. Für innere Zuständigkeiten dienen Modulgrenzen; die fachliche Bedeutung verschiedener Modelle klärt Bounded Context.

Das C4-Kontextdiagramm von Simon Brown ist eine verbreitete Form dieser Sicht: ein System in der Mitte, umgeben von Nutzern und Nachbarsystemen.

Selbst prüfen

Teste dich in drei Stufen

AblesenIm Bild nachsehen
Welcher Akteur meldet laut Darstellung den Bestand an den Shop?
Lösung mit Begründung ansehen
Das Lagerteam. Die Kante „Bestand pflegen“ führt vom Lagerteam zum Shop; das Lagerteam steht in der Zone Extern.
AnwendenAuf eine neue Lage übertragen
Der Shop soll künftig Bestellbestätigungen über einen externen Mailanbieter versenden. Was ändert sich im Systemkontext?
Lösung mit Begründung ansehen
Der Mailanbieter käme als weiterer externer Knoten mit einer Kante vom Shop hinzu. Die internen Module bleiben unsichtbar, weil nur die Außenbeziehung zählt.
BewertenEine Alternative abwägen
Das Team will die sieben Module zusätzlich im Systemkontext zeigen. Welchen Nachteil hat das?
Lösung mit Begründung ansehen
Der Vorteil ist mehr Detail. Der Nachteil: Die Grenze zwischen innen und außen verschwimmt, und das Bild beantwortet nicht mehr die Frage, mit wem der Shop spricht. Interne Module gehören in eine eigene Sicht.

Vertiefen

Diese Bausteine führen die Gedanken dieser Seite weiter.

Quellen

Weiter im Lernpfad

Als Nächstes in Grundlagen & Orientierung: Architekturtreiber.

7 Bausteine

Weiter mitArchitekturtreiber