L'Architecture Propre (Clean Architecture) dans les projets .NET

L'un des défis majeurs dans la création d'applications d'entreprise est de maintenir le code compréhensible et modifiable à mesure que le projet grossit. C'est là que l'Architecture Propre (ou Clean Architecture) entre en jeu. Popularisée par Robert C. Martin (Uncle Bob), elle met l'accent sur la séparation des responsabilités.

Voici une représentation visuelle du concept :

Les couches de l'Architecture Propre

Dans une solution .NET typique, cela se traduit souvent par une structure de solution avec plusieurs projets (bibliothèques de classes).

1. Domain (Le Cœur)

C'est le centre de votre application. Cette couche ne dépend d'absolument rien d'autre. Elle contient vos Entités d'entreprise, les Énumérations, et les exceptions spécifiques au domaine.

namespace VicodeBlog.Domain.Entities;

// L'entité au cœur de notre logique
public class Article
{
    public Guid Id { get; private set; }
    public string Title { get; private set; }
    public string Content { get; private set; }

    public Article(string title, string content)
    {
        Id = Guid.NewGuid();
        Title = title;
        Content = content;
    }
}

2. Application

Cette couche définit les cas d'utilisation de votre système. Elle dépend uniquement de la couche Domain. C'est ici que l'on retrouve souvent le pattern CQRS (Command Query Responsibility Segregation) avec des bibliothèques comme MediatR, ainsi que les interfaces pour les dépôts (Repositories).

3. Infrastructure

C'est ici que le code interagit avec le monde extérieur. Tout ce qui concerne l'accès aux bases de données (Entity Framework Core), les systèmes de fichiers, l'envoi d'e-mails, ou l'appel d'API externes se trouve ici. L'Infrastructure implémente les interfaces définies dans la couche Application.

4. Presentation (Web / API)

C'est le point d'entrée pour les utilisateurs ou les clients. Dans ASP.NET Core, ce sont vos Contrôleurs (Controllers) ou vos Endpoints minimaux (Minimal APIs). Cette couche gère les requêtes HTTP, valide les entrées de base, et délègue le travail réel à la couche Application.

Pourquoi utiliser cette architecture ?

L'avantage principal est de pouvoir remplacer des technologies sans casser le cœur métier. Si vous décidez de passer de SQL Server à PostgreSQL, virtuellement seul le projet Infrastructure devra être modifié. Votre logique métier (Domain) et vos cas d'utilisation (Application) n'ont pas besoin de savoir quelle base de données vous utilisez.