Malgré mes 8 ans révolus d'expérience et ma veille continue, j'en apprends encore tous les jours. Merci Julien d'avoir mis des mots sur des concepts que je connaissais, et d'avoir raffraîchit ma mémoire avec des exemples concrets. L'une des meilleurs conf à ce sujet (IMO).
L'anti-corruption layer ça n'est pas juste pour faire des contrôles/validations pour garder le domaine "propre", c'est aussi pour isoler un domaine qui a son propre vocabulaire d'un autre domaine qui a un autre vocabulaire.
Merci pour cette vidéo ! J'aurai une question, avec l'utilisation d'une base de donnée telle que postgres, à quelle niveau dans l'architecture est-ce qu'on doit gérer l'atomicité des transactions ? Dans une application sans cet architecture généralement on les effectue au niveau des services mais dans notre cas où on veut éviter de mélanger les règles métiers et l'infrastructure base de donnée j'ai du mal à visionner cette partie.
Je n'ai jamais compris pourquoi mettre une interface pour un service ou un pojo, lorsqu'on a qu'une seule implémentation dans le projet. A part multiplier la complexité et le nombre de classe par 2, ca n'a aucun interet.
@@TristanOnGoogle Donc pour ce use case qui arrive une fois sur 1000, tous les projets Java doivent avoir 1000 interfaces inutiles, alors qu'il suffirait de créer l'interface en question lorsque le besoin apparait ? Pas un bon argument désolé.
@@zartcolwing3218 oui en TU et en test d'intégration et je n'ai aucune interface. Stack tech : Java, Spring, Mockito, Junit5. je ne vois pas le rapport et de toute facon si vous avez besoin d'écrire du code en dehors des tests pour tester un block de code existant, c'est une très mauvaise pratique.
Malgré mes 8 ans révolus d'expérience et ma veille continue, j'en apprends encore tous les jours. Merci Julien d'avoir mis des mots sur des concepts que je connaissais, et d'avoir raffraîchit ma mémoire avec des exemples concrets.
L'une des meilleurs conf à ce sujet (IMO).
une référence, très bien préparé et expliqué !
Super intéressant merci !
super video avec une démarche concrete et claire
Trop bien Fait ! Très clair
L'anti-corruption layer ça n'est pas juste pour faire des contrôles/validations pour garder le domaine "propre", c'est aussi pour isoler un domaine qui a son propre vocabulaire d'un autre domaine qui a un autre vocabulaire.
Super demo. Thx
Merci pour cette vidéo !
J'aurai une question, avec l'utilisation d'une base de donnée telle que postgres, à quelle niveau dans l'architecture est-ce qu'on doit gérer l'atomicité des transactions ? Dans une application sans cet architecture généralement on les effectue au niveau des services mais dans notre cas où on veut éviter de mélanger les règles métiers et l'infrastructure base de donnée j'ai du mal à visionner cette partie.
Soit dans une couche au-dessus du domaine, soit avec des annotations custom
Je n'ai jamais compris pourquoi mettre une interface pour un service ou un pojo, lorsqu'on a qu'une seule implémentation dans le projet. A part multiplier la complexité et le nombre de classe par 2, ca n'a aucun interet.
C'est pour respecter les bonnes pratiques, notamment réduire le couplage fort (2 ème règle du S.O.L.I.D.)
Parce que à tout moment tu peux vouloir substituer une interface de test à ton implémentation principale par exemple.
@@TristanOnGoogle Donc pour ce use case qui arrive une fois sur 1000, tous les projets Java doivent avoir 1000 interfaces inutiles, alors qu'il suffirait de créer l'interface en question lorsque le besoin apparait ? Pas un bon argument désolé.
@@Monsieur_Anderson Et le besoin apparait dès que vous voulez tester vos controlleurs. Vous testez vos controllers n'est-ce pas?
@@zartcolwing3218 oui en TU et en test d'intégration et je n'ai aucune interface. Stack tech : Java, Spring, Mockito, Junit5. je ne vois pas le rapport et de toute facon si vous avez besoin d'écrire du code en dehors des tests pour tester un block de code existant, c'est une très mauvaise pratique.