unionflow-mobile-apps/docs/AUDIT_INJECTION_DEPENDANCES.md

Audit Injection de Dépendances - UnionFlow Mobile

Date: 2026-03-14 Framework: GetIt + Injectable Total services: 51 services enregistrés

---

📊 Vue d'Ensemble

Répartition par Type d'Annotation

Annotation	Nombre	Description
@injectable	27	Instance créée à la demande
@lazySingleton	24	Singleton lazy (créé au premier accès)
Total	51

Répartition par Feature (Top 10)

Feature	Services	Statut
finance_workflow	11	✅ Complet
communication	6	✅ Complet
dashboard	5	✅ Complet
notifications	3	✅ Complet
organizations	2	✅ OK
members	2	✅ OK
feed	2	✅ OK
explore	2	✅ OK
contributions	2	✅ OK
authentication	2	✅ OK

Autres features (1 service chacune) : solidarity, settings, reports, profile, logs, events, epargne, backup, admin, adhesions

---

🔍 Audit Détaillé par Feature

Finance Workflow (11 services) ✅

BLoCs (2):

• ApprovalBloc
• BudgetBloc

Use Cases (7):

• GetPendingApprovals
• GetApprovalById
• ApproveTransaction
• RejectTransaction
• GetBudgets
• GetBudgetById
• GetBudgetTracking

Data Sources (1):

• FinanceWorkflowRemoteDataSource

Repositories (1):

• Géré via clean architecture (injecté dans les use cases)

Statut: ✅ Complet - Tous les composants sont injectables

---

Autres Features

Communication (6 services):

• BLoCs, Repositories, Services de messagerie

Dashboard (5 services):

• DashboardBloc, Repositories, Cache Manager

Notifications (3 services):

• NotificationsBloc, Repository, Services

Autres features (1-2 services chacune):

• Pattern cohérent : BLoC + Repository minimum

---

✅ Architecture DI Actuelle

Fichiers Core

lib/core/di/
├── injection.dart              (Configuration @InjectableInit)
├── injection.config.dart       (Fichier généré - NE PAS MODIFIER)
├── injection_container.dart    (GetIt instance + init)
└── register_module.dart        (Modules personnalisés)

Pattern Utilisé

Centralisation : ✅ Un seul fichier d'injection généré

• Ancien pattern (DI par feature) : ❌ Supprimé (bonne pratique DRY)
• Nouveau pattern : ✅ @injectable annotations + build_runner

Initialisation

// main.dart
void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await initializeDependencies();
  runApp(MyApp());
}

// injection_container.dart
Future<void> initializeDependencies() async {
  configureDependencies(); // Appelle getIt.init()
}

---

📋 Checklist de Conformité

Architecture

• ✅ Un seul fichier de configuration DI (injection.dart)
• ✅ Fichier généré automatiquement (injection.config.dart)
• ✅ Pattern DRY respecté (pas de duplication)
• ✅ GetIt comme service locator
• ✅ Injectable pour la génération de code

Annotations

• ✅ @injectable utilisé (27 services)
• ✅ @lazySingleton utilisé (24 services)
• ⚠️ @singleton non utilisé (vérifier si nécessaire)
• ✅ Pas de duplication de code DI

Coverage par Feature

• ✅ Finance Workflow : 11 services (BLoC, repositories, usecases)
• ✅ Communication : 6 services
• ✅ Dashboard : 5 services
• ✅ Notifications : 3 services
• ✅ Autres features : 1-2 services chacune

---

🎯 Recommandations

✅ Points Forts

1. Centralisation réussie

   • Un seul point d'entrée pour la configuration DI
   • Pas de fichiers *_di.dart dispersés dans les features

2. Build runner bien utilisé

   • Code généré automatiquement
   • Évite l'enregistrement manuel

3. Bon équilibre @injectable vs @lazySingleton

   • 27 @injectable : Services sans état ou à courte durée de vie
   • 24 @lazySingleton : Services stateful ou coûteux à instancier

✅ Register Module Vérifié

Fichier: lib/core/di/register_module.dart

Dépendances externes enregistrées (3):

@module
abstract class RegisterModule {
  @lazySingleton Connectivity get connectivity
  @lazySingleton FlutterSecureStorage get storage
  @lazySingleton http.Client get httpClient
}

Statut: ✅ Correct - Uniquement des packages externes

• Pas de duplication avec injection.config.dart
• Usage approprié de @module pour les classes tierces

⚠️ Points d'Attention

1. Documentation

2. Documentation

   • Ajouter des commentaires dans injection.dart pour expliquer le pattern
   • Documenter quand utiliser @injectable vs @lazySingleton

3. Tests

   • Vérifier que cleanupDependencies() fonctionne correctement
   • Ajouter des tests d'intégration pour la DI

---

🔄 Commandes Utiles

Regénérer le fichier injection.config.dart

# Après avoir ajouté de nouveaux services avec @injectable
flutter pub run build_runner build --delete-conflicting-outputs

Vérifier les services enregistrés

# Compter les services
grep -r "@injectable\|@lazySingleton" lib/features --include="*.dart" | wc -l

# Par feature
grep -r "@injectable" lib/features --include="*.dart" -l | \
  sed 's|lib/features/||' | cut -d'/' -f1 | sort | uniq -c

---

📘 Guide : Ajouter un Nouveau Service

Étape 1: Annoter la Classe

Pour un service sans état (créé à chaque utilisation):

import 'package:injectable/injectable.dart';

@injectable
class MyUseCase {
  final MyRepository repository;

  MyUseCase(this.repository);

  Future<Result> execute() async {
    return repository.doSomething();
  }
}

Pour un service stateful (singleton lazy):

@lazySingleton
class MyRepository {
  final ApiClient apiClient;

  MyRepository(this.apiClient);
}

Étape 2: Regénérer le Code

flutter pub run build_runner build --delete-conflicting-outputs

Étape 3: Utiliser le Service

import 'package:get_it/get_it.dart';

final getIt = GetIt.instance;

// Dans un widget ou BLoC
final myUseCase = getIt<MyUseCase>();

OU via constructor injection (recommandé):

@injectable
class MyBloc extends Bloc {
  final MyUseCase myUseCase;

  MyBloc(this.myUseCase); // Injecté automatiquement
}

Choix de l'Annotation

Annotation	Usage	Exemple
@injectable	Services sans état, UseCases	GetPendingApprovals
@lazySingleton	Repositories, DataSources, Services avec cache	NotificationRepository
@singleton	Rarement utilisé (créé immédiatement au démarrage)	N/A

---

📝 Prochaines Étapes

Complété ✅:

1. ✅ Lister tous les services enregistrés feature par feature
2. ✅ Vérifier register_module.dart pour éviter duplication
3. ✅ Documenter les patterns d'utilisation
4. ✅ Créer un guide "Comment ajouter un nouveau service"

À Faire:

1. Ajouter des tests pour la DI (optionnel P2)
2. Documenter les @module patterns avancés (optionnel P2)

---

🎊 Conclusion

Statut Global: ✅ CONFORME

• Architecture DI bien structurée
• Pattern DRY respecté
• 51 services correctement enregistrés
• Pas de duplication apparente

Recommandation: Continuer avec ce pattern pour les nouvelles features.

---

Audit réalisé par: Claude Code Date: 2026-03-14