Architecture de MateZone
Découvrez la structure hexagonale moderne qui fait de MateZone une application robuste, maintenable et évolutive.
Vue d'ensemble de l'architecture
MateZone suit une architecture hexagonale (ports/adapters) avec une séparation claire entre les différentes couches
🖥️ Couche Client (MVC)
Gestion des interactions utilisateur
Interface utilisateur Swing
Logique business côté client
🔄 Couche Commune
Objets de transfert de données
Énumérations et contrats
⚙️ Couche Serveur
Protocole de communication
Logique métier serveur
Accès aux données
🗄️ Couche Persistance
Stockage des utilisateurs, messages et canaux
Structure détaillée des modules
Exploration approfondie de chaque module et de ses responsabilités
🖥️ Module Client
client/
├── MainClient.java
├── controleur/
│ └── Controleur.java
├── ihm/
│ ├── IhmGui.java
│ ├── frame/
│ │ ├── affichage/
│ │ │ └── MateZoneFrame.java
│ │ └── connexion/
│ │ └── ConnexionFrame.java
│ └── panel/
│ ├── affichage/
│ └── connexion/
├── infrastructure/
│ └── websocket/
│ └── WebSocketChatAdapter.java
└── metier/
├── Metier.java
└── interfaces/
├── IEnvoyeur.java
└── INotifieur.java
Responsabilités :
- Gestion de l'interface utilisateur
- Traitement des événements utilisateur
- Communication avec le serveur via WebSocket
- Logique métier côté client
⚙️ Module Serveur
server/
├── MainServer.java
├── bd/
│ ├── ConnexionBD.java
│ ├── repository/
│ │ ├── MessageRepository.java
│ │ └── UtilisateurRepository.java
│ └── SQL/
│ └── MateZone.sql
├── metier/
│ ├── interfaces/
│ │ ├── IMessageRepository.java
│ │ ├── IUtilisateurRepository.java
│ │ └── IWebSocketMateZone.java
│ ├── model/
│ │ ├── Client.java
│ │ └── Message.java
│ └── service/
│ └── ClientService.java
└── Protocol/
└── webSocket/
└── WebSocketMateZone.java
Responsabilités :
- Gestion des connexions WebSocket
- Logique métier serveur
- Persistance des données
- Authentification et sécurité
Patterns de conception utilisés
MateZone implémente plusieurs patterns de conception reconnus pour garantir la qualité du code
Architecture Hexagonale
Séparation claire entre la logique métier et les adaptateurs externes (base de données, interface utilisateur, réseau).
Pattern MVC
Architecture Modèle-Vue-Contrôleur pour organiser le code côté client avec séparation des responsabilités.
Pattern Repository
Abstraction de l'accès aux données avec des interfaces bien définies pour chaque entité métier.
Pattern DTO
Objets de transfert de données pour sérialiser les échanges entre client et serveur via JSON.
Pattern Adapter
Adaptation des WebSockets aux interfaces métier pour découpler la technologie de communication.
Dependency Injection
Injection des dépendances pour réduire le couplage entre les composants du système.
Flux de communication
Comment les données circulent entre le client et le serveur
📤 Envoi de message
- L'utilisateur saisit un message dans l'IHM
- Le contrôleur capture l'événement
- Le métier client valide le message
- L'adaptateur WebSocket envoie le DTO
- Le serveur WebSocket reçoit le message
- Le service traite et sauvegarde en base
- Le message est diffusé aux clients connectés
📥 Réception de message
- Le serveur diffuse un nouveau message
- L'adaptateur WebSocket client reçoit le DTO
- Le métier client traite l'événement
- Le notifieur met à jour l'IHM
- L'interface affiche le nouveau message
- L'utilisateur voit la mise à jour temps réel
{
"type": "NEW_MESSAGE",
"pseudo": "utilisateur",
"contenu": "Bonjour MateZone !",
"channel": 1,
"timestamp": "2024-11-11T10:30:00"
}
Avantages de cette architecture
Pourquoi MateZone utilise-t-il une architecture hexagonale ?
Testabilité
La séparation des couches permet de tester chaque composant indépendamment avec des mocks et des stubs.
- Tests unitaires isolés
- Tests d'intégration ciblés
- Mocking des dépendances externes
Maintenabilité
Code organisé et structuré facilitant la maintenance et l'évolution de l'application.
- Responsabilités bien définies
- Faible couplage entre modules
- Documentation claire du code
Évolutivité
Architecture flexible permettant l'ajout de nouvelles fonctionnalités sans impacter l'existant.
- Nouveaux adaptateurs possibles
- Extension des services métier
- Changement de technologies facile
Réutilisabilité
Composants modulaires réutilisables dans d'autres contextes ou projets.
- Logique métier indépendante
- Interfaces standardisées
- Composants découplés
Choix techniques et justifications
Les technologies sélectionnées et les raisons de ces choix
| Technologie | Utilisation | Justification |
|---|---|---|
| Java WebSocket API | Communication temps réel | Standard Java, performance optimale, support natif du protocole WebSocket |
| Java Swing | Interface utilisateur | Interface native, riche en composants, intégration parfaite avec Java |
| MySQL | Base de données | Fiabilité éprouvée, performance, support des transactions ACID |
| Gson | Sérialisation JSON | Simple d'utilisation, performance, support des types génériques |
| Architecture hexagonale | Structure du code | Maintenabilité, testabilité, séparation des responsabilités |