8) Use Cases
Maintenant que nous sommes confiants vis-à-vis de nos tests nous allons pouvoir commencer à refactorer.

Nous pouvons démarrer en splittant notre principal hostpot : PartieDeChasseService.

Pour ce faire, nous allons utiliser la stratégie Divide and Conquer :
Prendre du temps pour comprendre ce qu'est la
Clean ArchitectureNotamment la notion de
Use Case
Extraire 1
Use Casepar méthode duServiceAméliorer la définition de notre architecture via nos tests
Archunit
Extraire un premier Use Case
Utiliser les fonctionnalités de notre
IDEpour extraire la méthodeDémarrerRefactor->Extract->Extract ClassPenser à configurer l'extraction de la méthode en
Create delegating Wrapper

Voici le résultat :
La classe
PartieDeChasseServicedélègue maintenant les appels de la méthodeDémarrerà notreUse CaseAinsi, nous compilons et nos tests sont toujours au vert
On adapte les tests de ce
Use Case
Répliquer cela pour tous les Use Cases
A la fin, le PartieDeChasseService ressemble à cela :
Supprimer le service
L'arborescence de notre projet ressemble désormais à celà :
Il ne reste plus qu'un seul appelant du srvice
PartieDeChasseService->ScenarioTestsNous allons rediriger les appels des tests vers les
Use Case
On peut maintenant supprimer la classe
PartieDeChasseServicede manière totalementsafe

On place l'ensemble des
Exceptionsau plus proche de leur utilisation (dans le namespaceUseCases)

Notre architecture ressemble maintenant à ça

Mise à jour des règles ArchUnit
Impact sur l'analyse comportementale
Après avoir extrait les Use Cases, nous avons "tué" le hotspot identifié par codescene :

Nous avons simplement divisé cette grosse classe "fourre-tout" en plus petites unités, avec des dépendances clairement identifiées qu'on va pouvoir tranquillement refactorer.
Nouveau rapport SonarCloud disponible ici.
Reflect
Quel est l'impact sur le design ? les tests ?
En quoi pouvons nous parler ici de
Screaming Architecture?

Last updated
Was this helpful?