Transcription

• Speaker #0

  Bonjour et bienvenue sur le premier épisode du podcast PunkinDev. Dans tout domaine, toute discipline, il convient avant toute autre chose de définir proprement les termes que nous allons vouloir employer par la suite. Je vais donc aujourd'hui vous parler de DDD. Est-ce que vous avez déjà entendu cet acronyme ? DDD ? La première fois que je l'ai croisé, c'était autour de 2015, dans une annonce de poste d'une boîte qui m'intéressait un petit peu plus que les autres. J'avais absolument aucune idée de ce que ça pouvait bien être. Mais tout arrogant que j'étais, je me suis dit que c'était sûrement quelque chose comme TDD ou un concept qui devait être à la mode et que lire 2-3 articles en ligne... allait me suffire en saisir l'essence, et puis avec ça je me disais que j'allais pouvoir faire illusion en entretien. Et là, j'ai fait deux constats. Le premier, c'est que non, ça marche pas comme ça. DDD n'est pas un concept vite fait, comme ça, un peu à la mode, et qu'on peut saisir en deux-trois lectures. Le deuxième constat... que j'ai fait, c'est qu'en 2015, les articles qui ont été renvoyés par Google n'étaient pas forcément super accessibles. Disons que c'est le souvenir que j'en garde aujourd'hui. Des articles qui étaient compliqués, dans lesquels j'avais du mal à comprendre de quoi en parler. C'est le souvenir que j'en ai. Peut-être que ce n'était pas le cas, mais vraiment c'est la sensation, le sentiment que j'en garde aujourd'hui. Pour vous éviter ce même écueil, aujourd'hui je vais essayer de proposer une définition la plus synthétique possible de ce qu'est le DDD à mon sens. Il y aura certainement des raccourcis par rapport aux définitions plus académiques, mais aujourd'hui c'est ce que je retiens de DDD. Commençons par être réfactuel. DDD est un acronyme pour Domain Driven Design, ou conception pilotée et dirigée par le métier. Ces bases ont été posées par Eric Evans en 2003 avec la sortie de son livre Domain Driven Design, Tackling Complexity in the Heart of Software. L'idée qu'a portée Eric Evans à ce moment-là, elle tournait autour de la gestion de la complexité qu'on trouve quasi systématiquement dans tout logiciel. La finalité de son approche, c'est de permettre la gestion et le contrôle de cette complexité. On s'est presque tous retrouvés devant une application plus ou moins vieillissante. avec un bug à corriger, à se poser la question fatidique. Où est le code qui implémente ce comportement ? Et la réponse ressemble souvent à un peu partout. Généralement avec l'option, t'as pas fini de galérer. Je vais essayer maintenant de vous proposer une petite expérience de pensée. Imaginez. Juste imaginez, vous arrivez sur un projet, disons de vente en ligne. On vous demande de rajouter un nouveau modèle de calcul de promotion sur le rayon bibliothèque. On va vendre des livres et puis on va avoir vraiment un nouveau modèle de promo. On va gagner plein d'argent avec ça. Imaginez toujours, vous ouvrez votre code base, vous prêchement téléchargez et... Comme c'est la première fois que vous travaillez dessus, vous ne savez pas trop comment chercher, alors vous faites une bête recherche textuelle avec les mots-clés promotion et bibliothèque ou livre Imaginez, de manière un peu magique, vous tomber sur une liste de fonctions qui traitent chacune du mode de calcul d'une promo, et qu'à côté de ça, vous avez aussi une fonction logique qui appelle le bon mode de calcul, d'un seul coup, comme ça. Ça a l'air sympa, hein ? Personnellement, j'en ai rêvé pendant des années. Faire une recherche textuelle et bam, comme ça. Premier coup, tomber sur ce que je cherchais. Conceptuellement, c'est ce vers quoi l'approche DDD voudrait aller. Mais avant d'aller plus loin, définissons un petit peu plus DDD. DDD n'est pas un framework. C'est pas un design pattern. DDD est une boîte à outils, un ensemble de pratiques dont la finalité est de garder le contrôle sur la complexité du code. Pour ce faire, il existe deux angles d'attaque. L'angle stratégique d'abord. Comment faire en sorte que l'équipe de développement saisisse au mieux le métier à implémenter et que celui-ci se retrouve au-dessus de la situation ? dans le code de manière claire. Un élément de réponse se situe dans les éléments de langage utilisés par le métier. Ces éléments de langage, cette terminologie, tout ça doit être retrouvé dans le code. Ce doivent être les mêmes mots, les mêmes termes. Votre client parle de caddie sur son site de vente en ligne ? Ne renommez pas en panier juste parce que c'est le terme auquel vous êtes habitué ou qu'on voit sur la plupart des sites. S'il nomme ça caddie, Gardez caddie, ça facilitera les échanges. Accordez également la plus grande importance au contexte dans lequel est utilisé chaque terme. Pour le marketing, un article, en général ça va être un nom, une photo, une couleur, des choses comme ça. Pour la logistique, un article, avec le même terme, mais il sera défini par son poids, ses dimensions, son packaging. On parle à chaque fois d'un article, mais ça ne porte pas les mêmes informations. Ça n'a pas le même sens. Adaptez-vous à votre interlocuteur. Si vous avez une brique logistique, vous avez un article, il y aura les informations de poids, de dimension. Si c'est une feature pour le marketing, il y aura d'autres informations. Ce n'est pas le même article. Ne faites pas un super article qui porte absolument toutes les informations. Ce sera contre-productif et vous allez vous y perdre. Si vous avez intégré ces deux notions, le langage, les termes à utiliser, et les contextes dans lesquels on les utilise. Bravo ! Vous savez maintenant ce que veulent dire Ubiquitous Language et Bounded Context. Ce sont deux termes propres à la culture DDD. L'Ubiquitous Language, c'est le langage commun. Faire en sorte que le langage utilisé par le métier se retrouve dans le code, et que quand quelqu'un arrive et lit le code, il puisse retrouver le métier naturellement. Le Bounded Context... On parle vraiment là du contexte dans lequel on utilise chaque terme. Ce qui est vrai dans le métier doit être vrai dans le code. Pour faire émerger ces langages, ces contextes métiers, il existe tout un tas d'outils, comme le BDD, le Behavior Driven Development, l'Event Storming, mais ils seront l'objet de futurs épisodes. Ce sont des thèmes à part entière que j'aborderai plus tard. Venons-en maintenant au second angle d'attaque. L'angle... tactique, un petit peu plus technique, on va dire. Ou comment faire en sorte que le cœur de métier reste visible, accessible et maintenable à moyen et long terme. Si on se réfère à notre précédente expérience de pensée, vous noterez que je n'ai même pas évoqué d'interface utilisateur, de base de données ou de web service ou de choses comme ça. Pour cause, c'est bien le but de l'approche. Faire en sorte que les contraintes... purement techniques, ne viennent pas polluer les traitements business. Quand un client nous demande une nouvelle fonctionnalité, il suffit bien de savoir qu'on stocke dans une base relationnelle, un fichier XML, ou je ne sais quelle source de mémoire, du NoSQL, ce que vous voulez. Lui, en général, il ne voit dans sa demande qu'un moyen de gagner du temps, potentiellement de l'argent, ou de se simplifier la vie. Il va donc falloir se concentrer sur cette valeur, et repousser le plus possible les questions d'implémentation technique comme le choix d'un framework, d'un moteur base de données, toutes ces choses-là. Je ne dis pas que ces éléments-là ne sont pas importants, mais ils doivent venir dans un second temps. Idéalement, le code métier sera écrit dans le langage de votre choix, mais de la manière la plus pure possible. Par pure, j'entends ici l'absence de toute librairie externe. Pas de web service, pas de sérialisation. Pas d'accès réseau, pas d'accès base de données. Seulement les briques les plus élémentaires de votre environnement de dev. Le langage en lui-même, son système de type natif, et éventuellement des outils qui vous permettraient d'implémenter des particularités métiers, comme des outils mathématiques, des traitements de collection. Quand j'explique tout ça à des gens qui ne connaissent pas DDD, qui ne sont pas habitués, on me rétorque généralement, oui mais il va bien falloir les sauvegarder les données à un moment. Ah oui, c'est vrai. Mais c'est là que l'inversion de dépendance entre en scène. Pas besoin de savoir comment je vais sauvegarder pour intégrer une action de sauvegarde dans mon code. La plupart des langages objets, ils possèdent un concept d'interface. Ce concept permet de définir un contrat sans se soucier de son implémentation. L'avantage de cette approche, c'est qu'elle va nous permettre de créer la valeur pour le client sans s'arrêter sur des détails techniques. Si on va jusqu'au bout de ce raisonnement, on peut même se simplifier les choses et proposer... du maquettage fonctionnel très rapidement en choisissant de sauvegarder seulement mémoire, le temps de présenter la feature au client. Et ensuite seulement, quand la valeur créée est bien conforme à ce que le client attendait, on va pouvoir faire jouer notre expertise technique, choisir un moteur de base de données, le plus pertinent dans notre cas, ou tout autre outil qui va bien. Cette approche va globalement à contresens de ce qu'on apprend à l'école ou de ce qu'on peut voir dans énormément de projets. J'ai généralement vu un projet qui démarre par une conception d'une base de données, avec un joli modèle. avec la normalisation, des index, tout plein de tables. Et on part de cette table et ensuite on va lui créer plein d'opérations, de lecture, d'écriture, d'indexation, alors qu'on ne sait même pas comment vont être lues les données, ni comment elles vont être utilisées. Gardons les choses dans l'ordre le plus pertinent possible. D'abord un traitement métier, d'abord du business, de l'argent pour le client, c'est quand même lui qui paye, et ensuite... On fait un petit peu la base besoin technique. Éventuellement, on se fait plaisir avec des outils qui peuvent être sympas à utiliser. Il existe énormément de patterns tactiques qui permettent d'arriver à ce résultat. Architecture hexagonale, en oignon, CQRS, il y a tout plein de choses. Cette pratique évolue constamment et aucune ne constitue en elle-même une solution idéale. Chaque projet a ses contraintes. Du coup, chaque projet aura des patterns plus ou moins adaptés. Voici donc globalement une très brève introduction au DDD. Il y a encore énormément de choses à en dire, et c'est pour cette raison que j'y reviendrai dans d'autres épisodes. Mais s'il y a vraiment un concept central à garder, selon moi, c'est de faire en sorte que la valeur métier, la valeur business, le domaine du domaine Driven Design, reste toujours prioritaire dans nos préoccupations, et que nos codebases soient suffisamment claires pour y accéder rapidement et simplement sans se perdre dans des considérations techniques un peu trop complexes. Pour cela, pas besoin de notion d'architecture, de framework compliqué, juste une excellente compréhension du métier et une bonne maîtrise des fondamentaux du langage de programmation utilisé. Si ces concepts vous intéressent, je vous conseille de vous tourner vers les meet-ups et les user groups de votre ville. Les crafters lyonnais proposent une soirée DDD tous les mois, un meet-up DDD existe également sur Paris, un Slack DDDFR existent aussi. Je me permets enfin de vous proposer quelques noms à suivre sur Twitter. Il y a d'abord Thomas Pirin, Emilien Pécoul, Cyril Martraire, ou encore Arnaud Lemaire, pour ne citer qu'eux. Ce sont des gens dont j'ai beaucoup appris au fil du temps, à lire ce qu'ils publiaient sur Twitter, sur leurs blogs respectifs. Il y a beaucoup de choses à en apprendre. Je vous invite aussi à aller regarder leur conf disponible sur YouTube. Plonger au cœur de DDD est parfois difficile, mais c'est là un voyage sans fin vers une nouvelle façon d'aborder l'activité de dev. Que cet épisode vous ait plu ou vous paraisse encore incomplet, vous avez la possibilité de venir en discuter avec moi sur Twitter, sur LinkedIn ou dans la section commentaires de mon blog punkindev.fr. A bientôt pour un prochain épisode. D'ici là, cliquez bien, faites des biens.