idirene-youcef
commented
7 months ago Pour mieux expliquer le premier point, il faudrait qu'on rajoute un module qui nous permettra de mettre
- les serviceInterface les et les model (c'est des record) ✔️
- les exception interne (MappingException / TechnicalException)
- Enum ainsi que les objets de validation errors si on choisi de faire une validation spécifique pas forcement nécessaire car il existe un meilleur moyen qui utilise les ControlerAdvice
- Les objet de search dans le cas ou on utilise un dto (ex : 5 critère de recherche)
cela nous facilitera un peut la tache et nous permet de mettre les mapper dans la couche service (le module web contiendra que les implémentation des client (si communication avec d'autre api's) et les contrôleurs )
En gros tout ce qu'on pourrait utilisé dans les différent modules de l'application, il sera importer par service ( ou dans ton cas data ) ça permettera de mettre les mapper dans le module service et évité de les mettre dans web ça fait partie de la logique métier Sortir donc les service du module service pour les mettre dans le nouveau module (on peut réutilisé ce module pour redévelopper les fonctionnalité par exemple) ex : on veut développer les même méthode mais la couche data utilisera une DBA no sql (nouveau module serviceNoSQL qui import le module api qu'on a créer)
je pense que le mieux c'est de faire une séparation par package au niveau du module service que ta créer a voir si c'est mieux
Pour le mapper le mieux c'est de créer une interface avec deux méthode mapToModel / mapToEntity ou autre et chaque mapper devra l'implémenter pour avoir le même nom de methode
pour le nommage des méthode au niveau du service ou le controleur le mieux c'est de ne pas mettre getSpeciality mais juste le get ou find suffit vu qu'on est dans le contrôleur concerné pareil pour les méthode update et autre
Je pense pas besoin de créer trop de variable dans la méthode meme si pour debug c'est bien mais on peut le mettre directement dans la méthode exemple : ✔️
final Speciality speciality = SpecialityMapper.toSpeciality(specialityReq); final Speciality updatedSpeciality = specialityService.updateSpeciality(speciality); final SpecialityResp specialityResp = SpecialityMapper.toResp(updatedSpeciality);
devient
final Speciality speciality = SpecialityMapper.toSpeciality(specialityReq); final SpecialityResp specialityResp = SpecialityMapper.toResp(specialityService.updateSpeciality(speciality));
J'aimerais bien changer le nom du module data -> core/domain/api pour moi data c'est tres proche de service, apres vu le découpage je comprend ce que ta fait mais j'ai l'impression qu'il manque une couche
Exemple API contient les serviceInterface sans les implémentation / dto ce module sera injecté dans le module service (je te confirme ça)
2 - pour les response et request pas besoin de créer des objet on pourrait utilisé des records nouveauté de JAVA c'est mieux aussi ( faut que je vérifie un truc car ya moyen de faire une petite validation sur l'objet aussi)
si on se base sur une architecture Hexagonal ( ya de forte chance qu'on change un peu la structure mais pas besoin je pense)
...