DDD Mercredi 9 Octobre 2019


Format : Forum ouvert

17 Participants

Sujets choisis :

DDD

Comment adopter le DDD, comment le vendre ? Pas besoin d’un petit projet (1 semaine, 3 semaines ou 6 mois ?). Les problématiques métiers complexes sont envisageables.

Comment définir le DDD -> différences entre pattern tactiques et stratégiques.

Est-ce beaucoup utilisé ? Il y a beaucoup de ressources sur internet, sur le bassin lyonnais il existe des entreprises qui accompagnent. DDD au quotidien d’Emilien Pecoul -> On peut commencer avec certains concepts au jour le jour. Le DDD n’est pas une méthode mais une approche, une boîte à outils. Seul dans une équipe, on peut le faire sans utiliser les mots techniques : plus tu montres, plus tu as d’adoption.

Maturité pour introduire l’architecture hexagonale

Lors d’un stage, un participant a fait du travail en architecture hexagonale (ou onion). Les juniors n’ont pas modifié l’archi et n’ont pas cassé le code. L’isolation était agréable, mais les juniors avaient du mal à suivre le code. Par contre personne ne savait ce que le métier faisait -> Certains trouvent ça dommage, car l’archi hexagonale facilite cela.

Est-ce qu’avec un MVC ça se serait mieux passer ? La majorité des MVC sont focus sur la base de données et créent de la complexité dû à la différence entre les besoins métiers et les contraintes de la base de données. Le MVC est une méthode de l’interface, donc il n’y a pas forcément de différence.

Aggregate & Bounded Context

Qui définit le BC ? L’équipe décide car tout le monde doit connaître les limitations pour trouver la bonne solution. Le BC va changer, donc il faut accepter que l’on puisse changer la base de code.

Dans les patterns tactiques, il y a 4 concepts qui permettent de comprendre les aggrégats :

  • Le Value Object : identifié par ses valeurs (Pression de pneu)
  • L’Entité : identifié indépendemment de ses valeurs (Pneu avant droit)
  • L’Aggrégat : groupement d’entité qui garantit la cohérence des entités (Voiture avec 4 pneux)
  • Le Domain Service : ce qui permet de faire discuter différents aggrégats (Le service qui fait l’inventaire des pneux dégonflés)

Pas d’aggrégat dans un autre aggrégat.

Domaine en français

Faut-il traduire les concepts en français quand ils n’existent pas en anglais ? Pourquoi pas traiter les termes français comme des noms propres, mais sans accents pour éviter les problèmes liés à l’unicodes. Il faut aussi que l’équipe soit d’accord. L’exercice de traduction peut permettre d’affiner les termes. On peut aussi faire un lexique généré automatiquement.

La différence de langage permet aussi de séparer le code technique (en anglais) et le code métier (en français).

Persistence Aggregate / Domain Event

Pour séparer infra et domaine, quoi persister ? Plusieurs options :

  • Aggrégat qui émet un événement : testable sans mock
  • On injecte un handler dans l’aggrégat : aggrégat testable avec un mock
  • Aggrégat capable de retourner une vue de son état actuel

Retour des participants

  • ROTI 2/5 -> 1
  • ROTI 3/5 -> 3
  • ROTI 4/5 -> 12
  • ROTI 5/5 -> 1

Les feedbacks :

  • Les réponses sont souvent les mêmes pour ceux qui viennent souvent, malgré les sujets intéressants
  • Sympa ça donne des retours intéressants
  • Pour les novices, le groupe peut paraître assez obscurs alors que tout le monde est super accueillant -> les coding dojos sont plus accessibles
  • J’ai appris à plus comprendre le métier, et on quitte les séances avec plus de questions que de réponses
  • L’ouverture sur le sujet est large, du code à l’organisation de l’équipe
DDD  unconf