Points d'attention

Protection des BuildingBlocks

Le dossier src/BuildingBlocks/ contient le code partage par tous les modules. Toute modification de BuildingBlocks a un impact sur l'ensemble de l'application.

Regles

• Ne jamais modifier src/BuildingBlocks/ sans approbation explicite.
• Preferer les methodes d'extension ou les abstractions au niveau du module.
• Si une modification est necessaire, documenter l'impact et tester tous les modules affectes.

Composants BuildingBlocks

Frontieres des modules

Principe fondamental

Les modules communiquent uniquement via :

1. Les projets Contracts (DTOs, interfaces, events)
2. Les MediatR Notifications (evenements in-process)

A ne jamais faire

// INTERDIT : reference directe aux types internes d'un autre module
using Identity.Persistence;
using Identity.Entities;
using Audit.Services;

Approche correcte

// CORRECT : reference au projet Contracts
using Identity.Contracts;
using Identity.Contracts.IntegrationEvents;

Visibilite des types

• Les types de module sont internal par defaut.
• Seuls les types dans .Contracts sont public.
• InternalsVisibleTo est utilise uniquement pour les projets de test du meme module.

Securite

JWT et gestion des tokens

Gestion des sessions

Politique de mots de passe

OTP (One-Time Password)

Anti-enumeration

Tous les endpoints sensibles retournent des reponses generiques pour empecher l'enumeration des utilisateurs :

• POST /forgot-password : Toujours 200 OK
• POST /confirm-email : Toujours 200 OK
• POST /resend-confirmation : Toujours 200 OK
• POST /otp/resend : Toujours 200 OK

Headers de securite

L'application injecte systematiquement les headers suivants :

X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Content-Security-Policy: default-src 'self'; frame-ancestors 'none'

Gestion des migrations de base de donnees

Regles

1. Toujours creer les migrations dans le bon module en specifiant --context et --project.
2. Ne jamais modifier une migration deja appliquee en production.
3. Tester les migrations dans un environnement de staging avant la production.
4. Les migrations sont appliquees automatiquement au demarrage via IStartupTask.

Ordre d'execution

L'ordre de demarrage des taches est important :

1. Migrations de la base Identity
2. Seed des donnees (roles, admin)
3. Migrations des autres modules (Audit, Messaging)
4. Demarrage de Hangfire

Rollback

EF Core ne fournit pas de rollback automatique en production. Preparer des scripts de rollback manuels pour les migrations complexes.

Configuration sensible

Fichiers a ne jamais committer

Variables d'environnement critiques

Concurrence et versioning

Concurrency token

L'entite User utilise le champ Version comme concurrency token EF Core. Cela signifie :

• Toute modification concurrente d'un meme utilisateur leve une DbUpdateConcurrencyException.
• Le champ Version est incremente automatiquement a chaque SaveChangesAsync.
• Les entites implementant IVersion suivent le meme pattern.

Idempotence

Certains endpoints supportent l'idempotence via le header Idempotency-Key :

• POST /register
• POST /reset-password
• POST /social (login social)

L'entite IdempotencyRecord stocke les resultats des requetes precedentes avec une date d'expiration.

Rate limiting

Le rate limiting est configure par politique. Un depassement retourne 429 Too Many Requests.

Points de vigilance :

• Les politiques sont par IP source (via X-Forwarded-For si derriere un proxy).
• La configuration ForwardedHeadersTrustOptions doit correspondre a l'infrastructure de deploiement.
• En mode cluster, le rate limiting in-memory ne partage pas l'etat entre instances (Redis necessaire pour le scaling).

Observabilite

OpenTelemetry

L'application expose des metriques et des traces via OpenTelemetry :

{
  "ObservabilityOptions": {
    "InstrumentationName": "place-api",
    "MetricsEnabled": true,
    "TracingEnabled": true,
    "UsePrometheusExporter": true
  }
}

Audit HTTP Middleware

Un middleware d'audit capture automatiquement les requetes/reponses HTTP :

• Corps limites a 2048 octets
• Types de contenu captures : application/json, application/problem+json
• Chemins exclus : /health, /alive, /metrics, /hangfire

Background Jobs (Hangfire)

Le dashboard Hangfire est accessible en developpement. En production, securiser l'acces.