1. Ausführliche Zusammenfassung
Diese Fallstudie dokumentiert die Architektur des Internet-Banking-System für Big Bank plc. Das System ist darauf ausgelegt, privaten Bankkunden die Möglichkeit zu geben, ihre Kontostände einzusehen, ihre Transaktionsgeschichte einzusehen und Zahlungen über Webbrowser und mobile Geräte vorzunehmen.
Die Architektur folgt dem C4-Modell (Kontext, Container, Komponenten, Code), wodurch eine hierarchische Sicht auf das System von hochabstrakten Ebenen bis hin zur Bereitstellungsinfrastruktur ermöglicht wird.
2. Ebene 1: System-Kontext-Diagramm
Ziel: Das System im Kontext seiner Benutzer und externer Abhängigkeiten darzustellen.
Referenz-Diagramm: Bild 4 (Primär) und Bild 1 (vereinfachte Ansicht).
Analyse
Das Internet-Banking-System befindet sich innerhalb der Grenzen des Big Bank plc Unternehmen. Es fungiert als digitaler Kanal für die Privatkunden.

-
Benutzer (Aktoren):
-
Privatkunde: Der primäre Benutzer, der mit dem System interagiert, um Kontostände einzusehen und Zahlungen vorzunehmen.
-
Kundenservice-Mitarbeiter: Bankangestellte, die Kunden unterstützen (in Bild 4 dargestellt).
-
Hintergrund-Team: Verwaltungs- und Support-Mitarbeiter (in Bild 4 dargestellt).
-
-
Externe Systeme:
-
Mainframe-Bankensystem: Das System der Aufzeichnung. Es speichert alle zentralen Bankinformationen (Kunden, Konten, Transaktionen). Das Internet-Bankensystem stützt sich darauf, um autoritative Daten zu erhalten.
-
E-Mail-System: Das interne Microsoft Exchange-System, das zur Versendung von Benachrichtigungen (z. B. Passwortzurücksetzungen, Bestätigungen) an Kunden verwendet wird.
-
Geldautomat (ATM): Ein eigenständiges Software-System, das Bargeldabhebungen ermöglicht (in Bild 4 dargestellt, um das umfassendere Ökosystem zu veranschaulichen).
-
Wichtige Beziehung: Der Kunde interagiert mit dem Internet-Bankensystem, das wiederum als Fassade für das veraltete Mainframe-System fungiert, um Daten abzurufen und Zahlungen zu verarbeiten.
3. Ebene 2: Container-Diagramm
Ziel: Anzeigen der technologischen Entscheidungen auf hoher Ebene und der Verteilung der Verantwortlichkeiten innerhalb des Systems.
Referenz-Diagramm: Bild 2.
Analyse
Das „Internet-Bankensystem“ aus Ebene 1 wird in fünf verschiedene Container (bereitstellbare Einheiten) zerlegt.

-
Webanwendung (Java und Spring MVC):
-
Rolle: Dient als Einstiegspunkt für Webnutzer.
-
Funktion: Liefert statische Inhalte (HTML/CSS/JS) und die Einseitenanwendung (SPA) über HTTPS an den Browser des Kunden.
-
-
Einseitenanwendung (JavaScript und Angular):
-
Rolle: Die Client-seitige Logik, die im Browser ausgeführt wird.
-
Funktion: Bietet die vollständige Funktionalität des Internet-Bankings. Es stellt API-Aufrufe an die Backend-Systeme.
-
-
Mobile App (Xamarin):
-
Rolle: Die Client-seitige Anwendung für mobile Geräte.
-
Funktion:Bietet eine eingeschränkte Auswahl an Funktionen im Vergleich zur Webanwendung. Es führt außerdem API-Aufrufe an die Backend-Systeme durch.
-
-
API-Anwendung (Java und Spring MVC):
-
Rolle:Die zentrale Backend-Logik.
-
Funktion:Stellt eine JSON/HTTPS-API bereit. Es verwaltet die Authentifizierung, die Geschäftslogik und die Kommunikation mit externen Systemen (Datenbank, Mainframe, E-Mail).
-
-
Datenbank (Oracle-Datenbank-Schema):
-
Rolle:Datenpersistenz.
-
Funktion:Speichert Benutzerregistrierungsdaten, gehashte Anmeldeinformationen und Zugriffsprotokolle.Hinweis: Die Kernbankdaten verbleiben im Mainframe.
-
Wichtige Beziehung:Sowohl die Webanwendung (über die SPA) als auch die Mobile App kommunizieren mit derAPI-Anwendung. Die API-Anwendung kommuniziert anschließend mit derDatenbankfür lokale Daten und mit demMainframefür die Kernbankdaten.
4. Ebene 3: Komponentendiagramm
Ziel:Ein bestimmtes Container (die API-Anwendung) genauer darzustellen, um seine internen Bausteine zu zeigen.
Referenzdiagramm:Bild 3.
Analyse
Dieses Diagramm zerlegt denAPI-AnwendungContainer in logische Komponenten.

-
Controller (Spring MVC Rest-Controller): Diese verarbeiten eingehende HTTP-Anfragen.
-
Anmelde-Controller: Verarbeitet die Benutzerauthentifizierung.
-
Passwort-Zurücksetzungs-Controller: Verarbeitet den Ablauf zur Passwortwiederherstellung.
-
Kontozusammenfassungs-Controller: Ruft Kontendaten für den Benutzer ab.
-
-
Komponenten (Spring-Beans): Diese enthalten die Geschäftslogik.
-
Sicherheitskomponente: Verarbeitet das Anmelden und Ändern von Passwörtern. Wird vom Anmelde- und Passwort-Zurücksetzungs-Controller verwendet.
-
E-Mail-Komponente: Verarbeitet das Senden von E-Mails. Wird vom Passwort-Zurücksetzungs-Controller verwendet.
-
Facade des Mainframe-Bankensystems: Eine Hülle um das externe Mainframe-System. Sie übersetzt interne API-Aufrufe in das XML/HTTPS-Format, das vom veralteten Mainframe erforderlich ist. Wird vom Kontozusammenfassungs-Controller verwendet.
-
Wichtige Beziehung: Die Kontozusammenfassungs-Controller verwendet die Facade des Mainframe-Bankensystems um Daten aus dem externen Mainframe abzurufen, was die Trennung der Verantwortlichkeiten zwischen der API-Schicht und der Integrations-Schicht demonstriert.
5. Ebene 4: Bereitstellungsdiagramm
Ziel: Anzuzeigen, wie die Software-Container auf die physische Infrastruktur abgebildet werden.
Referenzdiagramm: Bild 5.
Analyse
Dieses Diagramm veranschaulicht die Laufzeitumgebung.

-
Kunden-Seite:
-
Mobilgerät: Führt die Mobile App (iOS/Android) aus.
-
Computer: Führt den Web-Browser (Chrome/Firefox/Safari/Edge) aus, der die Single-Page-Anwendung hostet.
-
-
Big Bank plc Datenzentrum:
-
Web-Server (bigbank-web*):** Ubuntu 16.04 LTS-Knoten, die laufen Apache Tomcat 8.x.
-
Hostet die Web-Anwendung und API-Anwendung.
-
-
Datenbank-Server (bigbank-db01/02): Ubuntu 16.04 LTS-Knoten, die laufen Oracle 12c.
-
Oracle – Primär: Die Hauptdatenbank.
-
Oracle – Sekundär: Eine Replikation für Redundanz/höhere Verfügbarkeit.
-
-
Wichtige Beziehung: Die Mobile App und der Web-Browser verbinden sich über das Internet mit der API-Anwendung auf Tomcat gehostet. Die API-Anwendung verbindet sich über JDBC mit dem Oracle-Datenbank-Cluster.
6. Wichtige Konzepte und Richtlinien angewendet
Basierend auf dieser Fallstudie wurden die folgenden C4-Modellierungsprinzipien angewendet:
-
Abstraktionsstufen: Das Modell bewegt sich erfolgreich von „Wer nutzt es?“ (Kontext) zu „Woraus ist es aufgebaut?“ (Container) zu „Wie ist es organisiert?“ (Komponenten) zu „Wo läuft es?“ (Bereitstellung).
-
Grenzen des Umfangs:
-
Auf Ebene 1 unterscheidet die „Big Bank plc“-Grenze die internen Systeme eindeutig von externen Akteuren.
-
Auf Ebene 2 umschließt die Grenze des „Internet Banking Systems“ die spezifische Software, die entwickelt wird, und trennt sie vom veralteten Mainframe.
-
-
Trennung der Anliegen:
-
Frontend vs. Backend:Die Trennung der Single-Page-Anwendung (Frontend) von der API-Anwendung (Backend) ermöglicht eine unabhängige Entwicklung und Skalierung.
-
Daten-Trennung:Vertrauliche Kernbankdaten werden im Mainframe gespeichert, während das Internet-Banking-System nur notwendige Benutzerzugangsdaten in seiner eigenen Oracle-Datenbank zwischenspeichert.
-
-
Technologieunabhängigkeit (wo angebracht):Die Diagramme legen Technologien (Java, Angular, Oracle) fest, wo sie für die Architekturentscheidung relevant sind, konzentrieren sich jedoch vor allem auf die Beziehungenund Verantwortlichkeitender Blöcke.
-
Notation:Standard-C4-Notation wird verwendet:
-
Person:Stabfiguren (oder Kreise in diesem spezifischen Darstellungsstil).
-
Software-System/Container/Komponente:Abgerundete Rechtecke mit unterschiedlichen Farben (Blau für intern/primär, Grau für extern/sekundär).
-
Beziehungen:Punktierte Pfeile mit Beschriftungen, die das Protokoll beschreiben (z. B. [HTTPS], [JSON], [JDBC]).
-










