Le Touilleur ExpressLe Touilleur ExpressLe Touilleur ExpressLe Touilleur Express
  • Accueil
  • A propos de l’auteur
  • A propos du Touilleur Express

Formation DDD jour 2

    Home Java Formation DDD jour 2

    Formation DDD jour 2

    Par Nicolas Martignole | Java | 5 commentaires | 16 février, 2010 | 0 | 3 127 affichages
         

    Deuxième journée en compagnie d’Eric Evans, pour suivre la formation DDD (Domain Driven Design) chez Zenika. Je vous ai raconté hier dans le premier article, comment DDD était une philosophie, nous allons voir aujourd’hui la suite de l’aventure.

    Nous avons débuté la journée autour de quelques patterns utiles pour DDD. Finalement, nous en connaissons un certain nombre, mais ici il s’agit de complément un peu différent des designs patterns des Gang of Four (GoF). Nous travaillons sur notre modèle, et sur nos éditeurs Javas toute la matinée, le tout entrecoupé de discussions et de séances de travail sur tableau blanc.

    Eric nous présente les Entities et les Value-Objects. Ces marqueurs permettent de décrire rapidement les caractéristiques des objets de son modèle. J’utilise les termes anglais autant que possible, ne soyez pas étonné de lire « Entité » ou « Entity ».

    Définition d’une Entity

    Une Entité est un objet qui possède une Identité. Celle-ci est unique dans votre système, et aucun autre objet n’est identique à votre objet si son identité n’est pas identique à l’identité de votre objet.

    L’identité d’un objet peut être un champ numérique (CargoID), un GUID, une clé primaire assignée par votre ORM, bref c’est un identifiant unique. Des exemples d’entités : un client, un conteneur, un véhicule ou une place de théâtre.

    Pour comparer des Entités, il suffit donc de comparer leurs Identités et pas leurs attributs.

    Définition d’un Value Object

    Un VO est un objet caractérisé par ses attributs, qui ne possède pas d’identité. Si deux ValueObjets ont les mêmes attributs, ils sont identiques. Pour cette raison, il s’agit en général d’objets immuables, ce qui rend votre modèle plus simple. Par exemple mon Addresse postale est un ValueObject, qui sera peut-être utilisée par les autres habitants de mon immeuble. Mais dans mon système, je n’aurai finalement besoin que d’une seule instance de cette Addresse. Vous connaissez un Value Objet en Java, c’est la class String. Une String est immuable, et c’est bien sa valeur qui en fait en quelques sortes son identité. Un value object est comparé par valeur, il peut y avoir 2 instances de VO « identique », cela ne pose pas de problèmes, puisque l’objet est immuable.

    Ce qui est intéressant, c’est que cela nous amène à reprendre du code et à le simplifier. Rapidement notre application s’allège, nos méthodes pour ajouter ou retirer des itinéraires à notre envoi de conteneur sont refactorisées. Puisque nos VO sont immuables, la synchronisation est inutile.

    Il est intéressant de regarder comment rendre « immuable » une classe en Java. Je vois très bien cela comme une question à poser lors d’un entretien d’embauche. Peu de gens connaissent toutes les techniques, c’est un sujet pour Olivier du Coder’s Breakfast je pense.

    Et c’est tout ?

    Là où DDD prend tout son sens, c’est que vos objets de base vont être améliorés afin de gérer votre domaine. Nous avions hier une class Itinerary qui n’était qu’une class anémique constitué d’une liste d’étapes. Après refactoring, ce Value Object est capable de retourner de nouveaux objets Itinerary, de se valider afin de s’assurer qu’un itinéraire est valide. Il est capable de se tronquer et de retourner un segment… Bref ce que nous avons fait pendant la matinée, remet en question la modélisation objet « anémique » composé d’une Class d’une part, d’un DAO et d’un Service. En retravaillant sur la modélisation DDD, vous redonnez un rôle complet à vos objets.

    Certains patterns ne sont-ils pas uniquement technique comme les DAOs ?

    Je ne suis pas plus emballé pour l’instant. Difficile de restituer nos discussions. Nous travaillons ensuite sur l’importance de la bonne utilisation du couple equals/hashCode pour les Values Objects et les Entités, de l’importance pour les VO dont l’égalité est basée sur les attributs, et pas sur une clé technique.

    Aggregate

    Eric Evans présente ensuite un concept intéressant : la notion d’Aggregate. Il s’agit de prendre notre modèle objet simple composé de quelques classes, et de reconnaître les zones d’agrégation. Jusqu’ici vous ne comprenez rien, c’est normal. Si vous avez travaillé avec Hibernate, vous avez certainement configuré l’effacement en cascade non ? Par exemple, si j’efface un client de mon application je veux aussi effacer toutes les réservations qu’il a effectué. Par contre je ne veux pas effacer les Hôtels et les Avions qu’il a associé à ses voyages. Imaginez sur un tableau blanc les différents objets dont je viens de parler. Prenez un marqueur, et dessinez des boîtes autour des grappes d’objets qui doivent vivre ensemble. C’est pas si simple non ?
    Technique d’Eric : dessinez le modèle physique en indiquant les instances. Et en effet, si je dessine un utilisateur « Nicolas » et que je dessine ensuite deux « Voyages », l’un est lié à « Hôtel Djerba » et l’autre à « Avion New-York », que j’ajoute la compagnie aérienne pour l’avion, là il devient facile d’identifier les instances.

    En décomposant des Aggregates, vous venez de faire quelque chose de très intéressant. Que nos copains du NoSQL et du Cloud computing écoutent un peu. Il s’avère que chaque aggregat en DDD permet d’ajouter de l’Inconsistance entre les aggrégats. C’est un partitionnement du système.
    Pour en savoir plus et peut-être mieux comprendre, je vous conseille « Aggregates and Aggregates Roots »

    The Ubiquitous Language

    Après un repas très sympa, nous nous retrouvons pour parler de l’importance de la communication entre les développeurs et les gens du métier. Pour illustrer cela, Eric Evans nous montre une série de vidéo où un développeur travaille avec une personne du métier. Quelques scènes cocasses, nous retrouvons des situations vécues. Dans l’une des vidéos, la personne du métier harcèle de questions le développeurs. Et celui-ci met fin à la discussion en disant « …de toutes les façons c’est dans les specs…« .

    Le développeur vient de Mars, les clients viennent de Vénus. Je tenterai bien l’analogie avec ce best seller de John Gray mais je pense que quelqu’un aura l’idée en lisant ces lignes… Il y a un gouffre entre le développeur et le client. Ajoutez un mur de spécifications écrit pour « clarifier les choses » et pour « aider le développeur », saupoudrez d’une dose de cycle en V, et vous devriez arriver à du vécu.

    DDD met en avant l’importance du Domaine. Une leçon d’Eric est qu’il est vital de définir ce que l’on appelle « The Ubiquitous Language ». C’est un vocabulaire définit par les gens du métier, appuyé par des exemples concrets. Ce n’est pas un espace pour que le développeur se lâche avec des mots comme « Classe », « Instance », « Objet » ou même « Partition ». On parlera plutôt de « Credit », « IntérêtCumules », « Echeancier ».

    Lorsque j’étais en mission l’an passé, je garde un excellent souvenir d’une matinée de formation par une personne de la maîtrise d’ouvrage sur les stratégies de couverture et de calculs du risque financier sur les contrats dérivés.

    Si vous êtes client, allez voir les développeurs et demandez-leur de vous expliquer ce qu’ils font. Si les termes sont trop techniques, allez chercher le livre d’Eric Evans. Il fait 590 pages. Mettez un grand coup sur la tête du développeur, et ensuite commencez à reprendre le pouvoir. Ce n’est pas à vous d’apprendre la langue des Geeks. C’est au développeur d’apprendre votre langue.

    Si vous êtes développeur, j’espère que vous êtes humble. Allez chercher le livre d’Eric Evans, il fait 590 pages et il est lourd. Allez ensuite voir le client, et lorsque vous êtes devant lui, flanquez-vous un coup de livre sur la tête. Une fois le reboot effectué, écoutez humblement le client. Et repartez avec 2 choses : une liste de mots clés du projet agrémentés de définition. Et un bleu sur le crâne, preuve de votre rédemption.

    Eric nous donne quelques pistes comme celle de ne pas restreindre la conversation à ce que le logiciel doit faire, à ce que le projet est censé faire. Vous devez parler de votre métier. Il est pour travailler de manière itérative sur le modèle. C’est une notion très importante.

    Le modèle doit être itératif

    Qui a déjà déclaré des « DummyCustomer » ou des « FakeProduct » dans son code ? A quoi cela vous a-t-il servi ? Dans l’exemple étudié, le développeur utilise un objet au sens Java, pour pouvoir appeler un service de routage. Or comme le montre Eric, c’est complètement absurde. Le développeur n’a pas voulu revoir son modèle. Ce genre de code indique que votre modèle n’est pas adapté. Il montre aussi le cas d’un calcul d’emprunt. Pour gérer le remboursement anticipé, le développeur « bidouille » et crée de faux versements techniques pour que son algo de calcul de taux s’en sorte… Evidemment c’est le signe d’un cancer grave de l’application, et il faut revoir le modèle.

    Pour éviter ces cas, il nous invite à écrire des scénarii complets idéaux et des cas limites avec les personnes du métier, en utilisant les mots des clients, pas votre jargon technique. Dans une autre vidéo, nous voyons comment le développeur écoute et met en oeuvre les nouvelles techniques pour apprendre de la part de la personne du métier comment faire.

    Je constate la chose suivante : plus les gens du métier sont loins de votre clavier, plus la bonne réalisation du projet sera dure.
    Une structure où l’on fait reposer à une jeune maîtrise d’ouvrage la responsabilité de « capturer » la sacro-sainte connaissance des « gens du métier » ira dans le mur. C’est un principe de base du développement logiciel. Si ton client n’est pas disponible, alors ne fait pas le projet. Si tu ne rencontres pas d’utilisateurs finaux et que ton seul interlocuteur est un document Word, alors refuse le projet.

    Conclusion

    Nous avons ensuite travaillé d’autres concepts, comme l’idée d’historise les changements d’états de certains objets clés dans des objets, le pattern « Domain Events », ce fut intéressant. Sur le rythme de la formation, ce fut parfois un peu lent et pas toujours assez rythmé.

    Entity, Value Object et Aggregator sont des patterns où les objets mélangent un état (State) et des comportements (Behaviors). Après cette deuxième journée, on comprend que les patterns classiques s’adaptent à la philosophie DDD. Il semble aussi qu’il existe des anti-patterns DDD comme les objets Anémiques, les multiplications de couches avec des DAO sans valeur ajoutée… Bref je pense qu’à l’issue de la formation j’aurai acquis non pas une nouvelle langue, mais une nouvelle culture.

    La suite demain. Et n’oubliez pas que ce mercredi 17 février il y aura une présentation de DDD par Eric Evans.

    Articles similaires:

    Default ThumbnailFormation Domain Driven Design avec Eric Evans – jour 1 Default ThumbnailJour 3 Formation JBoss for Advanced J2EE developers in Berlin Default ThumbnailJour 2 Formation JBoss for Advanced J2EE developers in Berlin Default ThumbnailJour 4 Formation JBoss for Advanced J2EE developers in Berlin
    ddd
    • Avatar
      Loïc 17 février 2010 at 8 h 59 min

      A noter que les « Entity » sont des « Class » en UML, et les « Value Object » des « Datatype »… L’aggregation y est présente mais il ne font pas mélanger avec la composition.

      J’irais quand même lire le livre mais finalement on dirait juste qu’il faut s’abstraire du code avant de programmer, non ?

      Tout comme utiliser le vocabulaire client doit être la recommandation la plus enseignée (certes aussi la moins appliquée)…

      Je recommanderai le livre « Requirements Engineering » qui expose une méthode permettant de décrire le modèle client avant de dériver le modèle du code.

    • Avatar
      Frédéric 17 février 2010 at 13 h 01 min

      Au sujet des agrégations, je me demande si ce concept est différent du concept d’association cher aux merisiens.

      En tout cas, merci de l’article et de nous faire partager ces informations sur le DDD.

    • Avatar
      Piwaï 17 février 2010 at 13 h 18 min

      Intéressant… Je me pose une question : est-ce qu’on dispose en Java de classes de listes/map immuables ? Je ne parle pas de Collections.unmodifiableList, mais plutôt des listes / maps telles que présentées à la conf sur Clojure, sur lequelles les opérations de modifications retournent une liste prenant en compte la modification.

      D’autres part, à votre avis est-ce qu’il serait facile de vérifier programmatiquement qu’une classe est immuable ? C’est une question ouverte…

    • Avatar
      Olivier 18 février 2010 at 9 h 14 min

      Concernant l’aspect technique: si vous voulez ‘jouer’ avec ces notions, alors je vous conseille ce formidable framework, trop méconnu: Fornax Sculptor.

    Recent Posts

    • GitHub Actions : le tueur de Jenkins ?

      Avouez-le : ce titre de blog est super racoleur. J’avais aussi pensé

      15 février, 2021
    • Comment recréer du lien social dans l’Entreprise avec des outils numériques en 2021

      Nous sommes en février 2021 pendant le 3ème confinement lié à la

      10 février, 2021
    • FizzBuzz en Java et Scala (surtout Scala)

      L’exercice FizzBuzz est un petit exercice très simple, à tester par exemple

      9 février, 2021

    Recent Tweets

    • RT  @JosePaumard : Il y a tout juste un an j'ouvrais ma chaîne de cours Java en ligne (près de 80h de cours), c'était la fermeture des univer…

      12 hours ago
    •  @ShirleyAlmCh  Ça fait du bien de te lire

      13 hours ago
    • RT  @kimchy : great read from  @ldoguin  on putting customers first to the benefit of all by cloud vendors, wonderful to see it embraced by  @cl …

      22 hours ago
    •  @juliendubois   @alexismp  Interesting. However I tweet mostly in French so how accurate is this graph ?

      1 day ago
    • Et hop, voici la future liste des talks 2021 https://t.co/kQPehA8uzx avec encore quelques ajustements à faire (masq… https://t.co/mIDLEw0sML

      2 days ago

    Mots clés

    agile (18) ajax (11) Apple (11) architecture (6) barcamp (5) BarCampJavaParis (5) ddd (5) devoxx (33) esb (6) exo (6) flex (9) geek (5) google (11) grails (5) groovy (10) humeur (12) humour (7) independant (6) iphone (12) Java (77) javascript (7) jazoon (28) jboss (22) jboss seam (12) jsf (9) jug (16) Linux (11) mac (6) mule (5) parisjug (7) paris jug (22) pjug (6) play (8) playframework (6) portlet (5) recrutement (6) ria (8) Scala (21) scrum (44) spring (23) Startup (11) usi (21) usi2010 (9) web (16) xebia (7)

    Le Touilleur Express

    Contactez-moi : nicolas@touilleur-express.fr

    Suivez-moi sur Twitter : @nmartignole

    Copyright© 2008 - 2020 Nicolas Martignole | Tous droits réservés
    • A propos de l’auteur
    • A propos du Touilleur Express
    Le Touilleur Express