Pourquoi une architecture claire change tout

Une API qui commence “vite fait” finit souvent en dette technique :
couplage fort, règles métier perdues entre les contrôleurs, difficile à tester, et chaque nouvelle feature devient un risque.

Voici les principes que j’applique systématiquement sur les projets clients.

1. Séparer clairement les couches

Je structure généralement en :

  • Domain : règles métier, entités, services métier
  • Application : cas d’usage, DTO, ports
  • Infrastructure : EF Core, HTTP clients, providers externes
  • API : contrôleurs minces, mapping, validation

Objectif : le métier ne dépend pas de la base de données ni d’ASP.NET Core.

2. DTO partout aux frontières

  • Entrée : DTO de requête
  • Sortie : DTO de réponse

Aucun DbContext ni entité EF Core exposé directement.
Cela protège le domaine et évite les leaks de schéma.

3. Validation & règles métier

  • Validation d’entrée via FluentValidation ou attributs.
  • Règles métier dans le Domain (pas dans le contrôleur), testées unitairement.
  • Codes erreurs cohérents (400, 404, 409, etc.).

4. Logging & observabilité

  • Serilog + corrélation ID.
  • Logs structurés sur les opérations critiques.
  • Métriques (temps de réponse, erreurs par endpoint).

5. Tests ciblés

  • Tests unitaires sur les services métier.
  • Quelques tests d’intégration pour les endpoints clés.
  • Pipelines CI pour exécuter tout ça.

Ce type d’architecture ne rajoute pas de “théorie pour la théorie”.
Il offre surtout un cadre stable pour faire évoluer l’API sans la casser, et c’est ce que recherchent les équipes qui me confient leurs projets .NET.