Architecture (haut niveau) - ApplETS/Notre-Dame GitHub Wiki

🏗️ Architecture Générale (Vue Rapide)

Le projet suit une architecture model-view-viewmodel, tel que défini dans la documentation Flutter avec séparation claire entre :

┌──────────────────────────────────────────────────────────┐
│                   PRÉSENTATION (UI)                      │
│  Views • ViewModels • Widgets • Navigation • Themes      │
└──────────────────────────────────────────────────────────┘
                            ↓
┌──────────────────────────────────────────────────────────┐
│                     MÉTIER (Domain)                      │
│  Entities • Models • Constants • Business Rules          │
└──────────────────────────────────────────────────────────┘
                            ↓
┌──────────────────────────────────────────────────────────┐
│                    DONNÉES (Data)                        │
│  Repositories • Services • Models API • Caching          │
└──────────────────────────────────────────────────────────┘
                            ↓
┌──────────────────────────────────────────────────────────┐
│              INFRASTRUCTURE EXTERNE                      │
│  APIs Distantes • Firebase • Bases de Données            │
└──────────────────────────────────────────────────────────┘

📋 Les 4 Couches

Couche Domain (Métier)

Responsabilité: Contenir la logique métier pure et indépendante de toute framework

Contient:

  • Modèles de domaine (Entities)
  • Constantes métier
  • Règles de validation métier
  • Aucune dépendance à Flutter ou frameworks externes

Couche Data (Données)

Responsabilité: Gérer l'accès aux données, peu importe leur source (API, base de données, cache)

Contient:

  • Repositories : Abstraction pour accéder aux données
  • Services : Logique pour communiquer avec des APIs ou services externes
  • Models : DTO (Data Transfer Objects) pour la communication avec les APIs
  • Caching : Gestion du cache local

Couche UI (Présentation)

Responsabilité: Afficher les données et capturer les interactions utilisateur

Contient:

  • Views : Pages/Écrans de l'application
  • ViewModels : Logique d'affichage et gestion d'état
  • Widgets : Composants réutilisables
  • Navigation : Router et gestion des routes
  • Themes : Styles et thèmes

🔄 Patterns de Communication

Pattern Repository + ViewModel + View

View (UI)
  ↓ (listens)
ViewModel (gère l'état)
  ↓ (appelle)
Repository
  ↓ (appelle)
Service/API
  ↓ (retourne)
Service/API → Repository → ViewModel → View

🎯 Principes Clés

1. Séparation des Responsabilités

Chaque couche a une responsabilité unique et bien définie. Les dépendances vont de haut en bas (UI → Logic → Domain → Data).

2. Flux de Dépendances

UI → Repository → Service → API

Les dépendances ne remontent jamais (API ne dépend pas de UI).

3. Gestion d'Erreurs

Chaque couche gère ses propres erreurs et les transforme appropriées:

  • Data: RepositoryException
  • UI: LocalizedErrorMessage

4. Injection de Dépendances

Utilise GetIt pour l'injection, enregistrées dans locator.dart:

5. Testabilité

Chaque couche peut être testée indépendamment:

  • Domain : Tests unitaires de la logique métier
  • Data : Tests des repositories avec mocks des services
  • UI : Tests des ViewModels et widgets

🛡️ Avantages de cette Architecture

✅ Simplicité: courbe d’apprentissage plus rapide pour les nouveaux développeurs ✅ Testabilité : Chaque couche peut être testée indépendamment
✅ Maintenabilité : Code bien organisé et facile à naviguer
✅ Scalabilité : Facile d'ajouter de nouvelles fonctionnalités
✅ Réutilisabilité : Services et repositories partagés
✅ Séparation des Préoccupations : Responsabilités claires
✅ Flexibilité : Facile de changer les implémentations (API, cache, etc.)

Voir aussi:

Cette page a été en partie générée avec l'aide de Claude Haiku 4.5