Devlog #2 – Modèle C4

👋 C’est l’heure du Devlog 2 !

Salutation, aujourd’hui nous parlerons d’un sujet très apprécié des développeurs 😏, la documentation et plus précisément celle de l’architecture du projet !

Au programme :

• Qu’est-ce que le modèle C4 ?
• Diagramme du contexte
• Diagramme des conteneurs
• Diagramme des composants de l’API backend
• Qu’est-ce que ça apporte au projet ?
• La suite !

🤔 Qu’est-ce que le modèle C4 ?

Nous avons tous déjà eu cette image de schéma d’architecture d’un projet vraiment incompréhensible, partant dans tous les sens, c’est là que le modèle c4 vient en aide !

Au lieu de tout regrouper dans un seul diagramme, le modèle C4 permet de réaliser plusieurs diagrammes avec un niveau d’abstraction différente. C’est-à-dire que nous allons partir d’une vision large du projet et nous rapprocher petit à petit de chaque composant de notre projet.

Pour représenter ce modèle, nous pouvons prendre l’exemple d’une carte du monde que l’on divise en continents, en pays, en régions, en villes, chacun avec ses propres informations en fonction de son niveau, on ne va pas afficher toutes les villes du monde sur une carte du monde entier.

Généralement, le modèle C4 est divisé en 4 niveaux :

• Niveau 1: Diagramme de contexte (parties prenantes, système…)
• Niveau 2: Diagramme des conteneurs (API, frontend, application mobile…)
• Niveau 3: Diagramme des composants (controller, services…)
• Niveau 4: Diagramme de codes (UML)

🚀 Diagramme du contexte système

À quoi sert-il ?

Le diagramme de contexte permet de prendre du recul sur le projet et de voir quelles sont les parties prenantes et les différents systèmes qui vont interagir avec notre projet.

Comment réaliser ces diagrammes ?

Pour réaliser les diagrammes du modèle C4, nous avons utilisé Structurizr, qui permet de créer, et gérer les multiples diagrammes de notre projet via du code DSL.

Le contexte système de Pathfinder

Nous pouvons retrouver deux catégories d’entités qui interagissent avec notre système :

• Person (Les parties prenantes) : Les JetPeople qui sont les utilisateurs internes à Jetdev
• Software System (Les différents systèmes de notre projet) : Notre système et les systèmes externes (Google) qui par exemple nous permettent de gérer l’authentification.

Nous pouvons retranscrire ce diagramme comme : Notre projet possède des utilisateurs internes à Jetdev qui vont interagir avec notre projet Pathfinder, qui lui-même interagit avec les serveurs Oauth2 de Google afin de gérer l’authentification.

📦 Diagramme des conteneurs

À quoi sert-il ?

Le diagramme des conteneurs permet de commencer à s’intéresser à notre système, de savoir quelles sont les différentes applications au sein de notre système, de voir avec qui et comment elles vont interagir avec les autres, par qui elles sont utilisées…

Les conteneurs de Pathfinder

Les entités que l’on retrouve dans ce diagramme :

• Container (Les conteneurs) : Les applications de notre projet Pathfinder
• Software System (Les systèmes externes) : Les systèmes externes (Google) qui interagissent avec les containers.
• Person (Les JetPeople) : Les utilisateurs de l’application.

Ce diagramme nous permet de clairement comprendre comment les applications sont censées communiquer avec les autres, quelles sont les applications que les utilisateurs peuvent utiliser.

🧑‍💻 Diagramme des composants de l’API backend

À quoi sert-il ?

Le diagramme de composants permet de s’intéresser au fonctionnement de nos différentes applications et de décrire les composants internes à celles-ci avec leurs responsabilités, leur implémentation et leurs relations.

Les composants de l’API backend Pathfinder

Dans ce diagramme, nous retrouvons :

• Container (Le Conteneur) : La partie de notre système que l’on souhaite décrire et le conteneur auquel il communique.
• Component (Les composants) : Les différents composants que contient le conteneur avec les différentes relations.

Qu’est-ce que cela apporte au projet ?

• Une documentation simple et claire du projet.
• Compréhensible pour les nouveaux membres du projet et les non-développeurs.
• Beaucoup plus simple à réaliser et à maintenir que les diagrammes traditionnels d’architecture.
• Pas de dangerosité supplémentaire (malgré son nom 💥…).

🤔 La suite !

Pour la suite du projet le défi est de mettre à jour continuellement les graphiques du modèle C4 afin qu’ils soient toujours au plus proche de l’architecture !

Si vous souhaitez plus d’informations sur le modèle C4, William à réalisé un super talk à ce sujet que vous pouvez revoir ici !