conf.md

bonjour à tous on va démarrer donc l'objectif de la session c'est de discuter clean architecture et architecture hexagonal et puis on va voir comment justement est ce qu'on arrive à ce type d'architecturé quand on part d'une organisation sur un découpage relativement technique donc moi je suis éligible et ça fait un petit peu plus de dix ans que je fais ce que je fais du développement je fais partie d'une tribu qui s'appelle software craft and cheap à octo technology et puis j'ai également une activité de conseil d'accompagnement sur des pratiques de qualité logicielle et puis également la partie formation sur des sujets qui me tiennent à coeur donc notamment le design applicatifs la chine architecture et l'architecturé hexagonal en font partie et puis également tout ce qui est pratique orientée à autour des tests l'objectif de la de la session donc j'en ai j'en ai un petit peu parlé ça va être de voir quelles sont justement les limites d'un design applicatifs orientées sur des couches techniques on va avoir quels sont les principes de l'architecturé hexagonal de la quine architecture et puis on va voir aussi comment à partir de ces bases là on va pouvoir simplifier à la fois les évolutions et la partie maintenance on va voir ce que ça donne en fait sur sur une base de code typiquement comment est ce qu'on arrive à isoler le coeur métier donc comment est-ce qu'on va s'abstraire de tout ce qui est accès à une base de données potentiellement serveur de mail a également et puis un système de fichiers quand vous avez besoin de faire des lectures ou des écritures donc comment est-ce qu'on peut organiser notre code autour de tout ça et puis on essaiera de faire un petit bilan sur se dire finalement de passer à ce type d'architecturé qu'est ce que ça va nous apporter au quotidien en tant que développeur donc l'idée c'est de prendre un petit à petit fils rouges en fait sur une application qu'on aurait pu très bien vous demandez donc ça aurait pu être un projet d'étude ou un projet que vous demandent en fait une mairie et l'idée c'est de voir larchitecture sur laquelle on part de base donc sur un découpage technique et puis de voir finalement en termes de maintenance et d'évolution cette tendance à partir sur un découpage très technique en quoi est ce que ça nous limitant à un moment donné donc on verra comment est-ce qu'on peut finalement passer à autre chose et les étapes qu'on peut prendre justement pour arriver à isoler cette partie métier de tout le reste donc le sujet on va dire on va se mettre dans le contexte vous avez à une demande vous êtes sélectionné et puis c'est le conseil municipal d'une mairie qui décide de développer une petite application cette application elle est relativement simple pour le moment elle va devoir faire un certain nombre de choses et le conseil municipal a décidé d'offrir un cadeau à ses habitants donc ce qui fait leur première bougie dans la commune finalement on veut leur offrir un cadeau évidemment va pas offrir le même cadeau à quelqu'un qui a trois ans ou quelqu'un qui a 65 ans parce que on risque de tomber à côté nuuk hallyday va y avoir un certain nombre de règles de gestion métier qui vont venir au fur et à mesure enrichir le périmètre de l'application donc il va falloir déjà sélectionné les habitants éligibles il va falloir leur trouver le cadeau approprié en fonction de leur âge et puis va falloir rentrer dans un mécanisme de notification domaine le mécanisme de notification mail il va devoir intervenir à deux niveaux il va falloir prévenir individuellement les habitants et puis il va falloir aussi envoyé un maire à capitule hâtives au service de la mer commence à y avoir plusieurs choses dans les demandes donc ça c'est votre feuille de route si on représente les choses un point de vue d'un point de vue graphique tout ce que je viens de vous raconter c'est un peu ce qu'on va devoir faire les sources de données qu'on va devoir manipuler donc de façon classique dans les projets on a forcément un moment donné on a des sources d'entrée des inputs saisine coûte il y en a deux qui il ya un input sous la forme de bases de données donc qui va à contenir l'ensemble des habitants de la commune placez une base de données en hd mais ça pourrait très bien être une base de données mysql ou poserait où finalement peu importe et puis on a une source une autre source de données qui nous provient d'un autre canal et sept autres sources de données c'est en fichiers donc il va falloir pour coder notre application et faire ce cas d'utilisation récupérer des informations qui vient de différentes sources de données on va avoir des déclencheurs qui sont différents on se dit que l'attribution d'un cadeau il va falloir qu'on puisse le déclencher via une interface graphique typiquement poids pour les employés de la mairie on sait qu'on va vouloir mettre à disposition une api typiquement pour des développeurs au thé ou pour des besoins de tests de ouvrir des choses pour regarder comment se passe notre système et pouvoir déclencher le cas d'utilisation et puis également une tâche automatique l'idée c'est d'envoyer le mail dès la première année d'arrivée dans la commune et cette tâche là si ça se passe le samedi et le dimanche évidemment ça va être déclenché de façon automatique donc on peut avoir finalement plainte déclencheur plein de formes différentes pour nos tripes pour notifier not used guys notre application les pistes on s'attend à avoir en sortie on va retrouver un toujours notre base de données mais cette base de données là et va être enrichie elle va être enrichie avec les informations de cadeaux qui vous montrent qu'ils vont être attribués et puis un certain nombre de mails qui vont être envoyés donc des mails individuels aux habitants et puis un mail un récapitulatif journée par journée à la mer donc en termes d' en termes d'architecturé si on prend on va dire ce qu'on trouve dans 80% des applications on va trouver un schéma autour d'un modèle qu'on appelle n-tiers donc en l'occurrence souvent trois tiers où on va trouver une partie qui va concerner la présentation une partie qui va concerner le métier et une partie qui va concerner l'accès aux données donc on va trouver vraiment un découpage technique c'est à dire qu'on va avoir nos contrôleurs et on va mettre l'ensemble des contrôleurs de notre application donc on va avoir un habitant contrôleur qui va nous retourner l'ensemble des informations nos habitants et puis un happy town controller qui finalement lui va permettre de déclencher l'attribution des cadeaux cette couche contrôleurs elle va déléguer l'appel à une couche service et puis la couche service ave a besoin à un moment donné de pouvoir accéder à la base pour récupérer les informations des habitants donc ces structures et par responsabilité technique on va trouver à des objets du domaine qui vont transiter à l'intérieur de toutes ces couches donc le modèle de stockage c'est à la fois le modèle manipulé par la partie métier et c'est à la fois le modèle qui va être remonté jusqu'à la couche de présentation donc il faut au moment où vous établissez votre modèle finalement d'arriver à faire entrer tous les besoins alors au départ quand vous commencez une application générale ça match vous êtes productif très rapidement mais comment vous commencez à faire évoluer les choses vous êtes plus ou moins contraints et ce modèle là impose finalement à ce que vos besoins utilisateurs en termes de restitution sur la partie présentation ça correspond aussi à ce que vous avez sur votre modèle de stockage donc rapidement vous allez faire grossir les choses mais pas les faire grandir et puis une partie configuration qu'on trouve généralement qui va couvrir aussi l'ensemble de vos couches ou si vous utilisez par exemple du spray ou d'autres applications dont vous allez avoir des frais mort qui vont être intrusif dans votre code typiquement des annotations ou des choses comme ça en termes de maintenabilité d'évolutivité du code je peux vous montrer à je peux vous montrer un exemple d'application donc a été à développer un justement sur en prenant cette approche d'architecturé trois tiers où là on retrouve vraiment un découpage sous forme technique on va avoir l'ensemble de nos contrôleurs l'ensemble de nos services nos repositories et puis l'ensemble des informations de domaine domaine ce qu'on manipule c'est relativement simple pour le moment on a des cadeaux on a des habitants et puis on a on a des tranches d'âge si on regarde les informations de notre domaine donc qui représente notre métier on se rend compte qu'on a tout un tas d'informations via des annotations donc on a déjà utilisé en fait un non sens de frais mort donc en l'occurrence si on regarde la partie un port on voit qu'on a doublé moque donc pour générer les guetteurs et 17h pour générer un certain nombre de constructeurs on voit aussi qu'on a des annotations de validation sur tout ce qui est notre blanc t-notes nul donc là on est en train de poser des annotations de validation sur notre domaine métier à partir du 1er août skies donc là ça veut dire qu'on prend une hypothèse très forte ça veut dire que tous les week-ends de notre application qui vont venir un prêt il va falloir qu'ils correspondent à ce modèle de validation donc là après on va commencer à jongler ça va être compliqué quand on va voir a ajouté d'autres cas d'utilisation notre classe de service si on regarde un petit peu notre classe de service qui attribue qui attribue les cadeaux elle prend tout un tas d'informations en paramètre l'attribution de deux cadeaux quand on repart de l'expression du besoin métier c'est relativement simple de façon périodique on veut déclencher l'attribution d'un cadeau et puis ça l'application d'aller sélectionner les habitants et de regarder ce qui se passe là on voit qu'on a tout un tas d'informations qui finalement sont très technique c'est à dire qu'on va passer le nom du fichier donc ça veut dire qu'on se lit déjà sur mes cadeaux ils vont arriver en lisant un fichier sur disque on a une information de date et puis on a tout un tas d'informations de configuration pour le serveur de mail donc là en fait on n'est pas très sûr du métier on est en train de dire je suis en train de faire passer des paramètres techniques dans mon cas d'utilisation si on regarde les imports de notes classe [Musique] on voit qu'on a effectivement de l'adhérence à un serveur de mail on a dû jacques semaine on a de l'adhérence à dax et systèmes et fichiers puisqu'on a dû java ayo et on est fortement couplé à toutes ces briques l'a donc le code il fonctionne il ya des tests il fait le job il ya du parking alors c'est un petit peu compliqué il ya pas mal de méthodes privé et puis on concatel les informations pour envoyer pour envoyer le même ça fonctionne si on regarde les tests alors s'est testé mais les tests sont compliquées les tests sont compliquées et quand on regarde les tests avec de l'expérience on se dit c'est des tests qui ont été écrits à posteriori on n'a pas écrit les tests en partant du métier on se répartit du métier de l'expression de besoin on aurait certainement pas écrit une méthode d'attribution de cadeaux en passant les paramètres de configuration du serveur mail ni emplacement noms de fichiers donc sur les tests on se rend compte que on a besoin démarrer un serveur de mail alors il ya des librairies qui sont à disposition heureusement il ya des framework qui sont là et puis on commence un peu à jouer un petit peu parce que finalement on a besoin de le démarrer sur un port donc sur ma machine ça va peut-être fonctionner et puis le développeur voisin va récupérer le code va lancer sur son poste et lui ça n'a pas marché parce que le port va pas être dispo sur sa machine donc vous allez aussi commencé à avoir des phénomènes de tests qui sont aléatoires ou quand on commence à avoir ce caractère aléatoire sur les thèmes généralement ou va désactiver les thèses parce que finalement on n'est pas serein ils nous font pas gagner du temps au contraire nous font perdre du temps donc on rentre dans cette logique là d' finalement c'est compliqué à tester donc on abandonne donc on voit finalement sur un premier cas d'utilisation qui est relativement simple on arrive à coupler fortement notre code et à être tout de suite adhérents à des framework technique skis espace régulièrement c'est que on va avoir de plus en plus de mal à faire évoluer ce col là que ce soit aussi bien sur la partie métier parce qu'on va commencer à voir nos utilisateurs en disant ah mais oui mais là du coup par rapport à l'autre used guys on a dit qu il fallait que cette info là soit présente donc ça va impacter votre modèle de stockage en fait vous allez perdre aussi en souplesse d'un point de vue implémentation et vous vous allez faire perdre aussi on va dire de la créativité au niveau des cas d'utilisation et vous avez limiter vos utilisateurs donc là ce qu'on a vu c'est sur une classe de service et c'est pareil sur sur l'habitant service aussi on est centré autour des framework donc pour savoir est ce que mon code a orienté autour des framework on regarde en fait la liste des imports et puis on voit justement toutes les couches sur lesquels on est fortement couple et le modèle métier on l'a vu il transite partout à la fois sur la partie repositories service et sur la partie présentation le fort couplage donc tout ce qui est composants d'infrastructure ça veut dire que dès que vous voulez poser un test sur votre métier la stratégie qui a été prise c'est lance un serveur de mail de scanner laideur du mail et de poser les insertions sur le contenu du mail donc là on est très loin des règles métier qui sur le papier sont très simples quand je sélectionne en d'habitants il est arrivé dans la commune depuis plus d'un an je suis obligé de démarrer un serveur de mails pour vérifier que j'ai bien implémenté la fonctionnalité les tests et créa a posteriori on voit rapidement au delà de la partie test ça va être finalement la lisibilité la simplicité de votre code là on sent que ce qu'on connaît l'application ils ont commencé par prendre les sources de données et puis ils ont rajouté le nom de fichier parce que c'était pratiquants paramètres et puis j'ai eu un besoin à un moment donné de mettre le serveur de mail donc tu rajoutes est donc là on fait grossir notre système et c'est de plus en plus compliqué en fait de le faire donc faire évoluer au niveau de la de la pyramide des tests on est aussi un niveau où on n'a plus de base c'est à dire qu'on est plus sur une approche unità qui va représenter le métier on est sur ce niveau intégration où on n'a pas une base et un socle solide on a des tests aléatoires dans notre cas ça marche sur ma machine mais ça marche pas sur la machine du voisin on est obligé démarrer un serveur de mail et notre stratégie de test on est orientée sur des framework on a utilisé une librairie pour faire un serveur de mail fake mais cette libraire et là si jamais demain je la fait évoluer il faut que je revoie l'ensemble du code de mes tests donc on se rend compte qu'on est sur un modèle qu'on attaque par le milieu de la pyramide mais qui rapidement en fait va va être à ses limites l'idée de la pyramide de thèse c'est plus en plus on est bas dans la pyramide plus on est unitaire plus on va avoir un temps d'exécution qui va être rapide aussi on va pouvoir pointer rapidement quand on a un test en erreur on sait que c'est ce qu'elle ait ce cas précis où on a un souci et on va avoir un coût de maintenance qui va être aussi beaucoup plus faible et d'évolution de la même façon quand vous avez quand vous avez un retour finalement il ya il ya quelque chose que vous avez pas pris en compte ce que j'appelle un trou dans la raquette et à un moment donné vous allez avoir votre métier qui va vous dire dans cette situation là ça fonctionne pas est-ce que vous avez bien fait notre job est ce que vous avez mal fait au stadium c'est toujours le truc peut-être le fameux on sait pas compris si vous avez des tests que vous vous êtes mis d'accord avec le métier sur quelles règles de gestion vous avez en général c'est des choses qui vous ont pas été remonté mais c'est cory jane facilement vous avez commencé par écrire un test justement qui reproduit en fait ce comportement là et c'est peut-être l'histoire de bornes à chaque fois est ce que on en voit les choses pile un an un an après les choses qu'on pas été pensées ou exprimer on enrichit la batterie de tests on commence par écrire à ce test le test va être rouge et on va faire évoluer aussi au fur et à mesure la batterie et les cas d'utilisation donc là on est vraiment sur un système finalement ou apporter de nouvelles règles c'est simple alors c'est peut-être des règles compas était prévu dès le départ mais on peut enrichir rapidement sur cette partie là la partie fonctionnelle là on l'a on l'a pas comme comme exemple ce serait des thèses qui serait vraiment très très haut niveau c'est à dire qu'on partirait de l'interface graphique en simulant finalement un clic pour dire je veux voir comment ça fonctionne l'attribution de mes cadeaux alors ce test là soit il est vert soyez les rouges si les rouges ou est ce que j'ai un problème est-ce que c'est au moment où je lis mon fichier moi j'ai un problème de droit est ce que finalement c'est ma base de données qui est tombée on sait pas tout ce qu'on sait c'est qu'il ya un problème mais par contre le champ des possibles derrière peut être relativement important d'autant plus si vous avez une stack et des sources qui sont relativement complexe derrière comment est ce qu'on essaye de faire autrement faire l'autrement il ya différentes possibilités faire autrement déjà vous poser la question pourquoi on veut faire autrement on a vu que ça fonctionnait mais qu'on commence à atteindre un petit peu un petit peu des limites faire autrement ça va vouloir isoler ça va vouloir être isolé protéger cette valeur de tout ce qui est évolution et changement métier on va vouloir aussi donner de la souplesse pour dire finalement notre modèle de stockage est ce que je fais une table pour mai à huit ans une table pour mes cadeaux est ce que je mets tout dans une table finalement c'est un choix secondaire et quand on commence à développer l'application le plus important c'est ça l'aide à apporter de la valeur est vérifiée en fait que les cas sont bien implémentée qu'on choisisse de prendre un stockage à la limite relationnelles ou un stockage sur du non relationnelles c'est un problème d'arrière sur le stockage mais ce problème là on peut tout de suite les cartes et le découpage pas responsabilité aussi quand on travaille sur un point l'idée c'est de rentrer dans les petits ci qui sont très courts le plus court possible et pour avoir des sites qui sont le plus court possible ils font intervenir sur un périmètre qui est borné si sur votre périmètre vous commencez à taper sur l'ensemble de aux couches en général vous allez avoir aussi des cycles qui vont être beaucoup plus long ce que ça vous permet aussi c'est d'être à l'aise quand vous faites des oeuvres gred de framework ou de dépendance bien souvent quand on arrive sur des projets on arrive dans des situations où on a à bannans on peut plus mettre à jour parce que si on met à jour ça fonctionne plus et ça marche plus on a peur finalement d'avoir des régressions donc on le fait pas au fur et à mesure il ya un moment donné où finalement pu faire donc d'avoir isolé justement ces bris technique c'est de rentrer aussi dans une logique où finalement à chaque fois qu'on a une version qui est disponible mais on peut la mettre à jour il ya des outils pour le faire aussi de façon automatique et si vous avez votre batterie de tests d'arrière qui en place vous êtes serein justement pour faire ce travail là et en tant que dave je vous assure que c'est beaucoup plus agréable de travailler avec les derniers outils que de travailler avec des choses des fois qui date qui date de plusieurs années donc il ya 2000 ya deux modèles qui propose d'organiser les choses de façon on va dire différentes et il ya des similarités en fait dans les deux la similarité principal ça va être d'isoler votre métier au cas d'utilisation la première proposition c'est la clean architecture donc c'est porté par un club qui a un blog que je vous invite enfin forcément à visiter quand vous avez un petit peu de temps voilà c'est très riche vous avez plein d'infos dessus et ça ouvre pas mal de possibilités ou tout du moins des réflexions sans avoir forcément de certitudes et ce qui est marrant c'est que un club lui commence sont faites en disant qu est-ce qui est pas une application quand vous discutez oisans sur quoi tu travaille en ce moment je suis sur un projet c'est super sympa on a dû cassandra et puis en haut qu'en fait on est orien très très technique et on oublie un pôle métier donc on fait un paquet en fait on essaye de mettre le métier au niveau de la technique vocale bob lui il dit foutu c'est pas tout par rapport à votre base de données et par rapport à vos framework évidemment on va en utiliser mais on va les utiliser à certains moments et dans certaines phases en fait du cycle de développement et lui ce qu'il dit c'est penser toujours used guys et cas d'utilisation quand on parle cas d'utilisation forcément on va discuter avec le métier et notre code va être beaucoup plus simple si on fait l'analogie sur le code qu'on vient de voir l'attribution de cadeaux normalement on met pas les paramètres de configuration du serveur mail ni noms de fichiers donc là on n'est pas un niveau used guys c'est à dire qu'on est vraiment sûr sur de la technique l'hexagonal architecture on est aussi sur cette notion de protection du métier mais on n'est plus sûr qu'est ce qui va se passer autour aussi et autour il ya notre application donc le métier qui finalement présent le fond de ce qu'on doit faire l'expression de besoin et puis va y avoir la forme comment finalement est-ce qu'on peut déclencher cas d'utilisation donc que ça soit des utilisateurs derrière une interface graphique que ce soit des programmes que ce soit des tests automatisés ou des bâches tout ça finalement c'est pas important c'est des moyens notification et rajouter un moyen de notification c'est pas compliqué c'est un endroit et vous pouvez enrichir facilement si vous avez bien fait cette séparation l'a donc l'idée c'est vraiment aussi d'être en isolation de tout ce qui est un système d'exécution et bases de données le schéma vous pourrez retrouver le schéma sur sur le blog l'idée c'est ce centre ce qu'il faut garder en tête c'est cette notion de centre et de serbes qui au fur et à mesure ça grandit dans votre centre vous devez avoir tout votre logique métier votre application saas est ce qu a de la valeur finalement quoi qu'il arrive autour ça ça doit être perrin dans le temps donc on est sur du code où on n'a pas de framework pas d'annotations on est vraiment sûr du langage pur est ce qu'au delà vous pouvez discuter avec votre product owner vous pouvez discuter avec votre client quand il lit le code il doit être en capacité de le comprendre il doit retrouver en tout cas un moment donné son expression de besoin et puis sur les cercles tour là on va commencer à entrer dans tout ce qui est point d'entrée pour déclencher les cas d'utilisation donc que ce soit via les api rest que ça soit sur des interfaces graphiques ou des tâches automatisées des fournisseurs de données aussi sur tout projet il ya un moment donné on a besoin de récupérer la donne et récupérer de la donner dans notre cas on a on a une base de données on a des fichiers on pourrait avoir faire un appel un outil de gestion rh par exemple finalement de se dire l'info de mes cadeaux bain j'appelle un autre système pour les récupérer et puis des éléments de configuration derrière nos clients c2c pas de ne plus utiliser les fragments ont contraint il ya des supers framework qui nous font gagner du temps par contre c'est de les utiliser au bon endroit et de pouvoir facilement sand est corrélée à un moment donné l'architecturé hexagonal on a une notion d'intérieur et d'extérieur qu'on n'est pas sur une représentation sous forme de cercles l'intérieur ça va être votre hexagone l'intérieur elle va compte ça à contenir ont aussi toute la logique métier sur la logique métier il ya un moment donné où vous allez vouloir récupérer des informations ou vous allez vouloir déclencher votre logique métier donc ça c'est ce qui va se trouver sur la partie application donc les moyens d'interaction et puis avoir toute la partie infrastructure sur tout ce qui est dépendance nécessaire pour faire fonctionner votre métier donc de la base de données ou du fight système le point important c'est le sens des dépendances ce sont ce des dépendances i doit être uniquement de l'extérieur vers l'intérieur c'est à dire que votre domaine ne doit absolument pas connaître l'infrastructure domaine a connaissance de l'infrastructure vous allez voir dans vos apports des choses vers l'extérieur vous avez cassé le modèle et en général quand vous commencez à avoir ça de façon des foires inconsciente parce qu'on peut se dire dès le départ en équipe on va essayer de partir sur ce sur un modèle et c'est important un moment donné d'outiller justement cette partie là pour avoir les alertes quand vous êtes en train de faire des choses qu'ils n'ont pas ça peut arriver et ça arrive plein de fois c'est à dire qu'on est en train de créer quelque chose et puis on l'a mis en infrastructures et puis finalement l'appel en métier et c'est de se dire ah finalement c'est pas d'infrastructures mais si un autre cas d'utilisation et une des difficultés ça va être de réussir à découper à identifier au cas d'utilisation on a un principe d'isolation des frontières l'isolation des frontières sûres sur l'architecturé hexagonal on est sur un mécanisme où finalement on est sur le pattern port adapteur donc concrètement c'est quoi la partie port ça va être des interfaces et puis la partie adapteur ça va être des implémentations concrètes donc on va pas s'occuper ont typiquement on va avoir besoin de récupérer un des habitants donc on va avoir un habitant provider et puis finalement l'implémentation il faut que j'aille jusqu'à une base h 2 on va s'en préoccuper mais après au moins j'aurai les informations la signature pour récupérer mais habitant donc si on projette un petit peu sur notre découpage technique finalement comment est-ce qu'on va arriver étape par étape à isoler nos cas d'utilisation nos fournisseurs de données et nos déclencheur donc ça c'est le modèle qu'on a vu qu'on a vu tout à l'heure et si on passe sur un modèle différent on va avoir quelque chose qui ressemble à ça quelque chose qui ressemble à ça en pin architecture on va avoir notre cercle donc retrouvés à vraiment la valeur le métier donc ce qu'on va appeler anti tison qui sont les cadeaux les habitants les tranches d'âge et puis on va avoir un certain nombre de cas d'utilisation qui ont émergé premier cas d'utilisation ça va être on a besoin d'avoir un youth caisse pour attribuer les cadeaux pour déclencher cette attribution de cadeaux on va avoir des riaux ce besoin d'un new skies pour récupérer les informations des habitants aient besoin d'un new skies aussi pour attribuer de façon aléatoire un cadeau on a une source de données où on a dans un fichier l'ensemble des cadeaux possibles par tranche d'âge donc un fichier 1 je peux vous montrer en fait le fichier de cadeau donc ça c'est quelque chose qui vous est livrée régulièrement et c'est des informations dans du fichier texte où vous avez une référence une description un montant et puis une tranche d'âge donc par exemple pour la tranche d'âge de 0 à 3 ans vous avez un certain nombre de deux cadeaux qui sont possibles qui sont à disposition et de façon aléatoire pour tous les gens qui sont arrivés dans la commune depuis une année qui entre 0 et 3 ans vous allez attribuer à un cadeau possible dans la liste donc va y avoir ayew skies qui va prendre en charge cette partie là vous allez avoir des fournisseurs de données pour la base donc l'accès aux fichiers et puis également une partie mail pour pouvoir envoyer l'ensemble des informations cette notion de séparation ou au final tout ce qui est autour on veut s'en préoccuper mais le plus tard possible on va déjà pouvoir codé notre application donc nos cas d'utilisation uniquement à partir de ce cercle l'a donc son framework sans annotations sans se préoccuper d'avoir un serveur de mails où on va pouvoir justement ce coupé complètement de l'extérieur donc il ya plusieurs étapes pour arriver à pour arriver à cette partie là les étapes qu'on va avoir au début ça est de se dire il faut qu'on se mette d'accord sur comment est-ce qu'on va organiser notre application on peut parler de corps vous pouvez parler d'application peu importe au final l'important c'est que vous soyez synchro en termes d' équipes sur ce que vous allez mettre derrière cette notion de corps à va contenir l'ensemble de vos objets métiers aux entités et puis les cas d'utilisation donc l'idée ça va être déjà de commencer à séparer les choses de se dire j'ai mon coeur j'ai mon métier j'aime et used guys et puis à côté jeu hors des frontières de données et puis après je vais avoir des zones tripolt c'est à dire des moyens de notifier mon coeur applicatifs donc la création de la nouvelle structure de package vous allez pouvoir commencer à séparer et à répartir les données au bon endroit donc tout ce qui est domaine qui transitaient dans toutes les couches ça va venir dans les antilles teese est la priorité ça va être de commencer à supprimer tous les frais morts qui sont et toutes les annotations qui sont présents à l'intérieur de ces objets là pour se dire on veut pas avoir d'adhérence on va avoir un code le plus pur possible donc on va commencer à retirer tous les framework et en voulant retirer tous les framework on va se rendre compte que c'est compliqué parce que si on reprend le code par exemple sur sur notre objet habitants qui a persisté qui persistait en base on a des annotations ou finalement on dit qu'elle est le nombre de la table et puis comment est ce que je vais généré à mach les imprimer mon identifiant au moment où je vais stocker mon objet et puis on a aussi des choses au moment où on leur restitue sur la partie présentation c'est à dire que dans mon jeune côté api je vais vouloir qu en première position j'ai le nom et puis après le prénom donc il ya des annotations en fait de partout qui concerne à la fois la présentation à la persistance donc arriver tout de suite à supprimer toutes ces annotations là ça va plus fonctionner donc il faut avancer un petit peu plus loin après aussi dans les étapes prochaine donc les états prochaine ça va être deux dia on a besoin finalement d'un fournisseur d'habitants on va pas se poser la question tout de suite sur l'implémentation mais dans mon corps on va dire j'appelle un habitant providers fournir la liste de mes habitants après on va pouvoir venir justement faire une implémentation concrètes donc en l'occurrence là qui en base de données donc on va venir des placiers le code qu'on avait précédemment est ce qu'on va faire c'est que on va créer un objet qui correspond à l'implémentation de notre base de données on va avoir un objet dédié pour le stockage cet objet ça va être habitants j'y perds et finalement c'est cet objet là qui va contenir toutes les annotations de persistance parce que son job 8 c'est uniquement de la persistance pour un modèle de base et puis on va commencer aussi à pouvoir créer new skies pourra récupérer la liste des habitants donc quand arnaud paquet je vous allez commencer à répartir aussi les choses donc va y avoir un nouveau provider qui ont été revus bien sûr de la base de données où vous allez avoir votre provider pour pour vos habitants votre modèle de stockage et dans habitants jpa repositories l'ensemble des informations pour écrire vos requêtes et c'est ici où vous allez pouvoir utiliser des framework spring data jpa ça marche très bien on n'écrit plus la requête par contre il va être uniquement présent à ce niveau là vous allez avoir un test qui vérifie le bon fonctionnement de vos requêtes et c'est uniquement centralisée ici vous n'êtes pas obligé de repasser par votre coeur et votre cercle pour pouvoir vérifier ce que mon système de base et bien ok donc de la même façon pour la partie présentation pour arriver à se décorréler des frais mort qu'on va créer un nouvel objet pour la partie restitution pour ce cas d'utilisation donc là mon métier veut récupérer l'info enfin dentelle sens ou potentiellement les dates je peux avoir un format de stockage pour les dates en base par contre en terme de restitution j'ai vouloir travailler travailler et rendre un quelque chose qui est plus humaine compréhensible donc dans la même façon on va avoir une nouvelle partie qui va intervenir ici donc là on va a commencé à supprimer du code qui avait sur la partie contrôleur service ce finalement c'est uniquement de la réorganisation donc ce qui était dans le contrôleur ça devient en fait votre plein de notification ça deviens vote endpoint et par compte ce contrôleur là c'est lui en fait qui va avoir son objet de présentation et il va être stocké uniquement à cet endroit à partir de là votre objet habitants ça devient un vrai objet métier c'est à dire que vous avez plus d'adhérence avec la façon dont vous le stocker et avec la façon dont vous avez choisi de le restituer en 4e étape après c'est plus simple c'est à dire que vous allez commencer à créer d'autres used guys donc le new skies principal de l'application sur l'attribution de cadeaux ou de la même façon vous allez rajouter une classe supplémentaire cette classe supplémentaire on est plus sur quelque chose orienté autour d'un nom d'applications api thann services happy town contrôleurs ou vous êtes finalement sur une notion de cru que vous stockez en bas ce que vous faites remonter sur votre couche service et vous mettez tout un tas de méthodes au kilomètre non là vous avez vraiment finalement qu'est-ce que votre application exposé à l'extérieur vous avez pu notion de service vous êtes vraiment sûr qu'est ce que vous manipulez et vous vous offrez aux métiers la partie tâches automatiques ça devient finalement un point d'entrée donc là vous aviez déjà des choses en place en termes de configuration pour notifier des tâches automatisées voilà il ya une classe dédiée pour cette partie là au niveau de la notification par mail donc cette partie provider ce qui est important de voir c'est qu'on est aussi bien sur la récupération de données que sur le fait de pousser la donne et que ce soit la fois sur deux la sauvegarde ou sur deux déclenchements donc typiquement de l'envoi de mails donc là c'est pareil vous allez besoin d'avoir un notification provider aujourd'hui il ya une implémentation sur du mail demain vous voulez proposer à votre métier finalement de dire je notification par sms ou par mail ou les deux en fait vous allez rajouter une nouvelle implémentation et ça va être transparent d'un point de vue votre métier d'un point de vue doit être métier ce que vous avez à faire c'est que vous allez déclenché le provider de notification les enfants quand vous commencez à faire ça vous allez aussi supprimer tous les paramètres exotiques qu'on avait d'en attribuer cadeaux la configuration des infos du serveur de mail le smtp host le smtp port c'est uniquement des infos qui vont se retrouver ici que vous alliez chargées via des propos retirés mais elles vont pas transiter dans l'autre couche contrôleurs dans votre couche services et dans vos classes d'envoi de mails vous allez uniquement aussi injecté les choses au bon endroit et puis vous pouvez choisir de changer de libre et de mails ça pose pas problème c'est à dire que vous n'êtes pas obligé de réécrire l'ensemble de vos tests parce que le fait d'avoir sorti toutes les notions techniques vos thèses vous êtes sûre du métier donc vous vérifiez des choses fonctionnel donc quand vous changez de librairies et volontairement faire l'exercice ça montre aussi qu'elle travaille en fait de riz facto on a affaire et plus finalement le travail important ça veut dire que vous êtes couplé et en termes d'évolution ça va être compliqué pour la suite le fichier c'est pareil finalement c'est un autre moyen mais il faut le voir de la même façon vous avez un provider qui va vous fournir quels sont les cadeaux par tranches d'âge et toute la complicité qu'on voyait tout à l'heure dans le code sur du piercing sur jose pitt avec la virgule et puis j'ai des tranches d'âge s'est agi minimum tirer âge maximum tout ça en fait vous allez mettre un endroit et le jour où il ya une évolution finalement les tranches d'âge elles sont plus représentés de la même façon sur eux-mêmes formalisme vous modifiez votre test qui couvre le parsing qu'à un seul endroit et vous pouvez modifier rapidement et votre code ici il a pas changé parce que vous êtes vous récupérez du métier vous êtes sur des objets et finalement que voulait récupérer un an avec un parking exotiques parce que des fois vous récupérez des choses des systèmes c'est un peu compliqué laborieux ça s'est isolé à 1 et à un seul endroit la notion d'exception aussi de penser vraiment à avoir des exceptions métier les exceptions métier vous arrivez pas récupéré aux cadeaux par tranche d'âge finalement que ce soit dans du fichier que vous avez un problème de droit vous avez de l'aio exception vous avez autre chaude transformer ces exceptions technique en exception métier parce que les exceptions technique il peut on se passer enfin plein de sortes par contre votre coeur métier ce que vous voulez discuter c'est de savoir où est ce que vous allez quand ça se passe pas bien et là la réponse elle est vous l'avez pas vous en tant que développeur il faut poser la question aux métiers si on n'arrive pas envoyé le mail qu'est-ce qui se passe est-ce qu'on attribue quand même le cadeau ou pas donc là vous allez tirer justement fin des discussions qui sont un petit peu plus large et finalement qui son métier et si la réponse c'est de se dire finalement qu'on n'ait pas réussi à envoyer de mails c'est pas bloquant d'accord peut-être poser un log on va mettre un système de monitoring sur le mec est pas en place par contre sara pas bloquer notre application 6 à la bloque on récupère l'exception métier et on fait le traitement qu'on veut derrière et puis à la dernière étape après vous pouvez faire les opérations de rhi facto vous voulez vous êtes complètement sortir justement des frais mort donc là vous êtes à l'aise vous voulez mettre en place des temps plein de mails pour pu avoir à écrire ça se fait facilement mettre en place des fictions faire du riz facto c'est rapide vous arrivez à avoir ce schéma là finalement assez rapidement en déplaçant et en mettant les choses on bat la clé en fait c'est vraiment de mettre les choses au bon endroit et d'être sûr que vous violez pas ce principe de dépendance est toujours de l'extérieur vers l'intérieur et pas l inverse pour terminer hexagonal architecture finalement c'est quasiment c'est quasiment la même chose dans notre exemple on n'est plus sûr du vocabulaire sur le vocabulaire on va être sur la notion de pattern port adapteur donc on n'utilisera pas où on va dire les mêmes terminologie si on veut vraiment va dire respecter les standards j'ai envie de dire c'est pas le plus important ce qui est important que vous choisissiez de parler de habitants port ou deux habitants provider finalement ce qui se cache derrière c'est le même objectif donc ce qu'est le plus important ça discutait en équipe lorsque parce qu'il faut se mettre un standard par contre qu'il n'y ait pas à la fois l'un et l'autre au sein du projet parce que sinon ça va être compliqué de s'y retrouver et c'est surtout la logique qui a derrière donc si on fait si on fait un petit peu une conclusion de la séance essayer au maximum de penser métier voilà de sortir de la technique la quine architectural hexagonal architecture ces deux propositions il y en a d'autres il ya d'autres façons moi de le faire ce qu'il faut garder en tête c'est qu'est ce que ça peut vous apporter si vous voyez pas le gain tout de suite vous allez forcément le voir à un moment donné et le temps que vous prenez pas au début de bien structurer organiser les choses vous le payer à un moment donné et vous commencez à le payer quand vous entendez les chaussures c'est compliqué de tester il ya des régressions on a des tests aléatoires on peut pas tester unitairement donc on tape à un niveau d'intégration fonctionnelle tout ça en fait ça doit être des signes qui montrent que finalement le code est pas bien organisé et en fait on est sur une approche où on amène au fur et à mesure on rajoute du code en amène de la complexité à j'ai besoin d'un ca d'envoyer un mail je vais remonter l'information etc etc donc garder cette notion d' isoler votre métier le maximum possible j'en ai terminé merci à tous [Applaudissements] je sais pas si elle tend pour des questions pas ouais alors bonne question ici à ce niveau là est la question je sais pas si tout le monde l'a entendu c'est au niveau du notification provider est-ce qu'on est sur des tests unitaires ou est-ce qu'on est sur des tests d'intégration à ce niveau là sur le notification provider on a une interface donc quand on teste en fait notre coeur métier on est vraiment sur des tests unitaires c'est à dire qu'on va vérifier le fait de déléguer la responsabilité un notification provider de notifier à la personne donc on est à sur un système de moque de ce top donc on est vraiment sur une partie unitaire par contre quand vous êtes sur cette partie là m'ont vraiment mon implémentation c'est à dire que j'ai la configuration serveur de mail et je veux vérifier qu'effectivement fait mon mail par bien donc là on va être sur un test d'intégration donc en fonction en fait de l'endroit où on est l'idée c'est quand on peut faire de l'unitaire ont fait l'unitaire il ya plein d'endroits en organisant enfin le cas notamment de cette façon où on peut faire de l'unitaire facilement seront assorties à via des interfaces donc on peut facilement moquer ou hst b et vérifier la délégation de l'appel par contre quand on veut voir si notre mail effectivement par bien et tester du rendu par contre on a un et un seul test d'intégration donc liddell et le propos c'est pas de se dire il faut uniquement avoir des tests unitaires et une base solide non il faut avoir en fait une proportion qui est correct quand il ya besoin de faire de l'intégration oui il faut faire de l'intégration par contre il faut que ça soit de l'intégration qui soit vraiment nécessaire donc dans le cas de l'envoi de mails on est sur un test d'intégration qui effectivement a tout son sens d'autres questions oui je suis pas sûr d'avoir bien entendu est ce que le bdta paris de bdc ça oui le bdd et conseillers notamment pour la partie cas d'utilisation new skies au monde quand vous discutez avec votre métier l'approchent bdd vous allez discuter et faire émerger justement quelles vont-être tous les cas d'utilisation donc là vous êtes déjà en train de se dire est-ce que je vais avoir un deux trois cas d'utilisation est ce que finalement c'est le même et doit dégager quels sont les cas d'utilisation des façons de les notifier ça c'est super important aussi donc la proche bdd finalement de faire une discussion enfin c est tres amigos à plusieurs que vous discutiez autour d'un tableau autour de fichiers excel avec des exemples pour comprendre comment finalement et le système d'arrière oui c'est important et ça c'est ce qui vous permet de construire le coeur et le centre de votre application et c'est là où on a de la valeur concrètement en tant que développeur notre valeur elle est d'en construire correctement le cercle et le centre donc si là où il faut combattre l'énergie et tout ce qui est autour il ya plein de framework il en sort tous les jours pour câbler mais déjà vous pouvez faire votre application en vous caucus on sur ça et il ya plein de fois où vous pouvez aller en démonstration où vous n'avez pas encore votre base de données mais c'est pas grave en fait si vous avez un habitant provider votre base de données elle n'est pas encore opérationnel parce que vous êtes sur un gros projet en termes d'infrastructures vous êtes dépendant d'un autre service ou d'un autre système dont vous pouvez très bien venir en démonstration en fait vous avancez à votre rythme et un finalement l'habitant provider dans votre implémentation pour le moment vous n'avez pas votre base de données vous faites un truc en mémoire et vous retourner une nouvelle liste avec trois habitants et vous pouvez en fait démontré plein de choses comme ça et le jour où vous aurez peut-être la livraison de votre base de vous allez pouvoir mettre les mondes configuration très bien en fait vous allez rajouter votre base de données mais le fait d'avoir vraiment sorti décorrélée cette partie là ça vous empêche pas d'avancer et de démontrer les choses régulièrement donc le bdd oui et pour construire le coeur c'est plus que leurs commandes on s'arrête il dernière question du coût ouais si du métier si ton métier de ce dit je vais pas à vouloir envoyer le même mail en fonction de telle info je sais pas où on va rajouter quelque chose de différent en fait ça c'est du métier tu vas pas aller jusqu'à l'envoi de mails ça qui est technique mais par contre tu vas mettre en place un mécanisme pour se dire dans ce cas là je suis sur cette typologie de notification tu vas avoir un type de notification finalement et sept types de notifications ça va être un objet métier donc là il faut que tu ailles discuter avec le métier combien à types de notifications ce que j'ai à une notification je sais pas pour les gens de 0 à 30 ans enfin qui sont pas exactement que la la même que la tranche d'âge et du coup tu as peut-être avoir une correspondance entre ces deux types de notifications et et tranches d'âge donc tu es sûre du métier là tu es sûre du métier parce que ça il va falloir que tu le test est ton métier ça tend justement à ce côté des notifications différentes par contre tu vas pas le tester en disant je vais vérifier le contenu mais de mes mails je démarre un serveur de mail j'ai effectivement mettre dans cette condition là envoyé le même scanner à laideur et vérifier si j'ai le bon contenu non par contre tu va poser des assertions est ce que dans ce cas j'ai bien ce type de notification et ça c'est simple à poser comme test et pour le coup on est vraiment sûr de l'unita on s'arrête là merci à tous [Applaudissements] excuse moi d'habitude