Bonjour à tous,
Dans cet article, je vais passer en revue une architecture clean d’une API, en .net core 5.0.
En tant que développeur , j’ai participé au développement back-end de plusieurs projets présentant différentes architectures et je crois que c’est la clean architecture qui couvre la plus grande partie des cas d’usages et présente le plus de bénéfices.
Cette architecture est destinée à tous ceux qui veulent développer une API robuste, testable, scalable et qui peut facilement être comprise (et reprise !) par d’autres développeurs.
Vous pourrez alors ouvrir la solution(trouvable ici) dans Visual Studio et parcourir les fichiers des différents projets en parallèle de la lecture de cet article 🙂
Qu’est-ce qu’une architecture clean ?
A priori, si c’est écrit « clean » c’est que potentiellement c’est bon pour vous… alors regardons pourquoi 😉
Une architecture clean a pour caractéristiques d’être :
- Indépendante de tout framework / interface utilisateur / base de donnée
- Testable
- Bien organisée, c-à-d agréable pour les développeurs
Cette architecture se décompose en 4 couches distinctes: Domain, Application, Infrastructure et Presentation.
La règle est simple : seule une couche supérieure peut accéder à la couche inférieure.
Quand on rentrera dans le code de chaque couche, vous verrez que cette architecture rend « facile la façon de bien faire les choses et difficile la façon de mal faire les choses ». Cela vient principalement du fait qu’une sous-couche est référencée uniquement par une couche supérieure.
Schéma explicatif de l’Architecture Clean représentant les 4 couches et les relations entre chaque.
- Le Domain est indépendant
- L’Application référence le Domain
- L’Infrastructure référence l’Application
- La couche Presentation a la particularité de référencer la couche Infrastructure et l’Application.
C’est à dire que votre solution ressemblera à ça:
Arborescence d’une solution implémentant (la sainte) Architecture Clean.
Comme vous pouvez le voir, l’arborescence est claire, J’en détaillerai le contenu dans les sections suivantes.
Les différentes couches d’une architecture clean
Domain
C’est le cœur de votre API, il contient :
- Les entités
- Les énumérations
- Les objets de valeur
- Quelques exceptions
Son rôle principal est de définir les entités qui seront manipulées par notre API (par exemple TodoItem, TodoList …)
On y retrouve également les énumérateurs (par exemple « PriorityLevel » pour définir des droits dans notre application).
Application
La couche Application contient :
- Les Interfaces
- Les Models
- Les Commands/Queries
- Les Validators
- Des Exceptions
- De la logique (y’a toujours un peu de logique)
Son rôle principal est de manipuler les données du Domain.
L’architecture clean est souvent utilisée avec l’approche CQRS : on sépare les Commands (Ajouter [POST], Mettre à jour [PUT] et supprimer [DELETE]) des Queries (Récupérer [GET]).
C’est dans cette couche que vous définirez vos interfaces telles que : IDateTime.cs, ICsvFileBuilder, IApplicationDbContext …
L’injection des dépendances de cette couche se fait via un fichier DependencyInjection.cs, à la racine du projet, contenant une méthode AddApplication() qui ajoute les services tels qu’AutoMapper ou MediatR lors son appel dans le fichier Startup.cs
Infrastructure
La couche infrastructure peut contenir beaucoup de choses différentes comme :
- Vos services (DateTimeService, IdentityService, FileService).
- La gestion de la persistance de vos données (votre dbContext, vos migrations).
- L’injection des dépendances de votre couche (comme pour la couche Application) où l’on injectera les services.
Presentation
Ici on parle bien de votre interface utilisateur !
Alors allez-y, faites-vous plaisir : du React, du Vue (si vous êtes quelqu’un de très bien), du Blazor … !
Cette couche contient tout de même vos controllers, donc les endpoints de votre API:
- APIController (avec notre mediator)
- TodoItemsController
- TodoListsController
- etc …
Conclusion
Je pense que vous avez maintenant un bon aperçu de ce qu’est une architecture clean.
Pour moi, cette architecture a répondu a un grand nombre de questions/problématiques que j’ai rencontrées et j’espère qu’elle en fera autant pour vous !
Sources
- Repository github de la solution présentée avec 3 variantes (WebAPi , WebAPI+Angular et WebAPi +Blazor)
Articles similaires