Vue d'ensemble

Presentation generale de Place API - objectifs, stack technique, architecture et conventions

Vue d'ensemble

Objectif du projet

Place API est une API backend construite pour gerer l'authentification, l'autorisation, l'audit et la messagerie d'une plateforme applicative. Elle fournit un socle robuste et securise pour les applications clientes (web et mobile).

L'API est concue comme un Monolithe Modulaire : un seul deployable qui organise le code en modules independants, chacun avec son propre schema de base de donnees, ses entites et ses fonctionnalites.

Stack technique

ComposantTechnologieVersion
Framework.NET10.0
Base de donneesPostgreSQL17
ORMEntity Framework Core10.0.3
AuthentificationASP.NET Identity + JWT Bearer10.0.3
CQRSMediatR14.0.0
ValidationFluentValidation12.1.1
MappingMapster7.4.0
Generation d'IDIdGen3.0.7
Background JobsHangfire1.8.23
CachingEasyCaching (InMemory)1.9.2
EmailMailKit + Mjml.Net4.12.0 / 3.4.0
SMSAWS SNS4.0.2.14
Documentation APIScalar + Swashbuckle2.12.38 / 10.1.2
Orchestration.NET Aspire13.1.1
ObservabiliteOpenTelemetry1.15.0
TestsxUnit + FluentAssertions + Testcontainers2.9.3 / 8.8.0 / 4.9.0

Architecture globale

Place API suit le pattern Modular Monolith (Monolithe Modulaire) :

  • Un seul processus deployable (src/Api/) qui heberge tous les modules
  • Isolation logique via des schemas PostgreSQL separes par module
  • Communication inter-modules via des projets Contracts (DTOs publics) et des notifications MediatR (INotification)
  • Pas de communication reseau entre modules (pas de gRPC, pas de message broker)
mermaid
graph TB
    Client[Client HTTP] --> API[API Host :5000/:5001]
    API --> Identity[Module Identity]
    API --> Audit[Module Audit]
    API --> Messaging[Module Messaging]
    Identity --> PG[(PostgreSQL)]
    Audit --> PG
    Messaging --> PG
    Identity --> BB[BuildingBlocks]
    Audit --> BB
    Messaging --> BB

Principaux modules

Identity

Gestion complete de l'identite utilisateur : inscription, connexion, authentification sociale (Google, Facebook, Apple), 2FA/TOTP, gestion des sessions avec rotation de refresh tokens et detection de replay, gestion des groupes et roles, rate limiting par endpoint.

Audit

Tracabilite automatique de toutes les actions via middleware HTTP et behavior MediatR. Persistance des evenements d'audit dans un schema dedie avec diffusion en temps reel via SignalR.

Messaging

Envoi de messages multicanal (email via SMTP/MailKit, SMS via AWS SNS, notifications push). Templates MJML pour les emails. Persistance des messages envoyes avec suivi de statut. Nettoyage automatique des messages anciens via Hangfire.

Conventions principales

Vertical Slice Architecture

Chaque fonctionnalite est autonome dans un dossier Features/{Domaine}/{Action}/V1/ contenant la commande/query, le validateur, le handler et l'endpoint.

CQRS avec MediatR

Les commandes (ICommand<T>) et queries (IQuery<T>) sont des wrappers fins autour de IRequest<T> de MediatR. Les endpoints utilisent IMediator.Send() pour dispatcher les requetes.

Conventions de nommage

  • Types de module : internal par defaut
  • Types publics : uniquement dans les projets Contracts
  • Endpoints : route pattern /api/v{version}/{module}/{resource}
  • Commits : conventional commits (feat:, fix:, chore:, etc.)
  • Tests : {Methode}_{Scenario}_{ResultatAttendu}

Analyseurs de code

Le projet applique strictement StyleCop, Roslynator, Meziantou et CSharpGuidelinesAnalyzer comme erreurs de build. Les regles notables incluent l'interdiction de noms de parametres lambda courts (x, s, p) et l'obligation de trier les using alphabetiquement.

© 2026 Place API