Aller au contenu principal

Presentation

Après avoir exploré les couches Domain, Application et Infrastructure, nous abordons maintenant la couche Presentation. C’est la couche la plus externe de la Clean Architecture et le point de contact direct avec l’utilisateur.

Son rôle est simple mais crucial : traduire une interaction utilisateur en une intention métier, puis restituer le résultat de manière adaptée.

6.1. Qu’est-ce que la couche Presentation ?​

La couche Presentation a pour responsabilité de :

  • Gérer les interfaces utilisateur (API HTTP, Web, Mobile, CLI, etc.)
  • Recevoir les entrées utilisateur
  • Effectuer la validation syntaxique et structurelle des données
  • Appeler les Use Cases de la couche Application
  • Transformer les résultats en réponses adaptées au canal utilisé

Caractéristiques clés :

  • Dépend uniquement de la couche Application
  • Ne contient aucune logique métier
  • Ne connaît ni le Domain ni l’Infrastructure
  • Doit rester mince, lisible et facilement remplaçable

👉 La Presentation est une porte d’entrée, jamais un lieu de décision métier.

6.2. Rôle réel de la couche Presentation​

On résume souvent cette couche à des « contrôleurs », mais son rôle est plus précis :

  • Adapter le monde extérieur au modèle applicatif
  • Gérer les protocoles (HTTP, JSON, gRPC, CLI, etc.)
  • Protéger les Use Cases des détails d’interface

👉 La couche Application ne devrait jamais savoir comment une action a été déclenchée.

6.3. Exemple en C# – ASP.NET Core​

Exemple d’API HTTP pour créer un utilisateur :

using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/[controller]")]
public class UsersController : ControllerBase
{
    private readonly CreateUserUseCase _createUserUseCase;

    public UsersController(CreateUserUseCase createUserUseCase)
    {
        _createUserUseCase = createUserUseCase;
    }

    [HttpPost]
    public IActionResult Create([FromBody] CreateUserRequest request)
    {
        _createUserUseCase.Execute(request.Email);
        return Ok(new { Message = "Utilisateur créé avec succès" });
    }
}

public class CreateUserRequest
{
    public string Email { get; set; }
}

6.4. Ce que fait réellement le contrôleur​

  • Reçoit une requête HTTP
  • Désérialise les données d’entrée
  • Effectue une validation technique (format, nullité, type)
  • Appelle un Use Case
  • Transforme le résultat en réponse HTTP

À aucun moment il ne :

  • Valide des règles métier
  • Manipule directement des entités du Domain
  • Accède à la base de données

6.5. Validation et mapping​

Bonnes pratiques :

  • Valider les entrées utilisateur dans la Presentation
  • Mapper les DTO de requête vers les paramètres des Use Cases
  • Mapper les résultats applicatifs vers des DTO de réponse
  • Garder ces transformations simples et explicites

La validation métier, elle, reste dans le Domain ou l’Application.

6.6. Erreurs fréquentes à éviter​

  • Ajouter de la logique métier dans les contrôleurs
  • Appeler directement l’Infrastructure
  • Faire dépendre la Presentation du Domain
  • Transformer les contrôleurs en services applicatifs

Un contrôleur trop complexe est souvent le symptôme d’un mauvais découpage.

6.7. Pourquoi la Presentation doit rester fine​

  • Elle change souvent (API v1/v2, nouvelle UI, nouveau protocole)
  • Elle est dépendante des frameworks
  • Elle doit être facilement remplaçable

👉 Une bonne Clean Architecture permet de changer complètement l’interface utilisateur sans toucher au métier.