4 dépôts GitHub pour maîtriser l'architecture .NET

Un dépôt GitHub d'architecture ne doit pas être traité comme une recette. Il représente les contraintes, les préférences et parfois les objectifs pédagogiques de ses auteurs. Copier sa structure sans comprendre ces choix produit facilement plus de couches que de valeur.

La bonne méthode consiste à étudier une question précise : comment les modules communiquent-ils ? Où vivent les règles métier ? Comment les tests traversent-ils l'infrastructure ? Quelles décisions sont documentées et lesquelles restent implicites ?

Les quatre dépôts ci-dessous donnent des réponses différentes. Ils ont été vérifiés en juillet 2026, mais leur activité et leurs dépendances peuvent évoluer.

1. dotnet/eShop : observer un système distribué avec Aspire

Le dépôt officiel dotnet/eShop présente une application e-commerce basée sur une architecture orientée services et orchestrée avec Aspire.

Il est surtout utile pour étudier :

• la composition de plusieurs services dans un AppHost ;
• la découverte de services et les dépendances d'infrastructure ;
• l'observabilité locale d'un système distribué ;
• la séparation entre catalogue, panier, identité et commandes ;
• le coût structurel introduit par la distribution.

Il ne faut pas en conclure qu'une application e-commerce doit commencer avec plusieurs services. Le dépôt montre ce que demande cette architecture lorsque la distribution est déjà justifiée. Pour un produit plus jeune, compare cette complexité à celle d'un monolithe modulaire.

2. jasontaylordev/CleanArchitecture : analyser un template moderne

jasontaylordev/CleanArchitecture est un template ASP.NET Core qui sépare domaine, application, infrastructure et interface web. Il documente également plusieurs décisions avec des ADR.

Les points intéressants à inspecter sont :

• le sens des dépendances entre projets ;
• la composition de l'application au démarrage ;
• le placement de la validation et des comportements transverses ;
• la stratégie de tests ;
• les variantes proposées selon la version de .NET.

Un template optimise le démarrage d'une certaine catégorie de projets. Il contient donc des choix dont ton application n'a peut-être pas besoin. Avant de reprendre une abstraction, cherche le problème qu'elle résout et vérifie que ce problème existe réellement chez toi.

3. kgrzybek/modular-monolith-with-ddd : comprendre les frontières de modules

kgrzybek/modular-monolith-with-ddd va plus loin qu'une simple arborescence. Le dépôt documente son domaine, ses modules, leurs communications, les décisions d'architecture et plusieurs niveaux de tests.

Il permet notamment d'étudier :

• l'encapsulation forte de chaque module ;
• la communication asynchrone entre modules ;
• la séparation des schémas de données ;
• les tests d'architecture qui contrôlent les dépendances ;
• les tests d'intégration avec de vraies dépendances externes ;
• la documentation des décisions et des compromis.

Le projet est volontairement riche. Cette richesse le rend utile pour apprendre, mais trop lourd à reproduire mécaniquement dans une petite application. Lis-le comme un catalogue de décisions vérifiables, pas comme une structure minimale obligatoire.

4. ardalis/CleanArchitecture : comparer deux interprétations du même principe

ardalis/CleanArchitecture propose une autre interprétation de la Clean Architecture, avec un template complet et une variante plus minimale.

La comparaison avec le template de Jason Taylor est particulièrement instructive. Les deux projets partagent une intention de découplage, mais ne placent pas toujours les responsabilités, les bibliothèques et les conventions au même endroit.

Regarde en priorité :

• ce que chaque template considère comme le noyau de l'application ;
• la façon dont les cas d'usage sont exposés ;
• le rôle accordé aux événements de domaine ;
• la frontière entre infrastructure et interface web ;
• les éléments retirés dans la version minimale.

Cette comparaison montre qu'un principe d'architecture ne conduit pas à une seule structure de dossiers.

Une méthode de lecture en cinq étapes

Pour tirer quelque chose de ces dépôts, évite de commencer par cloner le code. Choisis d'abord un seul flux métier, puis suis-le de bout en bout.

1. Identifie le point d'entrée HTTP ou applicatif.
2. Suis la commande ou la requête jusqu'à la règle métier.
3. Repère l'endroit où l'infrastructure intervient.
4. Trouve les tests qui protègent ce flux.
5. Note les abstractions réellement nécessaires à ce parcours.

Ensuite seulement, compare ce flux avec ton propre système. Une abstraction est intéressante si elle réduit un risque concret : dépendance instable, règle métier dispersée, test impossible ou intégration difficile à remplacer.

Les dépôts à ne plus prendre comme référence principale

Plusieurs anciennes listes recommandent encore eShopOnWeb ou eShopOnContainers. Les dépôts Microsoft historiques ont été archivés et renvoient maintenant vers dotnet/eShop. Ils restent utiles pour comprendre l'évolution des architectures .NET, mais ne constituent plus le meilleur point de départ pour choisir des dépendances actuelles.

Conclusion

La valeur de ces dépôts ne vient ni de leur nombre d'étoiles ni du nombre de patterns qu'ils contiennent. Elle vient des décisions qu'ils rendent observables.

Étudie dotnet/eShop pour la distribution et Aspire, les deux templates Clean Architecture pour comparer des frontières applicatives, et le monolithe modulaire de Kamil Grzybek pour approfondir l'encapsulation et les tests d'architecture. Puis conserve uniquement les idées qui répondent aux contraintes réelles de ton projet.