On n’a pas besoin d’utiliser 100% de « X » pour utiliser des pratiques/techniques de « X ».
Remplacez « X » par DDD, programmation fonctionnelle, CQRS, CQS, Hexagonal/Clean/Onion architecture et bien d’autres. Il n'y a pas de méthode ou technique qui soit LA réponse dans tous les cas.
Chacun(e) a ses avantages et inconvénients. Chacun(e) impacte notre façon de penser, notre façon de communiquer au sein de l’équipe. Chacun(e) nous apprend des choses, techniques ou humaines etc..
Par exemple, comment le DDD ou l'architecture hexagonale peuvent nous aider dans une application Drupal ? Est-ce que la complexité amenée en vaut la chandelle ? Vous verrez qu'ils peuvent être utiles même dans cette situation.
Nous verrons qu'il ne faut pas hésiter à piocher dans des concepts ou pratiques si cela convient à notre contexte actuel. N'oublions pas d'utiliser le bon outil au bon moment !
_ Merci beaucoup. Je vais remercier Olivier qui m'a accompagné pour toute l'AFUP . L'organisation est top.
Coucou. Nous allons aller au marché aujourd'hui. Et piocher de droite à gauche dans différents principes. Pour voir si on doit élargir nos horizons.
Je vais me présenter même si tu l'as fait. Je m'appelle Benjamin Rambaud. Je travaille chez Ekino. Je suis ingénieur PHP.
Petit disclaimer : je n'ai absolument rien inventé de ce qui se dit dans ce talk. Je vais rabâcher des choses qui existent depuis les années 50. Je n'étais pas né. Je n'y étais pas. Nous n'allons pas faire de liste exhaustive de tout ce qui existe, nous allons parler du DDD, mais nous n'allons pas regarder tout ce qui existe dans le DDD. Mais on va regarder quelques exemples. On va survoler des choses. Potentiellement, ça peut peut-être énerver des gens. Nous allons parler du domaine design sans l'implémenter à 100 %. On va peut-être déformer certaines choses pour entrer dans notre cas. C'est possible.
Nous allons commencer par un petit quiz tout simple. Que veut dire ce mot ? J'ai entendu quelqu'un devant dire que c'était Since. Oui. Mais non. Pour moi, c'est ça. C'est une Since.
(applaudissements)
D'où je viens, je ne passe pas la Serpillère, moi je since. Même si je suis fou, c'est logique. Un même mot n'a pas le même sens selon le contexte donné. Si vous ne me croyez pas, allez parler de beaux gosses au Québec, ce n'est pas la même réaction qu'en France. Un même mot n'a pas le même sens selon l'époque et selon tout ça. Le contexte est important. Si je lève la main, tout le monde s'en fout. Le contexte, c'est important. Que vous commenciez un projet, ou que vous soyiez au milieu d'un projet. Le contexte est important. Est-ce que vous allez faire les mêmes choix si vous avez un marché selon la maturité ? S'il faut sortir quelque chose très vite ? Avoir des fonctionnalités particulières ? Vous n'allez pas faire le même choix. Selon les choix que vous allez faire, ça va encore modifier le contexte. Encore une fois, vous allez devoir réfléchir.
Typiquement, si un jour vous voulez coder le cardel*, je ne vais pas choisir PHP. J'adore ce langage, mais ce n'est pas le plus adapté de mon expérience. Mais c'est mon expérience. L'équipe, de manière générale, que vous allez pouvoir avoir sur un projet, elle va changer ce contexte. Il faudra la prendre en compte selon leur expérience en techno. Et leur envie. Personnellement, vous me parlez d'un projet sur la cryptomonnaie. Ça ne m'intéresse pas.
Nous aimerions éviter des généralités. On ne devrait pas creuser partout pour trouver le Graal. A contrario, on va dire que c'est un bocal à anchois, vous savez éventuellement qu'il est dans la cour du château. Dans ce contexte, ça peut être intéressant. Ça peut être un cas où... dans ce cas, on voit que selon les choix que vous allez faire, on ne sera pas dans la même complexité. Ça ne va pas emmener les mêmes problèmes.
Dans un projet, vous avez grosso modo trois types de complexité. Environ. Nous allons avoir la complexité essentielle. C'est la complexité du problème à résoudre. Nous sommes tous d'accord que pour le bloc de Montchat* ou une application bancaire, ce n'est pas la même complexité. Les choix qu'on va faire, ça va être présent. C'est la complexité obligatoire de toutes les choses qui sont nécessaires pour qu'on puisse faire avancer le projet et répondre à la problématique de base.
Nous avons le bulldozer. La complexité accidentelle, ce que vous avez mis dans le projet, vous n'en avez pas besoin. Pour le bloc de Montchat, est-ce que j'ai besoin de Kubernetes ? Alors que dans certains projets, c'est pertinent. On a beaucoup de choix à faire. On a plein de choses à voir. De connaissances. On ne peut pas utiliser tout en entier. Ce n'est pas tout pertinent tout le temps. Personnellement, mon yaourt, je ne mange pas avec un bulldozer.
Ce que je vous propose dans cette partie, c'est d'essayer de voir juste. Survoler rapidement trois principes. Pour voir qu'est-ce que ça peut nous apporter. On va le faire vite.
On commence par l'architecture hexagonale. Ports and Adapters. La logique, vous avez une boîte noire dans laquelle à l'intérieur vous avez votre logique. Pour communiquer avec le monde extérieur, que ce soit en entrée ou en sortie, vous allez brancher des adapteurs dans des ports. Je ne parle pas de l'animal. Ne faites pas de mal aux animaux.
Grosso modo, c'est ça. La logique, le domaine. Il est isolé du monde extérieur. Si on veut tester ce qu'on a dans notre hexagone, c'est simple. Nous donnons des choses en entrée, en sortie. Nous sommes contents. Si nous continuons notre voyage et qu'on parle un peu de Programmation Fonctionnelle, je vous rassure, je ne parlerai pas de Monade. Je vais essayer de donner une définition ennuyeuse parce que sinon, c'est trop long à expliquer. La Programmation Fonctionnelle, c'est un paradigme de programmation dans lequel on va appliquer et composer des fonctions de la même manière que les mathématiques. Pour résoudre des problèmes. Le nom Programmation Fonctionnelle, on a des fonctions. Un des piliers, c'est les fonctions pures. On en a parlé hier. Une fonction pure, c'est une fonction qui va être idempotente. On va vous donner toujours avec les mêmes entrées et la même sortie. Elle n'a pas d'effet de port. Une fonction pure, c'est super cool à tester. Quand on compose des fonctions pures entre elles, c'est cool à tester. C'est déterministe.
Nous avons une autre idée avec la Programmation Fonctionnelle. Mais pas seulement. L'immutabilité. Imaginons un langage dans lequel nos entiers seraient des objets. Pour faire 1 + 1, vous devez faire ce truc-là. À quoi vous vous attendez que 1 est égal ou que 2 est égal ? Je m'attends à ce que 1 soit égal à 1 et je m'attends à ce que 2 soit égal à 2. Je ne m'attends pas à redéfinir la valeur de 1 si je fais 1 + 1. On va se retrouver dans un bordel.
Il y a des gens qui font de la Programmation Fonctionnelle, vous allez me taper. Dans les langages fonctionnels, on va parler de langage immutable. Les Value Objects. Dans notre cas, ça va être sympa. Plutôt que d'avoir un string de type primitif, on a une URL. Elle est valide. Avant, si c'était valide ou pas, je ne sais pas. Ça peut être un poney. Plutôt que d'avoir trois pauvres champs sur votre entité, vous vous dîtes : c'est une adresse. Je vais faire un Value Objects adress. Ça marche. Si ça vous intéresse de comment on peut faire, vous mettez votre adresse et vous avez 0,7 heure. Si vous voulez créer une adresse à partir d'une autre, vous utilisez les wizzer. Dans cet exemple, au début, je suis dans un resto. Je change de lieu. Je suis dans un magasin de musique. Mon restaurant existe toujours. Comme dans la vraie vie.
Continuons et parlons de s'isoler. IO. Les entrées et sorties. Inputs et outputs. C'est l'architecture hexagonale. C'est pareil. Ça partage quelque chose. Nous retrouvons un truc qu'on a déjà vu.
Je vais terminer avec la programmation fonctionnelle pour vous parler de ça. PHP. Ce n'est pas un langage purement fonctionnel. C'est là un langage multiparadigme. N'essayez pas de forcer un truc qui ne va pas utiliser le paradigme qui va vous permettre d'avoir la chose la plus lisible, la plus maintenable, la plus performante. Servez-vous de votre choix. Si vous voulez faire 100 % de la Programmation Fonctionnelle, changez de langage. Ça peut être sympa de voir un autre paradigme dans un langage qui va vous permettre d'y aller 100 % pour apporter d'autres possibilités. Parfois, vous simplifier la vie.
Maintenant, parlons de driven-design. Ça existe depuis très longtemps. C'est une philosophie pour gérer des domaines complexes. Vous dîtes : Si je n'ai pas de domaine complexe, ça me sert à rien. Vous avez raison. Si vous essayez de faire du DDD dans un cas où vous n'en avez pas besoin, je reprends mon image de : Vous allez manger un yaourt avec un bulldozer. C'est ce que vous ferez.
Au cœur de la philosophie du Domain-Driven Design, on va modéliser du domaine. On va modéliser la réalité. On va vouloir que notre modèle soit le plus riche possible. Riche, ça ne veut pas dire fourre-tout. On ne met pas tout et n'importe quoi. Si vous voulez créer une application pour inviter les gens à faire du design de voiles de bateaux, vous incorporez dedans toutes les manières possibles de faire des nœuds marins, ça ne sert à rien. On ne le mettra pas dans la modélisation. On voudra que la modélisation, Domain-Driven Design, on se concentre sur le domaine. On veut que tout ce qui se passe à l'extérieur, on s'en fout. On ne veut pas y penser.
La notion d'isoler, c'est la troisième fois qu'on la voit. C'est pas mal. Dans la suite, on veut que notre modèle, notre domaine soit le plus explicite possible. Ça va me permettre d'avoir un domaine explicite dans notre code, de mieux communiquer tous ensemble. C'est pas mal quand on se parle qu'on se comprenne dans une même équipe. Que vous soyez l'expert du domaine, le texte. Je pense que parler et communiquer tous ensemble, c'est une bonne idée.
Mais quand vous voulez implémenter le Domain-Driven Design, vous vous rendez compte que c'est lourd. C'est complexe. C'est normal. C'est pour gérer des domaines complexes.
Ces deux schémas, ils viennent du livre Blue Book. Il y en a d'autres d'avant. C'est plein d'éléments qui sont parfois très simples et complexes parfois. Ils ont déjà fait une démarche où on va se dire : Pour l'implémenter, on peut faire ça. Mais toutes ces choses, ce sont des détails d'implémentation. Vous avez la version de Rick Evans, celle de Jean-Michel, tout le monde a sa version. C'est une philosophie. Vous avez des implémentations derrière des Frameworks.
Dedans, pour ceux qui arrivent à lire, on parle de Layered Architecture. On s'en fout royalement. L'intérêt, c'est que ce soit isolé. Que vous fassiez de l'architecture hexagonale, de l'Onion Architecture, on s'en fout, l'idée, c'est que ce soit isolé.
On peut trouver d'autres concepts. Il y a les side effects, ça ressemble aux fonctions pures.
Quand on fait du DDE, il y a beaucoup de détails dits d'implémentation, mais pas besoin de faire de l'Event Sourcing. C'est plein de détails d'implémentation. Il faut faire beaucoup de lecture et de compréhension là-dedans pour comprendre ce qu'on veut faire derrière. Gérer des domaines complexes.
Dans ce truc, nous avons quand même un truc important qui revient souvent. Quand on parle de DDD. Ubiquitous Language. Quand j'ai lu pour la première fois, je ne comprenais pas. J'ai lu la définition, c'est un langage commun dans un contexte donné. Je vais arrêter de dire Ubiquitous Language. C'est plus long à dire la définition. Mais plus facile à comprendre.
Cet Ubiquitous Language, un mémo n'a pas le même sens dans un contexte donné. Vous vous rappelez le sens, mais un même mot n'a pas le même sens dans un métier ou l'autre. Si je vous dis *, sans contexte, je ne sais pas de quoi on parle. Ce langage commun, il n'a pas du cielet il n'est pas imposé par des gens. Nous allons le créer ensemble en équipe. Avec des experts du domaine N, les DEV. Les personnes qui interviennent en équipe. En créant le langage, il y a des choses comme Event Storming, je fais du name-dropping, on va aller pousser le besoin. Au début, la personne arrive avec son idée. Elle ne savait peut-être pas trop. En communiquant et en nous comprenant, nous arrivons à pousser la logique de plus en plus. Nous arrivons à comprendre et à aller plus loin. C'est intéressant. Si vous utilisez ce langage commun de votre code, c'est cool. On reste dans la philosophie. C'était explicite. Nous avons d'autres manières de rendre explicites ces choses. Nous avons parlé de ce langage commun. Nous retrouvons nos amis. Les Value Objects. Nos objets auront un sens métier. Nos variables auront un vrai sens. En plus d'être valide, on va savoir à quoi s'attendre. On peut s'amuser à trouver des choses très simples. L'exemple du bateau, c'est pourri. Nous avons une entité article, pour le public et, il faut setter le statut à publish, il faut qu'elle ait une date de publication. Plutôt que de mettre ça partout, on peut faire un mutator. Quand je lis Article publish, je comprends. C'est simple à mettre en place.
Ce qu'on peut dire déjà, c'est qu'on a survolé ces trois principes. Parce que derrière, vous tapez tout cela sur Internet, l'architecture hexagonale, etc. Plein de bouquins sont écrits là-dessus. On a juste survolé, mais on a vu qu'il y a beaucoup d'idées entre eux qui sont partagées. Qu'est-ce qui nous empêche d'aller piocher dans ces choses pour en venir à nos cas à nous dans certains cas ? C'est là où on arrive à la partie de notre Use Case. Nous allons volontairement prendre un cas dans lequel ça va faire du Domain-Driven Design, de la Programmation Fonctionnelle, on pourrait pas. On va essayer de prendre ce cas.
On va essayer de garder en tête que même si on ne peut pas faire du Domain-Driven Design, on peut rester focus sur le domaine de notre application. Pourquoi est-ce qu'on connaissait l'application ? Quel est le problème qu'on peut résoudre ? Nous avons un vrai besoin intérieur, une vraie utilité. Gardons cela en tête. Le Framework aurait été choisi parce qu'il est pertinent. C'est celui qu'il faudrait utiliser pour répondre à cette problématique avec laquelle le domaine est arrivé. On ne va pas se battre contre notre Framework sans arrêt. Restons simples. Sans plus attendre, ce use case va être une application Drupal. pourquoi ? Si vous essayez de faire du Domain-Driven Design ou de l'architecture diagonale, du CQRS, ça n'aurait pas trop de sens. Vous allez vous battre contre le Framework sans arrêt. Ce serait de ne pas comprendre les liens d'intention de ces différents principes. Drupal, c'est plus un content manager Framework. C'est plutôt RAD. C'est lowcode. Et un mélange pour que si tu es DEV, tu peux faire des applications poussées. Un DEV va aller dans cette direction, et ce n'est pas celle du Domain-Driven Design. Si vous ne me croyez pas, on va prendre un cas Basic.
Drupal, au niveau de l'ORM, il va tendre vers le pattern active record plus que Data Mapper. Derrière, nous avons une sorte de couplage entre notre entité et notre source de données. C'est un peu problème. Quand nous avons un domaine riche, notre entité peut être construite avec plusieurs informations qui vont venir de plusieurs sources. On s'en fout de la source de données. Dans le cas de Drupal, si je vais tester ma méthode publish, qui ne fait pas grand-chose, je ne peux pas le faire tant que le conteneur n'est pas buildé. On est complémentaire à notre source de données. On voulait s'isoler du Framework. On essaie de faire du DDD. On s'éloigne des problématiques. On voudrait s'isoler de Drupal. Ne pas utiliser l'entité Drupal. On ferait un mapping entre Drupal et une autre entité.
Nous ne sommes pas obligés de faire que des concours de P. On peut toujours s'isoler de notre Framework tant qu'on ne le combat pas. Je vous parlais d'un cas que nous avons développé où est-ce que c'est un évaluateur du nombre de naissances. Il faut évaluer le nombre de naissances qui sont prévues dans les prochains mois. L'évaluateur en lui-même, où sont stockées les données, il s'en fout. L'évaluateur. Cet évaluateur, on pourrait le mettre dans un microservice, il est isolé. Les données, il veut seulement qu'on lui donne en entrée. Il va vous donner un résultat ou pas.
Si on continue dans cet exemple, au début, tout ce qui est dans domaine, c'est l'évaluateur qui serait dans une ligne à part. On voulait faire cela dans un crunger*. Ça se fait toute la nuit et se stocke quelque part. D'où viennent les données, ce n'est pas son problème. Il veut seulement te donner la réponse. Un Admin a voulu se projeter un peu et pouloir faire cela dans son back-office. On reste isolé de nos entrées. Il s'en fout d'où viennent les données. Le evaluate birth number, c'est un domaine service pour ceux qui veulent chercher, où on va donner en entrée nos données complexes. J'avais dit qu'on ne parlerait pas de Monade. Désolé. Mais le résultat, on pourrait dire que c'est une Header Monade. C'en est une.
Nous sommes heureux parce que notre birth number, c'est une fonction pure. Nous sommes isolés. C'est facile à tester. Nous ne sommes pas obligés de faire des concours de paix.
On revient à notre idée de langage comme dans un domaine donné. Qu'est-ce qui vous empêche d'essayer de communiquer bien dans votre équipe ? Ça me paraît logique. Mais l'expérience, on ne le fait pas forcément. Ce n'est pas parce que vous ne faites pas du DDD que vous ne pouvez pas faire du Event Storming. Ça existe pour mieux communiquer et sortir des mots-clés de besoin. Vous pouvez les mettre dans votre code pour que ce soit compréhensible par tout le monde. Ça se fait bien. Vos collègues, quand ils vous parlent, vous comprenez et vice versa. C'est sympa.
Qui dit langage commun dans un contexte donné, derrière, il faut un peu parler du contexte. Sans forcément parler de subdomaine, on peut très bien s'en inspirer pour avoir des limitations claires entre certaines features. Ma droite, ici, vous avez l'arborescence standard de module Drupal. Il n'y a rien à dire, classique.
De l'autre côté, rien ne vous empêche de faire un truc comme cela. Vous ne savez pas du tout quelle est cette appli, vous avez une idée des features qui sont dedans. Si on utilisait les termes du langage commun qu'on a vu avant, tout le monde s'y retrouve. C'est cool. On n'a pas besoin de combattre le Framework pour cela. Ceux qui font du Drupal dans la salle vont dire : tu bluffes, Drupal impose que... je leur répondrai : tu bluffes, si on regarde comment le carnet compile nos containers, il y a Entities, planning, elements. Après, c'est fini, vous faites ce que vous voulez.
Nous ne nous sommes pas battus contre le Framework. Nous connaissons l'outil. Je vous conseille de connaître l'outil. Sinon, vous allez vous couper avec le couteau. En connaissant notre outil, nous connaissons tous derrière Drupal, il y a les composants Symfony, l'injection de dépendances, on voit comment ça fonctionne. On creuse le sujet. Derrière, ça nous permet d'avoir plus de choix pour nous simplifier la vie quand nous avons besoin de ces choix.
Dans la suite, continuons notre petit cas pratique. Voyons un autre cas. C'est pareil. Un autre truc déjà vu sur un projet Drupal. Très souvent pour ceux qui en ont fait. Vous avez votre expert du domaine qui dit : Un article avec une catégorie et une couleur. On voit comment ça a été implémenté. Le truc avec YAML, vous donnez les valeurs qui sont autorisées pour être des catégories. Nous avons foo et bar. Comment c'est fait maintenant, c'est stocké en base de données. Vous n'avez aucune idée de quelles sont les valeurs autorisées pas que vous n'avez pas pioché dans la base de données ou dans le code. C'est chiant. Vous ne savez jamais si quelqu'un s'est amusé avec la base de données et a inséré un truc, n'importe quoi.
Mais derrière, nous avons un autre problème là-dedans. Pour savoir que notre article a une catégorie et que notre catégorie a une couleur, il faut deviner que nous avons un service qui s'appelle article Manager, on ne sait pas ce qu'il manage au vrai. Il faut réussir à trouver la méthode get category color. Elle va retrouver la couleur. Ce n'est pas très parlant. Cette méthode est ultra chiante à tester.
Derrière, nous pouvons faire un peu mieux. Ce n'est pas parfait. C'est pour simplifier. Sans combattre le Framework, on oublie peut-être l'interface de Drupal et on regarde comment il est codé. On va remarquer qu'on peut lui passer un callback pour voir les valeurs autorisées. Ensuite, notre article a des catégories. Rien ne nous empêche de lui mettre une méthode catégorie pour lui envoyer une catégorie. On pourrait appeler cela enum value object. Dans notre cas ici présent, ça nous convient. Maintenant que nous avons une catégorie, nous savons qu'elle est valide. Nous pouvons typer le fait que c'est une catégorie.
Et quand nous nous intéressons au résultat final, si je vous dis : un article a une catégorie et une catégorie a une couleur, c'est évident. Ma grand-mère arriverait à comprendre. Elle ne comprend pas l'anglais. Mais elle comprendrait les mots.
Si on continue maintenant, je vous avais dit qu'un était simple à tester et l'autre non, le plus simplifié, c'est le premier test. Le truc plus simple avec une seule ligne : Est-ce que c'est pertinent à tester ? C'est la première solution.
Nous pouvons essayer de parler d'application service. On en a un où on va exporter le workshop en CSV. Je lis seulement le nom pour comprendre ce que c'est. Derrière, on a mis une commande. Ça nous parle, ça nous dit quoi faire. Plutôt que de faire une Monade, on a choisi de faire file ou on envoie une erreur. C'est assez explicite de comprendre ce qu'on fait.
Je pense que dans l'idée du use case, nous avons réussi à le faire. À aucun moment, nous n'avons oublié le domaine de notre application, à aucun moment, nous nous sommes combattus contre notre Framework. Nous connaissons les outils de manière générale, nous savons ce qu'on peut faire pour se simplifier la vie. Nous sommes restés assez simples.
Ce qui veut dire en conclusion, pour ce talk, c'est toujours intéressant d'apprendre, de comprendre surtout énormément de choses. Ce n'est pas parce que vous êtes dans un contexte où, comme le Domain-Driven Design, la Programmation Fonctionnelle, un autre langage PHP, je vous encourage à aller tester plein de choses. Ce n'est pas parce que vous n'en avez pas besoin de suite ou que vous n'en aurez pas besoin dans cinq ans que ça ne va pas vous apprendre des choses que vous allez pouvoir réutiliser dans votre cas. Il faut s'adapter à toutes les situations. C'est pratique dans notre métier. Pouvoir s'adapter. C'est le cœur de métier. C'est un truc intéressant. Lire, comprendre tout un tas de choses. Je vous encourage fortement à être curieux et faire tout ça.
J'aimerais vous laisser sur une citation qui vient du livre de Éric Evans. Le Blue Book. Même si c'est un livre qui parle de DDD, cette citation est valable. Ça reste vrai dans tous les cas. Il n'y a pas vraiment de solution ultime qui existe à tous. Mais je pense que cette phrase reste vraie dans notre métier, peu importe ce que vous faites. Et sinon, faire la chose la plus simple qui puisse fonctionner. Soyons en amélioration continue. Faisons du refactoring continuellement. Améliorons le design tout le temps. La personne qui est venue nous voir au début, elle ne savait pas trop. Nous l'avons accompagnée là-dedans.
Pour ceux qui en ont envie, un peu de lecture. J'ai donné beaucoup de noms, mais je n'ai pas le temps de tout vous expliquer. N'hésitez pas à aller voir. Il y en a plein d'autres. Ça ne tenait pas sur les slides. Si vous avez des questions, n'hésitez pas. Merci à vous.
(applaudissements)
_ Merci, Benjamin. Nous avons quelques minutes pour des questions.
_ J'aurais bien aimé qu'il n'y ait pas de questions.
_ Bonjour. Super talk intéressant. Je comprends bien la dernière citation. Faire évoluer en même temps que les besoins du client, mais dans le cadre d'un projet dans du Web par exemple, en agilité, faire une structure Symfony, c'est simple au départ, en arrivant à un moment, les choses vont s'empiler et on va avoir de nouveaux besoins. À la fin, on aura une structure très proche de la structure initiale Symfony. Il y aura 500 contrôleurs, 500 Entities. Il va arriver un moment où on va se dire : On va créer des domaines et faire ce genre de choses. Dans quelle mesure c'est évident de créer cela au client ? De dire : Vos prochaines fonctionnalités qui prennent une demi-journée vont prendre trois mois. On va tout refaire pour l'intégrer d'une manière cool et lisible. Versus le coût que ça aurait coûté dès le départ pour commencer avec du domaine-driven. Est-ce que c'est facile cette frontière ?
_ Non, ce n'est pas facile. C'est quelque chose qui est fait dans le cadre d'un client où on va dire que c'est de l'apprentissage et de l'éducation au fur et à mesure. Nous avons le droit de s'être plantés. Ça fait partie du métier. Plus nous avons d'expériences... L'expérience, c'est se planter plus souvent. On a le droit d'être honnête, au début, c'était pertinent, maintenant, ça ne l'est plus. Ce n'était peut-être pas une erreur. Nous ne sommes peut-être pas obligés de tout arrêter pendant trois mois. L'idée, c'est d'y aller petit à petit. C'est souvent une erreur que j'ai vue et que j'ai commise moi-même : nous avons un projet Legacy et on se dit : Vas-y. On refait tout depuis zéro depuis le début. Le projet en lui-même, il a beau être Legacy, il a une valeur métier. Notre tâche, ça va être de comprendre et de faire des petites modifications au fur et à mesure. On ne va pas tout arrêter pendant trois mois. nous allons avoir cette discussion : Ça ne suffisait, maintenant, il faut faire autrement. C'est comme le workflow. Ça marche à l'instant T. Le contexte évolue, il faut changer. Si le client ne veut pas changer, j'ai envie de lui dire : La porte est là-bas. Si ça vous dérange, nous avons d'autres clients. Pas de souci. Nous restons dans un rôle de conseil. Il n'y a pas de magie. C'est de l'éducation. Le petit à petit. Ne pas faire le côté feature freeze. On arrête tout. On est sûr de se planter.
_ Une petite question.
Plus de questions ?
_ Merci pour la conf. Au niveau de la mise en place de DDD avec Symfony ou Laravel, est-ce qu'il existe des guides pour savoir comment commencer et démarrer un projet avec ces Frameworks ?
_ Il existe énormément de choses. Mais en Symfony et Laravel, il y en a beaucoup de qualités plus ou moins... voilà. Je ne vais pas m'étendre. L'idée, si vous voulez commencer, c'est d'oublier Symfony et Laravel. Voir comment vous implémentez les principes. Ce sera propre à votre cas. Il y a des projets comme en Java où les gens ont décidé de faire des Framework basés pour DDD. On n'a pas cela en PHP. C'est une guerre interne entre plein de gens dans le DDD. Personne n'est d'accord. Même les grands qui font du DDD, personne n'est d'accord. Quand on veut l'implémenter, il n'y a pas de choses : C'est comme ça qu'il faut faire. Un truc basique si on veut parler de DDD, l'architecture hexagonale, la comprendre. Commencer avec cela. Une des manières qui est faite, le repository, ce serait l'interface. Si vous ne l'avez pas, quel est votre point d'entrée chaque fois ? Le port que vous voulez faire ? Le blog de Tepirin a plein de choses sur la notion de DDD. Il va faire du Csharp, mais en comprenant toute la logique qui est derrière, C'est plus simple à implémenter soi-même. Dans tous les langages qui ont existé, personne n'est d'accord. Tous les exemples que vous allez trouver, vous êtes capables de dire : Oui, mais là-dedans, je n'aurais pas fait cela. Tout le monde ne va pas faire la même chose.
Tweets