Excellent pour comprendre ce concept. J'en entends parler de plus en plus, il me fallait un exemple concret, merci pour les travaux. Bsarthek l'accent du Sud, c'est du propre haha.
Petit retour: non ça n'est pas trop déstructuré. Je trouve le format chouette. T'es pas en galère, tu tâtonnes sur un nouvelle techno, c'est plutôt sympa :) Peut être éditer la description avec des liens vers les références dont tu parles :)
Super intéressant. Merci. C'est cool d'avoir une vision de quelqu'un qui débute sur le sujet de l'hexagone. C'est pas un sujet forcément simple mais tu l'as rendu très accessible. Le format en live était cool ça change des vidéos "formaté" J'espère que tu fera d'autres vidéos sur le sujet :)
Merci beaucoup le pro Lior ! Une suggestion.. Et si tu nous faisait comme toujours un super cours sur la sécurisation des sites et particulièrement le chiffrement
c'est mieux qu'une vidéo préparée, car tout est naturel et toi-même tu ne sais pas ce que tu va faire par coeur, on comprend mieux. Il y a des nouvelles vidéos sur le sujet?
Super pédagogie Lior, via la pratique + TDD super. Juste un point : ton répertoire domain, aurait dû s'appeler Core. En hexagonal Archi. : Core layer = Domain layer + Application layer, et c'est dans l'Application layer que doivent se trouver les UseCases, et dans la Domain layer que doivent se trouver les Entity(métiers et business logic de celles-ci). ;o). Soit Core/Domain/les entités,etc et Core/Application/les uses cases. Voici une vidéo très courte et synthétique qui peut éclaircir un peu : th-cam.com/video/JubdZIdLQ4M/w-d-xo.html
Merci Lior comme d'habitude cette vidéo est extra. Petite question aurais tu des ressources ou des conseilles pour "brancher" Api Platform sur une clean architecture ?
salut Lior cest Bikach du slack Wealcome ;) Petites remarques amicale sur certain passage, j'écris le com en même temps que je regarde la vidéo, ces remarques ne tiennent qu'à moi je suis pas expert sur le sujet ;) [43:33] -> je pense pas que c'est utile de faire l'assert sur l'objet, c'est un détail d'implementation, c'est le usecase que tu tests pas les objets [59:36] -> Tu devais mettre en place un port avant de créer ta inmemory puisque celle-ci est censé l'implémenter ;) et ta méthode "save" ne devrait rien retourner. Pour vérifier que le post est bien inséré dans la Array, tu peux soit passer une Array dans le constructeur de ta InMemrory, soit ajouter une méthode pour récupérer un Post de ta Array dans la InMemory, il faudra juste faire attention à ne pas ajouter celle-ci dans le port si tu en as pas besoin en prod [1:07:00] -> Tu viens de créer le port (linterface) et tu as fait l'erreur que j'ai cité plus haut. Tu ajoutes findOne() à celle-ci mais en l'état, coté prod, tu en as pas besoin. Ton Usecase c'est de créer un Post, tu n'aura pas besoin pour le moment de le récupérer. Tdd c'est aussi écrire le minimum de code, celui que tu as besoin à l'instant T. c'est pour ça que je pense que c'est mieux de créer d'abord ton port et ensuite tu adapte ta Inmemory qui l'implemente pour tes tests. [1:12:40] -> tu a créé le vrai adapter dans le dossier concernant les tests, j'imagine que cette erreur est dù à live ;) dommage ça aurait été instructive de montrer le coté infra dans le dossier src avec infra/adapter et domain/port (tu le fais plus tard avec le controler ;) ) [1:39:20] -> Peros j'aurai mis le try/catch dans la méthode validate(), je pense que c'est de sa responsabilité, et ça laisserai ta méthode execute() moins chargée. Après je suis comme toi niveau exception je sais pas trop si c'est le repo, l'entity ou le usecase qui doit les gérer lol Toujours au top Lior, mes remarques ne sont peut être pas justes si quelqu'un à des corrections à apporter n'hesitez pas
Salut,c est tres bienn ce que tu fais. Moi, actuellement, on m'embète avec le BDD (une application du TDD en prenant n compte les fonctionnalités ?) et le DDD, si un jour tu sais pas de quoi causer, ce serait chouette. Merci
Salut Lior, juste une question qui me vient à la fin de la vidéo. Peut-on considérer que le dév Hexagonal est un peu le dév en couche un peu plus poussé ?? Merci pour tes vidéo, j'adore et j'adhère ;)
Just do not forget SQL injection, so the input data should be verified, escaped, which we can easily to forget when we code from scratch :) even when we want ports->adapters architecture
Pour les uuid, c'est bien de les utiliser quand on ne veut pas exposer publiquement un id mais en tant que champ simple, pas en PK. Par exemple, stocker l'avatar d'un user dans un dossier publique en ne pouvant utiliser son pseudo (possiblement pas unique). On utilise l'uuid pour nommer le dossier de manière unique et l'exposer (affichage de l'avatar). Cest bien aussi pour éviter de faire appel à la db pour récupérer l'id après insertion d'une donnée. Là aussi sans l'utiliser en PK. On insère la donnée et on fait les éventuelles liaisons via l'uuid. Par contre en PK c'est une mauvaise idée. C'est un type bien plus gros à stocker qu'une id. Ça n'offre pas les mêmes perf d'index qu'un int. Et à stocker en mémoire lors de process des grosses data, ça pique. Il faut aussi imaginer une db avec des centaines de milliers ou millions d'uuid en PK ou FK. L'horreur ! Je ne l'utilise donc que quand j'ai besoin d'un identifiant unique que je dois exposer publiquement, et pas en PK ni FK.
C'est bien vos histoires de TDD, DDD, clean architecture et compagnie, pour faire un CRUD basique ça te prend juste deux semaines parce que tu veux que tout soit testé et respecte toutes les règles... Une vraie perte de temps, faites des tests uniquement pour les éléments métier complexe (pas sur du CRUD à la con). Foutez tous vos controllers dans le même dossier. Franchement on s'en fou, on a des IDE aujourd'hui. Qui va vraiment regarder dans les dossiers directement ? Tu fais ctrl-shift-n, tu tapes Blog et tu vas dans ton controller...
Evidemment, ça s'applique pour des applications très larges où tu as parfois des dizaines de Controllers, des centaines de Listeners/Subscriber, des dizaines et des dizaines de models et de services. Mais oui c'est une critique qui est souvent faite :) Et même un code basique a besoin de tests pour assurer sa propre qualité. Donc tant qu'à faire coder les tests directement :)
Le problème de mettre tout dans un même dossier, quand on a une grosse application ayant plusieurs briques distinctes, c'est que quand un nouveau dev arrive, il se retrouve devant un dossier avec des centaines de modèles, evenlistener, contrôleurs,... Il ne peut pas vraiment "juste taper Blog" pour avoir une vision globale du truc. Je ne parle même pas de construire quelque chose de conséquent sans tests. Le nouveau débarque, modifie un truc et ça pète ailleurs car aucun test n'a été mis en place. Surtout face à une app mono... Oui, c'est se prendre le chou pour pas grand chose pour une petite app et si on restera seul dessus, mais ça ne l'est pas quand on travaille en équipe sur un truc conséquent, avec des mises en prod rapides. J'en ai croisé des projets où tu arrives et dois te familiariser rapidement aux projets, avec zéro doc, zéro phpdoc (ou sommaire), zéro archi, zéro tests... Ton cauchemar commence quand on te demande de modifier ou ajouter quelque chose.
Excellent pour comprendre ce concept. J'en entends parler de plus en plus, il me fallait un exemple concret, merci pour les travaux. Bsarthek l'accent du Sud, c'est du propre haha.
Super vidéo, très instructif ! Ton humilité et ta façon de parler rendent le concept moins lourd , c’est vraiment top ! Merci pour le partage
Merci beaucoup à toi :)
Super format merci d'avoir partagé tes progrès et expérimentations. Super boulot Lior.
Super frangin. Très précis et compréhensif,
Bravo.
Instructif, intéressant et suffisamment décalé pour ne pas être relou malgré les tâtonnements.
Continue c'est top
Merci énormément :)
Super vidéo. Je comprends bien l’intérêt de cette architecture hexagonale. Franchement beau boulot !
Merci beaucoup David :)
Bravo, tu as bien expliqué l'architecture
Merci beaucoup ❤❤❤❤
Petit retour: non ça n'est pas trop déstructuré. Je trouve le format chouette. T'es pas en galère, tu tâtonnes sur un nouvelle techno, c'est plutôt sympa :)
Peut être éditer la description avec des liens vers les références dont tu parles :)
Dès que j'ai le temps ! :p merci beaucoup !
Hello Lior ce serait bien d'avoir une suite ameliorer , avec une implementation framework sf ou laravel .sinon très bon contenu, très enrichissant
C'est noté💪
Super intéressant. Merci. C'est cool d'avoir une vision de quelqu'un qui débute sur le sujet de l'hexagone.
C'est pas un sujet forcément simple mais tu l'as rendu très accessible.
Le format en live était cool ça change des vidéos "formaté"
J'espère que tu fera d'autres vidéos sur le sujet :)
On verra dans le futur, merci en tout cas :)
Merci a toi super pedagogie pour debuter dans la clean archi.
J'ai enfin compris ce qu'est un "InMemory" :-)
Merci à toi d'avoir regardé :)
Attention :) Clean Archi Onion Archi. Hexagonal Archi., ça en parle un peu : th-cam.com/video/JubdZIdLQ4M/w-d-xo.html
Merci pour cette vidéo très instructive pour un débutant sur le sujet comme moi!
Merci à toi d'avoir regardé :)
Ouais c'est pas mal, j'aime bien le format, l'idée et le sujet
Merci :)
Merci beaucoup le pro Lior ! Une suggestion.. Et si tu nous faisait comme toujours un super cours sur la sécurisation des sites et particulièrement le chiffrement
Je suis très nul en sécurité :x
Très bonne vidéo, merci
De rien merci à toi :)
Excellente vidéo merci
Merci a toi ♥️
c'est mieux qu'une vidéo préparée, car tout est naturel et toi-même tu ne sais pas ce que tu va faire par coeur, on comprend mieux. Il y a des nouvelles vidéos sur le sujet?
Super pédagogie Lior, via la pratique + TDD super.
Juste un point : ton répertoire domain, aurait dû s'appeler Core. En hexagonal Archi. : Core layer = Domain layer + Application layer, et c'est dans l'Application layer que doivent se trouver les UseCases, et dans la Domain layer que doivent se trouver les Entity(métiers et business logic de celles-ci). ;o). Soit Core/Domain/les entités,etc et Core/Application/les uses cases. Voici une vidéo très courte et synthétique qui peut éclaircir un peu : th-cam.com/video/JubdZIdLQ4M/w-d-xo.html
merci , super vidéo
Merci à toi :)
Merci Lior 😃
Merci à toi :)
Très bien !!!!
Merci !
Merci Lior
Merci à toi :)
Excellente vidéo merci! Mais j'ai une petite question bête :), en quoi l'entity Post à 50:10 n'est pas un DTO ?
Bonne question, je viens de revisionner et a priori, c'en est un vu qu'il ne porte aucune logique :D :D
Merci Lior comme d'habitude cette vidéo est extra. Petite question aurais tu des ressources ou des conseilles pour "brancher" Api Platform sur une clean architecture ?
Pas de ressources particulières hélas mais c'est un sujet intéressant que je vais creuser :)
T'es pas dans le coup Lior, dans l’hexagone c'est le bordel justement à cause de la lutte des classes ! ;p
40:22 ça fait trop du bien aux oreilles ahahaha
:D
Super !!! Merci pour le retour d'expérience !!! Tu as plus avancé que moi. :-D
Merci à toi d'avoir regardé :)
salut Lior cest Bikach du slack Wealcome ;)
Petites remarques amicale sur certain passage, j'écris le com en même temps que je regarde la vidéo, ces remarques ne tiennent qu'à moi je suis pas expert sur le sujet ;)
[43:33] -> je pense pas que c'est utile de faire l'assert sur l'objet, c'est un détail d'implementation, c'est le usecase que tu tests pas les objets
[59:36] -> Tu devais mettre en place un port avant de créer ta inmemory puisque celle-ci est censé l'implémenter ;) et ta méthode "save" ne devrait rien retourner.
Pour vérifier que le post est bien inséré dans la Array, tu peux soit passer une Array dans le constructeur de ta InMemrory, soit ajouter une méthode pour récupérer un Post de ta Array dans la InMemory, il faudra juste faire attention à ne pas ajouter celle-ci dans le port si tu en as pas besoin en prod
[1:07:00] -> Tu viens de créer le port (linterface) et tu as fait l'erreur que j'ai cité plus haut. Tu ajoutes findOne() à celle-ci mais en l'état, coté prod, tu en as pas besoin. Ton Usecase c'est de créer un Post, tu n'aura pas besoin pour le moment de le récupérer. Tdd c'est aussi écrire le minimum de code, celui que tu as besoin à l'instant T. c'est pour ça que je pense que c'est mieux de créer d'abord ton port et ensuite tu adapte ta Inmemory qui l'implemente pour tes tests.
[1:12:40] -> tu a créé le vrai adapter dans le dossier concernant les tests, j'imagine que cette erreur est dù à live ;) dommage ça aurait été instructive de montrer le coté infra dans le dossier src avec infra/adapter et domain/port (tu le fais plus tard avec le controler ;) )
[1:39:20] -> Peros j'aurai mis le try/catch dans la méthode validate(), je pense que c'est de sa responsabilité, et ça laisserai ta méthode execute() moins chargée. Après je suis comme toi niveau exception je sais pas trop si c'est le repo, l'entity ou le usecase qui doit les gérer lol
Toujours au top Lior, mes remarques ne sont peut être pas justes si quelqu'un à des corrections à apporter n'hesitez pas
Merci Bikach !
comment créer les applications tels que le frontend et l'administration avec un seul noyau de symfony
Salut,c est tres bienn ce que tu fais.
Moi, actuellement, on m'embète avec le BDD (une application du TDD en prenant n compte les fonctionnalités ?) et le DDD, si un jour tu sais pas de quoi causer, ce serait chouette.
Merci
Merci, je débute dans ces domaines, je me documente et j'essai d'appliquer mais c'est pas toujours simple x:
Salut Lior, juste une question qui me vient à la fin de la vidéo. Peut-on considérer que le dév Hexagonal est un peu le dév en couche un peu plus poussé ?? Merci pour tes vidéo, j'adore et j'adhère ;)
Merci à toi, comme je ne connais que trop peu le sujet pour répondre, j'ai trouvé ça sur Google : tpierrain.blogspot.com/2016/04/hexagonal-layers.html
Salut Lior, merci pour la vidéo. Fred Pouchery ? C'est bien cela ? J'ai cherché des variantes mais je n'ai rien trouvé
Frédéric Bouchery, vas voir toutes ses conférences ici : th-cam.com/play/PL1uti1wPH3hRDD_873WhrhDyz6XY-1JnU.html
Uuid c’est idem le guid en c# c’est une instance d’objets ?
Uuid c'est une chaine de caractères normalement :)
Just do not forget SQL injection, so the input data should be verified, escaped, which we can easily to forget when we code from scratch :) even when we want ports->adapters architecture
Yes ofc, I was in a hurry right there :x
Il y a aussi Jonathan Lefebvre sur OpenClassrooms
J'irai voir, merci :)
Mon prof
Dedans, dehors, dedans, dehors :D :D :D, oui je le connait, le concept. Ça s'appelle "boundary line" :D
:) :)
Pour la DDD voici un petit cours sur openclassroom : openclassrooms.com/fr/courses/5647281-concevez-le-domaine-metier-avec-uml
Merci Saif, j'ai vu ce cours en effet très sympa :)
ça commence à 10:05
Ca a été corrigé !
Ah thomas boileau c'est qui stp? ?
Google > Thomas Boileau
Pour les uuid, c'est bien de les utiliser quand on ne veut pas exposer publiquement un id mais en tant que champ simple, pas en PK. Par exemple, stocker l'avatar d'un user dans un dossier publique en ne pouvant utiliser son pseudo (possiblement pas unique). On utilise l'uuid pour nommer le dossier de manière unique et l'exposer (affichage de l'avatar).
Cest bien aussi pour éviter de faire appel à la db pour récupérer l'id après insertion d'une donnée. Là aussi sans l'utiliser en PK. On insère la donnée et on fait les éventuelles liaisons via l'uuid.
Par contre en PK c'est une mauvaise idée. C'est un type bien plus gros à stocker qu'une id. Ça n'offre pas les mêmes perf d'index qu'un int. Et à stocker en mémoire lors de process des grosses data, ça pique.
Il faut aussi imaginer une db avec des centaines de milliers ou millions d'uuid en PK ou FK. L'horreur !
Je ne l'utilise donc que quand j'ai besoin d'un identifiant unique que je dois exposer publiquement, et pas en PK ni FK.
Petite update du commentaire vu qu'il est mis en avant. Histoire que tout le monde comprenne.
Très bonne précision :)
C'est bien vos histoires de TDD, DDD, clean architecture et compagnie, pour faire un CRUD basique ça te prend juste deux semaines parce que tu veux que tout soit testé et respecte toutes les règles...
Une vraie perte de temps, faites des tests uniquement pour les éléments métier complexe (pas sur du CRUD à la con).
Foutez tous vos controllers dans le même dossier. Franchement on s'en fou, on a des IDE aujourd'hui. Qui va vraiment regarder dans les dossiers directement ? Tu fais ctrl-shift-n, tu tapes Blog et tu vas dans ton controller...
Evidemment, ça s'applique pour des applications très larges où tu as parfois des dizaines de Controllers, des centaines de Listeners/Subscriber, des dizaines et des dizaines de models et de services. Mais oui c'est une critique qui est souvent faite :)
Et même un code basique a besoin de tests pour assurer sa propre qualité. Donc tant qu'à faire coder les tests directement :)
Le problème de mettre tout dans un même dossier, quand on a une grosse application ayant plusieurs briques distinctes, c'est que quand un nouveau dev arrive, il se retrouve devant un dossier avec des centaines de modèles, evenlistener, contrôleurs,... Il ne peut pas vraiment "juste taper Blog" pour avoir une vision globale du truc.
Je ne parle même pas de construire quelque chose de conséquent sans tests. Le nouveau débarque, modifie un truc et ça pète ailleurs car aucun test n'a été mis en place.
Surtout face à une app mono...
Oui, c'est se prendre le chou pour pas grand chose pour une petite app et si on restera seul dessus, mais ça ne l'est pas quand on travaille en équipe sur un truc conséquent, avec des mises en prod rapides.
J'en ai croisé des projets où tu arrives et dois te familiariser rapidement aux projets, avec zéro doc, zéro phpdoc (ou sommaire), zéro archi, zéro tests... Ton cauchemar commence quand on te demande de modifier ou ajouter quelque chose.