quel-est-ce-pokemon/docs/ARCHITECTURE.md

Application Architecture

Overview

L'application suit une Clean Architecture allégée en trois couches, avec une règle de dépendance stricte : les dépendances pointent vers l'intérieur. Le state management est assuré par Riverpod (providers manuels).

Couches

domain (Dart pur)

• Entités : Pokemon, immuable, sans dépendance Flutter/DB/API.
• Repository (interface) : PokemonRepository définit le contrat d'accès aux données.
• Jeu : GameState (état immuable) et GameEngine (règles pures, testables).

data

• DTO : PokemonDto centralise tout le parsing JSON (API Tyradex + SQLite).
• Datasources : PokemonLocalDataSource (SQLite via sqflite), PokemonRemoteDataSource (HTTP).
• Repository (impl) : PokemonRepositoryImpl applique « DB locale d'abord, sinon API + cache ». Sur le web, le datasource local est absent (null).

presentation

• Providers : pokemonRepositoryProvider (DI), pokedexProvider (AsyncNotifier), gameProvider (Notifier<GameState>), selectedTabProvider (onglet courant).
• Pages : ConsumerWidget / ConsumerStatefulWidget qui observent les providers.
• Widgets : éléments réutilisables (PokemonImage, PokemonTile, PokemonTypeWidget).
• Thème : type_colors.dart (couleur/format des types).

Flux de données

UI (Consumer) → Notifier → GameEngine (règles) + Repository (données)
                                 → DataSource (SQLite / HTTP) → DTO → Entity

Riverpod re-render automatiquement les consommateurs concernés. Plus de bus d'événements global ni d'accès inter-pages via l'arbre de widgets.

Tests

• test/domain/game_engine_test.dart : règles du jeu.
• test/data/pokemon_dto_test.dart : parsing.
• test/data/pokemon_repository_test.dart : logique du repository (datasources factices).