GLO-4002 - Site du cours 2024

DDD : Le langage ubiquitaire

Concept

Veuillez lire ce court article qui explique le concept.

Exercices

  1. Résumez le concept d'ubiquitous language avec vos propres mots. Partagez vos idées et vos questions avec votre équipe sur Discord.

  2. Listez les concepts du domaine que vous retrouvez dans le code de l'exercice de la gestion de clinique (devoir de la semaine 2).

- Clinic
- Triage
- Symptom
  1. Quels sont les risques de ne pas avoir un langage commun entre développeurs et experts du domaine?

La collaboration entre développeurs et experts s'affaiblit dans le temps. Chacun développe son propre vocabulaire sans bien comprendre ce que veut dire l'autre. En plus de créer de la confusion et des rencontres de travail frustrantes, cela amène un manque de rigueur dans la compréhension du besoin. Les requis d'affaires deviennent ambigus ce qui augmente le risque de defects.

Par exemple, revisitons l'exemple de la clinique. Le concept de Patient est représenté de facon très sommaire : par son nom, une String. Imaginez-vous les risques de ne pas représenter correctement le concept de patient, de ses antécédents médicaux, de ses allergies connues, de sa couverture d'assurance?

  1. Pour respecter l'utiliser de l'ubiquitous language, les développeurs n'ont pas le droit d'employer d'autres mots que que ceux du domaine dans le code. Vrai ou faux?

Faux. Le coeur de l'application devrait être baséee sur le domaine, mais...

  • Certaines parties du code sont plus reliées à la technologie (par exemple pour interagir avec une base de données). Cela se revisité dans les concepts d'architecture hexagonale.
  • Dans le domaine, on veut prioriser des noms qui correspondent au langage des experts. Cependantm il est tout à fait possible d'y trouver des noms davantage relié aux solutions utlisées par les développeurs tel que des design pattern (Par exemple, une classe PatientFactory ou TriageStrategy seraient tout à fait appropriées dans le domaine).
  1. Ouvrez le projet dans ce repository github, il s'agit d'une application simpliste de réservation de conteneurs sur des bateaux de transport inspirée du livre "Domain Driven Design : Tackling Complexity in the Heart of Software" de Eric Evans. Quelles sont les bonnes et moins bonnes utilisations du ubiquitous language que vous y voyez?

Bon:

  • Les concepts de Bateau et de Conteneur sont bien présents
  • Des Conteneurs peuvent etre réservés sur Bateau tant que leur taille ne dépasse pas la capacité restante

Moins bon:

  • On parle parfois de cargaison et parfois de conteneur, est-ce une erreur de refactoring (renommage partiel) ou bien cela cache-t-il une incompréhension du domaine?
  • On peut réserver 2 fois le même container? Il semble manquer un concept important...

Bonus:

  • Les résultats de réservation (boolean) et la gestion de la capacité (integer) semblent simplistes. Cela sera abordé dans le cours sur l'obsession des primitives.
  1. La gestion des conteneurs est plus compliquée qu'il n'y parait. Il ne s'agit pas seulement de leur taille mais aussi de leur poids. Un bateau a un capacité en terme d'espace mais aussi de poids. Modifiez le code pour représenter ce concept.
retour au curriculum