Skip to content

Évolution de l'Architecture : Du Service au Manager

Au cours du développement, la structure initiale Controller <-> Service <-> Repository a montré ses limites (Services "fourre-tout"). Un refactoring complet a été opéré pour adopter des patterns plus granulaires.

đŸ—ïž Nouveaux Patterns implĂ©mentĂ©s

  • Managers : Responsables exclusifs des opĂ©rations CRUD et de l'interaction avec les Repositories. Ils portent la logique de persistance (ex: validateAndSave).
  • Mappers : DĂ©diĂ©s Ă  la transformation bidirectionnelle Entity <-> DTO. Cela isole la logique de prĂ©sentation de la logique de donnĂ©es.
  • Traits : UtilisĂ©s pour la rĂ©utilisabilitĂ© horizontale (ex: gestion automatique des createdAt/updatedAt et factorisation du validateAndSave).
  • Utils : Classes utilitaires pures pour des besoins structurels (gĂ©nĂ©ration UUID Base 62, mĂ©ta-donnĂ©es de pagination).

🧠 Pourquoi ce choix ?

Cette structure réduit drastiquement la dette technique. En séparant les responsabilités, chaque classe devient plus courte, plus lisible et, surtout, beaucoup plus simple à tester unitairement.

Factory des Expéditeurs (Carriers)

Pour gérer les différents transporteurs sans répéter de la logique, j'ai mis en place une Factory.

Fonctionnement

On utilise un champ technical_name en base de données (table carrier) qui est mappé sur un Enum PHP. Cela permet de centraliser la logique de création :

  1. La table carrier contient le nom technique (ex: la_poste).
  2. Le backend utilise ce nom pour instancier la bonne logique via la Factory.
  3. Le principe DRY est respecté car toute la gestion des transporteurs passe par ce point unique.