Posted inAI AI Chatbot C4 Model

Étude de cas du modèle C4 : système de banque en ligne de Big Bank plc

1. Résumé exécutif

Cette étude de cas documente l’architecture du système desystème de banque en lignepourBig Bank plc. Le système est conçu pour permettre aux clients particuliers de consulter leurs soldes de compte, d’accéder à leur historique des transactions et de réaliser des paiements via des navigateurs web et des appareils mobiles.

L’architecture suit le modèlemodèle C4 (Contexte, Conteneurs, Composants, Code), offrant une vue hiérarchique du système, des abstractions de haut niveau jusqu’à l’infrastructure de déploiement.

2. Niveau 1 : Diagramme de contexte du système

Objectif : Montrer le système dans son contexte d’utilisation par les utilisateurs et ses dépendances externes.

Diagramme de référence : Image 4 (principale) et Image 1 (vue simplifiée).

Analyse

Lesystème de banque en ligne se situe à l’intérieur de la frontière de l’Big Bank plc entreprise. Il agit comme un canal numérique pour leclient de banque personnelle.

C4 Model System Context Diagram for Internet Banking System

  • Utilisateurs (acteurs) :

    • Client de banque personnelle : L’utilisateur principal qui interagit avec le système pour consulter les soldes et effectuer des paiements.

    • Personnel de service à la clientèle : Les employés de la banque qui aident les clients (représentés sur l’image 4).

    • Personnel de back-office : Le personnel administratif et de support (représenté sur l’image 4).

  • Systèmes externes :

    • Système bancaire principal (mainframe) : Le système de référence. Il stocke toutes les informations essentielles de la banque (clients, comptes, transactions). Le système de banque en ligne s’appuie sur celui-ci pour obtenir des données fiables.

    • Système de messagerie : Le système interne Microsoft Exchange utilisé pour envoyer des notifications (par exemple, réinitialisations de mot de passe, confirmations) aux clients.

    • Distributeur automatique de billets (ATM) : Un système logiciel distinct permettant les retraits en espèces (présenté dans l’Image 4 pour illustrer l’écosystème plus large).

Relation clé : Le client interagit avec le système de banque en ligne, qui agit à son tour comme une façade vers le système principal hérité pour récupérer des données et traiter les paiements.

3. Niveau 2 : Diagramme des conteneurs

Objectif : Montrer les choix technologiques de haut niveau et la répartition des responsabilités à travers le système.

Diagramme de référence : Image 2.

Analyse

Le « système de banque en ligne » du niveau 1 est décomposé en cinq conteneurs distincts (unités déployables).

C4 Model Container Diagram for Internet Banking System

  1. Application web (Java et Spring MVC) :

    • Rôle : Fonctionne comme point d’entrée pour les utilisateurs web.

    • Fonction : Fournit le contenu statique (HTML/CSS/JS) et l’application monopage (SPA) au navigateur du client via HTTPS.

  2. Application monopage (JavaScript et Angular) :

    • Rôle : La logique côté client s’exécutant dans le navigateur.

    • Fonction : Fournit l’ensemble complet des fonctionnalités de la banque en ligne. Elle effectue des appels d’API vers le serveur backend.

  3. Application mobile (Xamarin) :

    • Rôle : L’application côté client pour les appareils mobiles.

    • Fonction :Fournit un sous-ensemble limité de fonctionnalités par rapport à l’application web. Elle effectue également des appels d’API vers le backend.

  4. Application API (Java et Spring MVC) :

    • Rôle :La logique centrale du backend.

    • Fonction :Expose une API JSON/HTTPS. Elle gère l’authentification, la logique métier et la communication avec les systèmes externes (Base de données, Mainframe, Email).

  5. Base de données (schéma Oracle) :

    • Rôle :Persistence des données.

    • Fonction :Stocke les informations d’inscription utilisateur, les identifiants hachés et les journaux d’accès.Remarque : les données principales de banque restent sur le Mainframe.

Relation clé :À la fois l’application web (via le SPA) et l’application mobile communiquent avec leApplication API. L’application API communique ensuite avec leBase de données pour les données locales et leMainframe pour les données principales de banque.

4. Niveau 3 : Diagramme de composants

Objectif :Zoomer sur un conteneur spécifique (l’application API) pour montrer ses blocs de construction internes.

Diagramme de référence :Image 3.

Analyse

Ce diagramme décompose leApplication API pour le diviser en composants logiques.

C4 Model Component Diagram for Internet Banking System

  • Contrôleurs (contrôleurs REST Spring MVC) : Ils gèrent les requêtes HTTP entrantes.

    • Contrôleur de connexion : Gère l’authentification des utilisateurs.

    • Contrôleur de réinitialisation du mot de passe : Gère les flux de récupération du mot de passe.

    • Contrôleur de synthèse des comptes : Récupère les données du compte de l’utilisateur.

  • Composants (Spring Beans) : Ils contiennent la logique métier.

    • Composant de sécurité : Gère la connexion et le changement de mot de passe. Utilisé par les contrôleurs de connexion et de réinitialisation du mot de passe.

    • Composant e-mail : Gère l’envoi des e-mails. Utilisé par le contrôleur de réinitialisation du mot de passe.

    • Facade du système bancaire Mainframe : Un wrapper autour du système Mainframe externe. Il traduit les appels d’API internes au format XML/HTTPS requis par le Mainframe hérité. Utilisé par le contrôleur de synthèse des comptes.

Relation clé : Le Contrôleur de synthèse des comptes utilise le Facade du système bancaire Mainframe pour obtenir des données du Mainframe externe, démontrant la séparation des préoccupations entre la couche API et la couche d’intégration.

5. Niveau 4 : Diagramme de déploiement

Objectif : Montrer comment les conteneurs logiciels sont mappés sur l’infrastructure physique.

Diagramme de référence : Image 5.

Analyse

Ce diagramme illustre l’environnement d’exécution.

C4 Model Deployment Diagram for Internet Banking System

  • Côté client :

    • Appareil mobile : Exécute l’application mobile (iOS/Android).

    • Ordinateur : Exécute le navigateur web (Chrome/Firefox/Safari/Edge) qui héberge l’application monopage.

  • Centre de données de Big Bank plc :

    • Serveurs web (bigbank-web*):** Nœuds Ubuntu 16.04 LTS en cours d’exécution Apache Tomcat 8.x.

      • Héberge le Application web et Application API.

    • Serveurs de base de données (bigbank-db01/02) : Nœuds Ubuntu 16.04 LTS en cours d’exécution Oracle 12c.

      • Oracle – Primaire : La base de données principale.

      • Oracle – Secondaire : Une réplique pour la redondance ou la haute disponibilité.

Relation clé : L’application mobile et le navigateur web se connectent via internet à la Application API hébergée sur Tomcat. L’application API se connecte via JDBC au cluster de base de données Oracle.

6. Concepts clés et lignes directrices appliquées

Sur la base de cette étude de cas, les principes suivants de modélisation C4 ont été appliqués :

  1. Niveaux d’abstraction : Le modèle passe avec succès de « Qui l’utilise ? » (Contexte) à « De quoi est-il composé ? » (Conteneurs) à « Comment est-il organisé ? » (Composants) à « Où s’exécute-t-il ? » (Déploiement).

  2. Limites du périmètre :

    • Au niveau 1, la frontière « Big Bank plc » distingue clairement les systèmes internes des acteurs externes.

    • Au niveau 2, la frontière « Système de banque en ligne » encapsule le logiciel spécifique en cours de développement, en le séparant du système hérité Mainframe.

  3. Séparation des préoccupations :

    • Frontend vs. Backend : La séparation de l’application monopage (frontend) de l’application API (backend) permet un développement et une mise à l’échelle indépendants.

    • Séparation des données : Les données sensibles de la banque centrale sont conservées sur le Mainframe, tandis que le système de banque en ligne ne met en cache que les données d’accès utilisateur nécessaires dans sa propre base de données Oracle.

  4. Indépendance technologique (lorsque cela est pertinent) : Les diagrammes précisent les technologies (Java, Angular, Oracle) là où elles sont pertinentes pour la décision architecturale, mais se concentrent principalement sur les relations et responsabilités des blocs.

  5. Notation : La notation C4 standard est utilisée :

    • Personne : Figures en bois (ou cercles dans ce style de rendu spécifique).

    • Système logiciel/Conteneur/Composant : Rectangles arrondis aux couleurs distinctes (Bleu pour interne/primaire, Gris pour externe/secondaire).

    • Relations : Flèches pointillées avec des étiquettes décrivant le protocole (par exemple, [HTTPS], [JSON], [JDBC]).