Refacto - Strategy Pattern en .NET - cas pratique et refacto avec Clean Architecture

Objo : expliquer mon point de vue sur les méthodo magiques - ne pas over-engineer un système simple - toujours s’adapter au contexte

Introduction

On veut tous devenir le meilleur developer. Être rapide, efficace, le 10x Developer qui créer du code propre et maintenable du 1er coup. Moi le 1er.

Et dans cette quête du Grâal, qui nous pousse à explorer toujours plus de concepts, de patterns, arrive toujours un moment où l’on se retrouve déconnecté de la réalité terrain. Clean Architecture, DDD, Ports & Adapters sont sur toutes les lèvres - mais sont-ce des solutions magiques qui résolvent toutes les problèmatiques de l’industrie logicielle ?

La réponse magique: ça dépend.

Et si vous fournissez cette réponse à vos stackholders - vous ne vous tromperez jamais … mais avec ce genre de réponse ce n’est pas garanti que vous restiez très longtemps en poste non-plus.

Parce que oui, notre valeur en temps que développeur, et notre responsabilité, c’est de fournir une réponse à cette question.

ça dépend de quoi? Pour le coup nous avons notre point de départ:

Le contexte fait tout

Et notre rôle en tant que developpeur, c’est justement de compiler le plus de données possible concernant ce fameux contexte pour cerner la problématique au mieux, et pouvoir remplacer la réponse “ça dépend” - par une solution concrète, sur-mesure, pour répondre à ce problème du moment.

Notre pensée est la capacité à réfléchir, raisonner et tirer des conclusions en se basant sur nos expériences, nos connaissances et nos visions profondes Jim Taylor

Notre cerveau est donc au service de la résolution du problème - et nous permet de proposer des solutions les plus efficientes. En ce sens, quelqu’un qui agite sans cesse le même marteau de la Clean Architecture, peu importe le type de projet - parfois de manière despotiques - ne remplit pas son rôle.

Pour ma part, c’est toujours un long process, une vague:

1. J’apprends quelque chose de nouveau (les Domain Events, une Enumeration Pattern )
2. Je le vois partout, et donc je l’applique partout maladroitement au début
3. La prise de recul: Je comprends (après plus ou moins longtemps - plus ou moins de tentative) l’essence même et le problème que résout ce concept - ses avantages et ses inconvénients - pour en dessiner les contours de son utilisation.

Sortir le Bazooka pour tuer une mouche

Dans cette série, j’essaye d’illustrer des use cases - pour rendre plus accessible les concepts - et les appliquer dans de vrais projets - sans parler de créer une solution SaaS multi-tenants soutenant un traffic de plusieurs milliers d’utilisateurs sur plusieurs continents.

J’adore cet exercice, où l’on essaye de justifier des concepts haut-niveau: la separation des responsabilités en couches, l’importance de la dependency inversion - de la vitalité d’une bonne encapsulation et d’une bonne abstraction, tout ça sur une base de système simpliste - qui de surcroît fonctionne très bien pour l’usage qu’on en a.

Comme base d’article: comment appliquer les principes de bonne conception logiciel sur un système simple

Articles exemples:

Le sujet: Une feature sur un portail applicatif, qui permet d’afficher des notifications à l’utilisateur lorsqu’il se connecte :

;

Les expressions prennent ici tout leur sens: le pragmatisme.

Moi, ça m’ait arrivé après avoir lu Clean Architecture (deux fois, avec 1 an d’interval), puis DDD de Eric Evans, et après avoir manger des 100ène d’heures de formation sur le DDD, la Clean Architecture.

C’est super efficace pour un projet au long cours - sur plusieurs

Attirer l’Attention : Démarrez avec une anecdote, une question ou une statistique qui montre l’importance d’une architecture propre et organisée pour les projets de développement logiciel.

Présentation de l’Article : Expliquez brièvement ce que les lecteurs peuvent attendre de l’article, à savoir un guide détaillé sur la manière de refacturer un projet existant vers la Clean Architecture tout en maintenant l’engagement du lecteur.

1. Les Enjeux d’une Architecture Mal Structurée Identifier les Problèmes : Mettez en évidence les problèmes courants auxquels les projets avec une architecture mal structurée peuvent être confrontés, tels que la complexité croissante, la difficulté de maintenance et les dépendances confuses.
2. Introduction à la Clean Architecture Comprendre les Fondamentaux : Donnez un aperçu de base de la Clean Architecture en expliquant ses principes clés, tels que la séparation des préoccupations, la dépendance à sens unique et la centralité du domaine.
3. Évaluation de Votre Projet Actuel Analyser l’Architecture Actuelle : Montrez comment évaluer l’architecture actuelle de votre projet en identifiant les zones problématiques, les dépendances inutiles et les éléments qui nécessitent une amélioration.
4. Planification du Refactoring Élaborer un Plan : Détaillez l’approche que vous prendrez pour le refactoring. Expliquez comment vous allez diviser le processus en étapes gérables et assurez-vous de mentionner la minimisation des risques.
5. Diviser et Conquérir : Séparation des Responsabilités Créer des Modules Cohérents : Expliquez comment diviser vos fonctionnalités en modules distincts selon les principes de la Clean Architecture. Mettez l’accent sur la séparation des responsabilités pour rendre chaque module autonome.
6. Préserver la Logique Métier : Les Cas d’Utilisation Identifier les Cas d’Utilisation : Montrez comment identifier et extraire les cas d’utilisation essentiels de votre application. Discutez de la manière dont ils peuvent être encapsulés dans des domaines distincts.
7. Concevoir les Interfaces des Modules Définir les Interfaces : Détaillez comment concevoir des interfaces claires pour chaque module, en définissant les contrats et les dépendances avec précision. Expliquez comment ces interfaces favorisent le découplage.
8. Adapter les Couches d’Infrastructure Gérer les Dépendances : Expliquez comment adapter les couches d’infrastructure, y compris les DbContexts, pour refléter la séparation des responsabilités et les interfaces définies.
9. Tests et Validation Maintenir la Qualité : Discutez de l’importance des tests dans le processus de refactoring. Expliquez comment vous allez valider chaque étape pour vous assurer que l’application fonctionne toujours correctement.
10. Implémentation Étape par Étape Refactoring Pas à Pas : Détaillez chaque étape du refactoring en expliquant les modifications apportées à chaque module. Utilisez des exemples concrets pour montrer comment la Clean Architecture est mise en œuvre. Conclusion Résultats Obtenu : Résumez les résultats de votre refactoring et mettez en évidence les avantages de la Clean Architecture pour votre projet.

Encouragement à Agir : Encouragez les lecteurs à envisager de mettre en œuvre des principes de Clean Architecture dans leurs propres projets, en partageant des ressources ou des guides utiles pour approfondir leurs connaissances.

Ressources Supplémentaires (facultatif) Liens Utiles : Fournissez des liens vers des ressources supplémentaires, comme des exemples de projets open source avec une Clean Architecture, des vidéos explicatives, etc.

Introduction Captivante (Exposition) :

Dans cette phase, vous exposez le contexte en utilisant une anecdote ou une situation qui engage le lecteur. Cela établit le ton et prépare le terrain pour la notion technique que vous allez explorer. Cette étape est similaire à la première partie de la “Courbe Narrative” de Vonnegut, où l’histoire commence à se développer.

Une longue soirée d’été, qu’on aurait pu passer à siroter un jus sur la terrasse, mais qu’on se retrouve bloquer devant l’écran à débugguer une API Notification qui ne fonctionne pas. (trouver un bug) Je ressasse le déroulement de l’action - une

Contexte et Importance (Incident Perturbateur) :

Ici, vous introduisez la notion technique comme réponse au besoin ou au problème exposé dans votre introduction. Vous pouvez montrer comment cette notion peut résoudre des défis et améliorer les choses. C’est l’équivalent de la partie de l’histoire où l’incident perturbateur agite la situation initiale.

Développement de la Notion (Développement) :

Cette partie correspond à la phase de développement de l’histoire où vous expliquez les concepts techniques. Vous construisez progressivement l’histoire de la notion, fournissant des détails tout en gardant une narration fluide et engageante.

Avantages et Cas d’Utilisation (Climax) :

Vous pouvez présenter des exemples concrets qui illustrent comment la notion a été utilisée avec succès. C’est comme le climax d’une histoire, où le protagoniste atteint son objectif principal grâce à l’utilisation de la notion technique.

Conseils Pratiques (Résolution) :

Intégrez des conseils pratiques comme des leçons apprises ou des recommandations pour appliquer la notion. Cela équivaut à la phase de résolution dans laquelle les personnages tirent des enseignements de leurs expériences.

Appel à l’Action (Retour à la Normale) :

Terminez en invitant les lecteurs à partager leurs expériences ou à interagir avec votre contenu. Cela équivaut au retour à la normale dans une histoire, où les personnages continuent leur vie après avoir surmonté les défis.

Signature Personnelle (Conclusion) :

Comme une sorte de conclusion, réaffirmez votre expertise et votre passion pour le développement .Net sur Azure et l’architecture logicielle.

Hashtags Pertinents (Thème Récurrent) :

Utilisez des hashtags liés à la notion pour renforcer le thème et augmenter la visibilité de votre post.