Posted inAI AI Chatbot C4 Model

Studium przypadku modelu C4: System bankowości internetowej Big Bank plc

1. Podsumowanie wykonawcze

To studium przypadku dokumentuje architekturę systemu System bankowości internetowej dla Big Bank plc. System został zaprojektowany w taki sposób, aby klienci indywidualni mogli przeglądać salda kont, historię transakcji oraz dokonywać płatności za pomocą przeglądarek internetowych i urządzeń mobilnych.

Architektura opiera się na modelu C4 (Kontekst, Kontenery, Komponenty, Kod), zapewniając hierarchiczny widok systemu od abstrakcji najwyższego poziomu aż po infrastrukturę wdrażania.

2. Poziom 1: Diagram kontekstu systemu

Cel: Pokaż system w kontekście jego użytkowników i zależności zewnętrznych.

Diagram odniesienia: Obraz 4 (główny) i Obraz 1 (uproszczony widok).

Analiza

System System bankowości internetowej znajduje się w granicach Big Bank plc przedsiębiorstwa. Działa jako kanał cyfrowy dla klienta bankowości indywidualnej.

C4 Model System Context Diagram for Internet Banking System

  • Użytkownicy (aktorzy):

    • Klient bankowości indywidualnej: Główny użytkownik, który interakcje z systemem w celu przeglądania sald i dokonywania płatności.

    • Personel obsługi klienta: Pracownicy banku, którzy pomagają klientom (pokazani na Obrazie 4).

    • Personel biura tylnej: Personel administracyjny i wsparcia (pokazany na Obrazie 4).

  • Systemy zewnętrzne:

    • System bankowy mainframe: System źródłowy. Przechowuje wszystkie podstawowe informacje bankowe (klienci, konta, transakcje). System Internet Banking opiera się na nim w celu uzyskania wiarygodnych danych.

    • System poczty e-mail: Wewnętrzny system Microsoft Exchange używany do wysyłania powiadomień (np. resetowanie haseł, potwierdzenia) do klientów.

    • Bankomat: Oddzielny system oprogramowania umożliwiający wypłaty gotówki (pokazany na Rysunku 4, aby przedstawić szerszy ekosystem).

Kluczowe relacje: Klient interakcjonuje z Systemem Internet Banking, który z kolei działa jako fasada dla starszego systemu mainframe w celu pobierania danych i przetwarzania płatności.

3. Poziom 2: Diagram kontenerów

Cel: Pokaż wyższe poziomy wyborów technologicznych oraz sposób dystrybucji odpowiedzialności w obrębie systemu.

Diagram odniesienia: Rysunek 2.

Analiza

System Internet Banking” z poziomu 1 jest rozłożony na pięć różnych kontenerów (jednostek wdrażalnych).

C4 Model Container Diagram for Internet Banking System

  1. Aplikacja internetowa (Java i Spring MVC):

    • Rola: Służy jako punkt wejścia dla użytkowników internetowych.

    • Funkcja: Dostarcza zawartość statyczną (HTML/CSS/JS) oraz aplikację jednostronicową (SPA) do przeglądarki klienta przez HTTPS.

  2. Aplikacja jednostronicowa (JavaScript i Angular):

    • Rola: Logika po stronie klienta działająca w przeglądarce.

    • Funkcja: Dostarcza pełny zestaw funkcji bankowości internetowej. Wykonuje wywołania interfejsu API do serwera backendowego.

  3. Aplikacja mobilna (Xamarin):

    • Rola: Aplikacja po stronie klienta dla urządzeń mobilnych.

    • Funkcja:Dostarcza ograniczony zestaw funkcji w porównaniu do aplikacji internetowej. Również wykonywane są wywołania interfejsu API do zaplecza.

  4. Aplikacja API (Java i Spring MVC):

    • Rola: Główna logika zaplecza.

    • Funkcja: Dostarcza interfejs API w formacie JSON/HTTPS. Obsługuje uwierzytelnianie, logikę biznesową oraz komunikację z systemami zewnętrznymi (Baza danych, Mainframe, Email).

  5. Baza danych (schemat Oracle):

    • Rola: Trwałe przechowywanie danych.

    • Funkcja: Przechowuje informacje o rejestracji użytkownika, hashowane dane logowania oraz dzienniki dostępu.Uwaga: Podstawowe dane bankowe pozostają w systemie Mainframe.

Kluczowa relacja: Obie aplikacje — Web App (poprzez SPA) i aplikacja mobilna — komunikują się z Aplikację API. Następnie aplikacja API komunikuje się z Bazą danych w celu danych lokalnych oraz z Mainframe w celu danych podstawowych bankowych.

4. Poziom 3: Diagram komponentów

Cel: Zamierza przybliżyć konkretny kontener (Aplikację API), aby pokazać jego wewnętrzne elementy budowlane.

Diagram odniesienia: Obrazek 3.

Analiza

Ten diagram rozkłada Aplikację API na kontener logicznych komponentów.

C4 Model Component Diagram for Internet Banking System

  • Kontrolery (Spring MVC Rest Controllers): Obsługują przychodzące żądania HTTP.

    • Kontroler logowania: Obsługuje uwierzytelnianie użytkownika.

    • Kontroler resetowania hasła: Obsługuje przepływy odzyskiwania hasła.

    • Kontroler podsumowania kont: Pobiera dane konta dla użytkownika.

  • Składniki (Spring Beans): Zawierają logikę biznesową.

    • Składnik zabezpieczeń: Obsługuje logowanie i zmianę haseł. Używany przez kontrolery logowania i resetowania hasła.

    • Składnik e-mail: Obsługuje wysyłanie e-maili. Używany przez kontroler resetowania hasła.

    • Facade systemu bankowego Mainframe: Odpowiednik zewnętrznego systemu Mainframe. Przekształca wywołania interfejsu API wewnętrznych na format XML/HTTPS wymagany przez starszy system Mainframe. Używany przez kontroler podsumowania kont.

Kluczowa relacja: Poniższa Kontroler podsumowania kont korzysta z Facade systemu bankowego Mainframe w celu pobrania danych z zewnętrznego systemu Mainframe, co pokazuje rozdzielenie odpowiedzialności między warstwą interfejsu API a warstwą integracji.

5. Poziom 4: Diagram wdrożenia

Cel: Pokaż, jak kontenery oprogramowania są mapowane na infrastrukturę fizyczną.

Diagram odniesienia: Obraz 5.

Analiza

Ten diagram ilustruje środowisko uruchomieniowe.

C4 Model Deployment Diagram for Internet Banking System

  • Strona klienta:

    • Urządzenie mobilne:Uruchamia aplikację mobilną (iOS/Android).

    • Komputer:Uruchamia przeglądarkę internetową (Chrome/Firefox/Safari/Edge), która hostuje aplikację jednostronicową.

  • Centrum danych Big Bank plc:

    • Serwery internetowe (bigbank-web*):** węzły Ubuntu 16.04 LTS działająceApache Tomcat 8.x.

      • HostujeAplikację internetowąorazaplikacją API.

    • Serwery baz danych (bigbank-db01/02):węzły Ubuntu 16.04 LTS działająceOracle 12c.

      • Oracle – podstawowy:Główna baza danych.

      • Oracle – pomocniczy:Kopia zapasowa zapewniająca odporność/wysoką dostępność.

Kluczowe relacje:Aplikacja mobilna i przeglądarka internetowa łączą się przez internet zaplikacją APIhostowaną na Tomcat. Aplikacja API łączy się przez JDBC z klastrem bazy danych Oracle.

6. Kluczowe koncepcje i zasady stosowane

Na podstawie tego przypadku badawczego zastosowano następujące zasady modelowania C4:

  1. Poziomy abstrakcji:Model pomyślnie przechodzi od „Kto go używa?” (kontekst) do „Z czego się składa?” (kontenery) do „Jak jest zorganizowany?” (komponenty) do „Gdzie działa?” (wdrożenie).

  2. Granice zakresu:

    • Na poziomie 1 granica „Big Bank plc” jasno rozdziela systemy wewnętrzne od aktorów zewnętrznych.

    • Na poziomie 2 granica „System Internetowy Bankowy” hermetyzuje konkretny oprogramowanie tworzone, oddzielając je od starszego systemu Mainframe.

  3. Oddzielenie odpowiedzialności:

    • Frontend vs. Backend:Oddzielenie aplikacji jednostronicowej (frontend) od aplikacji API (backend) pozwala na niezależną rozwój i skalowanie.

    • Oddzielenie danych:Wrażliwe dane bazowe bankowe przechowywane są w systemie Mainframe, podczas gdy System Internetowy Bankowy przechowuje tylko dane potrzebne do dostępu użytkownika w swojej własnej bazie danych Oracle.

  4. Neutralność technologiczna (gdy to odpowiednie):Diagramy określają technologie (Java, Angular, Oracle), gdy są one istotne dla decyzji architektonicznej, ale skupiają się przede wszystkim na relacjachi odpowiedzialnościachbloków.

  5. Oznaczenia:Używana jest standardowa notacja C4:

    • Osoba:Postacie z drutu (lub koła w tej konkretnej stylizacji renderowania).

    • System oprogramowania/Container/Element:Okrągłe prostokąty o różnych kolorach (niebieski dla wewnętrznego/pierwotnego, szary dla zewnętrznego/sekundarnego).

    • Związki:Przerywane strzałki z etykietami opisującymi protokół (np. [HTTPS], [JSON], [JDBC]).