Construire une architecture .NET moderne en 2026

Construire une architecture .NET moderne en 2026 ne consiste pas à empiler des patterns ou à multiplier les projets dans la solution. Le vrai objectif est plus simple: permettre à une application de rester lisible, testable et évolutive pendant plusieurs années, tout en absorbant des changements métier fréquents.

Une bonne architecture n'est pas une collection de schémas. C'est une série de décisions qui réduisent le couplage, clarifient les responsabilités et rendent les évolutions prévisibles.

Ce qu'on attend d'une architecture moderne

Une architecture backend sérieuse doit couvrir cinq besoins:

séparer clairement les règles métier de l'infrastructure
rendre les flux applicatifs explicites
limiter les dépendances transverses
permettre des tests rapides et utiles
préparer le passage à l'échelle sans complexité prématurée

En .NET, cela conduit souvent vers une architecture en couches explicites:

Domain: entités, value objects, règles métier, invariants
Application: cas d'usage, orchestration, validation, contrats
Infrastructure: base de données, messaging, services externes
Api: endpoints HTTP, auth, sérialisation, composition root

Une architecture utile n'est pas forcément "clean architecture"

Beaucoup d'équipes appliquent une version mécanique de la Clean Architecture et se retrouvent avec trop de projets, trop d'interfaces et trop de cérémonie. Le résultat est souvent contre-productif.

La bonne question n'est pas: "Quel pattern est à la mode ?"

La bonne question est: "Quelles décisions doivent être stables, et lesquelles vont changer souvent ?"

Si ton domaine évolue vite, protège le domaine. Si ton application intègre beaucoup de systèmes externes, isole l'infrastructure. Si ton produit est encore jeune, ne crée pas dix abstractions pour un seul fournisseur.

Une structure pragmatique de solution

Voici une structure qui reste simple tout en offrant une vraie séparation:

src/
  YvaDev.Api/
  YvaDev.Application/
  YvaDev.Domain/
  YvaDev.Infrastructure/

tests/
  YvaDev.Domain.Tests/
  YvaDev.Application.Tests/
  YvaDev.Api.Tests/

Cette organisation permet de raisonner vite:

les règles métier vivent dans Domain
les cas d'usage vivent dans Application
les détails techniques vivent dans Infrastructure
le point d'entrée web reste dans Api

Le domaine doit rester pauvre en dépendances, pas pauvre en logique

Une erreur classique consiste à transformer le domaine en simple conteneur de DTO. C'est l'inverse de ce qu'il faut faire.

Le domaine doit porter les invariants importants.

public sealed class Subscription
{
    public SubscriptionStatus Status { get; private set; }
    public DateOnly RenewalDate { get; private set; }

    public void Renew(DateOnly renewalDate)
    {
        if (Status != SubscriptionStatus.Active)
        {
            throw new InvalidOperationException("Only active subscriptions can be renewed.");
        }

        if (renewalDate <= RenewalDate)
        {
            throw new ArgumentException("Renewal date must move forward.");
        }

        RenewalDate = renewalDate;
    }
}

Cette logique n'a rien à faire dans un contrôleur, ni dans un repository, ni dans un service utilitaire.

La couche Application orchestré, elle ne pense pas à la place du domaine

La couche application sert à décrire les flux. Elle récupère les données, invoque le domaine, persiste les changements, publie des événements si nécessaire.

public sealed class RenewSubscriptionHandler
{
    private readonly ISubscriptionRepository _repository;
    private readonly IUnitOfWork _unitOfWork;

    public async Task HandleAsync(RenewSubscriptionCommand command, CancellationToken ct)
    {
        var subscription = await _repository.GetByIdAsync(command.SubscriptionId, ct)
            ?? throw new InvalidOperationException("Subscription not found.");

        subscription.Renew(command.NewRenewalDate);

        await _unitOfWork.SaveChangesAsync(ct);
    }
}

Le handler ne decide pas des règles métier. Il coordonne.

L'infrastructure doit rester remplaçable, mais pas abstraite à l'excès

Dans beaucoup de projets .NET, l'infrastructure devient un cimetière de wrappers inutiles. Une architecture moderne evite cela.

Quelques règles simples:

abstraire les dépendances qui changent ou qui doivent être mockées utilement
ne pas créer d'interface pour une classe qui n'a qu'une implémentation et aucune raison de varier
garder les détails techniques dans Infrastructure
exposer des contrats orientés métier, pas des API génériques

Un ICustomerRepository à du sens. Un IGenericRepository<T> crée souvent plus de confusion qu'autre chose.

L'API doit être mince

Une API HTTP bien structurée ne fait que trois choses:

recevoir une requête
traduire la requête en commande ou query
renvoyer un résultat HTTP cohérent

app.MapPost("/subscriptions/{id:guid}/renew", async (
    Guid id,
    RenewSubscriptionRequest request,
    RenewSubscriptionHandler handler,
    CancellationToken ct) =>
{
    await handler.HandleAsync(new RenewSubscriptionCommand(id, request.NewRenewalDate), ct);
    return Results.NoContent();
});

Le contrôleur ou l'endpoint minimal ne doit pas contenir de logique métier cachée.

Les sujets transverses doivent être explicites

En 2026, une architecture backend moderne doit prendre au sérieux:

la validation
l'observabilité
la gestion des erreurs
l'idempotence
la sécurité
la résilience face aux services externes

Ces sujets ne doivent pas être répartis au hasard dans les couches. Ils doivent être traités par des conventions claires, des middlewares, des pipelines ou des composants dédiés.

Quand préparer la scalabilité

Il ne faut pas concevoir tout de suite une plateforme distribuée si le produit n'en à pas besoin. En revanche, il faut préparer la possibilité de grandir.

Cela signifie:

isoler les écritures importantes
séparer clairement lecture et écriture quand cela devient utile
découpler les intégrations externes
utiliser des événements métier quand ils ont un vrai sens
conserver des frontières de module nettes

Une architecture modulaire et monolithique reste souvent la meilleure base pour un produit qui grandit.

Checklist simple

Avant de valider ton architecture, pose ces questions:

où vivent les règles métier ?
peut-on comprendre un cas d'usage sans lire l'infrastructure ?
les dépendances pointent-elles dans le bon sens ?
les tests applicatifs sont-ils rapides ?
un changement de base de données ou d'API externe impacte-t-il tout le code ?

Si la réponse est mauvaise sur ces points, l'architecture est probablement trop couplée.

Conclusion

Une architecture .NET moderne en 2026 n'a pas besoin d'être spectaculaire. Elle doit être lisible, stable sous pression et suffisamment modulaire pour absorber les changements métier.

Le bon niveau d'architecture est celui qui aide l'équipe à avancer plus vite avec moins de régressions. C'est cela, une architecture moderne.