Bonjour à tous,

Dans cet article, je vais passer en revue une architecture clean d'une API, en .net core 3.0, proposée par Jason Taylor lors de la NDC Sydney 2019.

En tant que développeur junior, 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.

Je pense que le meilleur moyen de suivre cet article est d'ouvrir un shell et de lancer ces deux commandes qui vous créeront en local une copie de la solution que présente (en vidéo) Jason Taylor lors de la conférence:

dotnet new --install Clean.Architecture.Solution.Template
dotnet new ca-sln

Vous pourrez alors ouvrir la solution dans VS 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" comme dirait Jason Taylor. 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

• Vidéo Clean Architecture.
• Repository github de la solution présentée.

Happy Coding ! 🖖