Ameliorations futures

Ce document recense les ameliorations planifiees et recommandees pour Place API, basees sur le MIGRATION-PLAN.md, l'analyse du codebase actuel, et les bonnes pratiques de l'industrie.

1. Modules metier additionnels

Contexte

Le plan de migration prevoit l'ajout de trois modules metier issus de l'ancienne architecture microservices :

Ce qui existe deja

• Le projet Booking.Contracts existe dans src/Modules/Booking/Booking.Contracts/ avec un .csproj configure.
• Les interfaces publiques des modules sont definies dans le plan de migration (IFlightModule, IPassengerModule).

Actions requises

• Creer les modules Flight et Passenger avec la structure standard (Entities, Features, Persistence, Extensions).
• Migrer les entites depuis l'ancienne architecture (src/Services/) vers les nouveaux modules.
• Remplacer les projections MongoDB par des queries EF Core directes sur PostgreSQL.
• Remplacer l'Event Sourcing (Booking) par un modele EF Core classique.
• Implementer les interfaces de module comme alternative aux appels gRPC.

2. Cache Redis

Etat actuel

Le caching est configure via EasyCaching en mode in-memory. Cela fonctionne pour une instance unique mais ne supporte pas le scaling horizontal.

Amelioration prevue

• Remplacer le cache in-memory par Redis pour supporter le deployement multi-instance.
• Redis est deja mentionne dans le plan de migration comme infrastructure cible.
• Le rate limiting beneficierait egalement d'un store Redis distribue.

Impact

3. Architecture evenementielle (Outbox Pattern)

Etat actuel

Le module de persist message existe avec une table dediee et une integration Hangfire (PersistMessageOptions). L'outbox dispatch est configure avec un cron */15 * * * *.

Ameliorations recommandees

• Fiabiliser le pattern outbox avec des garanties de delivery at-least-once.
• Ajouter un mecanisme de retry avec backoff exponentiel (deja configure : MaxRetryCount: 3, RetryBackoffBaseSeconds: 10).
• Considerer l'ajout d'un dead letter queue pour les messages qui echouent apres tous les retries.
• A terme, envisager une transition vers un message broker externe (RabbitMQ, Azure Service Bus) si les besoins de scalabilite l'exigent.

4. Modules Push Notification et SMS

Etat actuel

Ameliorations

• Implementer un vrai service de push notifications (Firebase Cloud Messaging ou APNs).
• L'entite PushToken est deja en place dans le module Identity pour stocker les tokens FCM/APNs par device.
• Ajouter la gestion des bounce et du feedback loop pour les push notifications.

5. API Versioning

Etat actuel

L'API utilise Asp.Versioning avec des version sets par module. Seule la version 1.0 existe actuellement.

Ameliorations recommandees

• Definir une strategie claire de deprecation des anciennes versions.
• Ajouter le versioning dans l'URL de maniere systematique (actuellement /api/v1/...).
• Documenter le processus de creation d'une nouvelle version d'endpoint.
• Ajouter des headers de sunset pour les versions deprecees.

6. Monitoring et observabilite

Etat actuel

Ameliorations recommandees

• Deployer un stack d'observabilite complet (Grafana + Prometheus + Loki/Tempo).
• Activer l'export OTLP pour integration avec des plateformes comme Datadog ou New Relic.
• Ajouter des metriques metier personnalisees (nombre d'inscriptions/jour, taux d'echec login, etc.).
• Configurer des alertes sur les metriques critiques (taux d'erreur > seuil, latence elevee).
• Ajouter le distributed tracing complet entre les modules via le CorrelationId.

7. Pipeline CI/CD

Etat actuel

Ameliorations recommandees

• Ajouter le build Docker et le push de l'image dans la pipeline CI.
• Implementer le deploy automatique vers staging sur merge dans main.
• Ajouter l'analyse de securite des dependances (Snyk, Dependabot).
• Ajouter la couverture de code (Coverlet + rapport).
• Ajouter des smoke tests post-deploiement.

8. Multi-tenancy

Etat actuel

Le module Audit possede des champs TenantId dans les logs, et l'architecture est preparee pour le multi-tenant, mais il n'est pas encore implemente.

Amelioration prevue

• Implementer le multi-tenancy via Finbuckle.MultiTenant (mentionne dans les regles d'architecture).
• Ajouter le filtrage automatique par tenant dans les DbContexts.
• Definir la strategie de resolution du tenant (header HTTP, claim JWT, sous-domaine).

9. Administration Web

Etat actuel

Un projet AdminWeb existe dans src/Admin/AdminWeb/ (application Bun/frontend). Il est orchestre par Aspire et tourne sur le port 5175 en developpement.

Ameliorations

• Developper les interfaces d'administration pour :
  • Gestion des utilisateurs (activation/desactivation, recherche)
  • Visualisation des sessions actives
  • Consultation des logs d'audit en temps reel (via SignalR)
  • Monitoring des messages envoyes
  • Dashboard des metriques metier

10. Tests d'architecture

Etat actuel

Pas de projet de tests d'architecture dedie.

Amelioration prevue

Le plan de migration et les regles d'architecture mentionnent des tests d'architecture pour enforcer :

[Fact]
public void Module_ShouldNotReference_OtherModule_Internals()
{
    // Verifie l'isolation des modules
}

[Fact]
public void Domain_ShouldNotDepend_On_Infrastructure()
{
    // Verifie la separation des couches
}

Priorites recommandees