GLO-4002 2026

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).

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

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 façon 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?
☑️ Solution

Faux. Le coeur de l'application devrait être basée 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 revisite dans les concepts d'architecture hexagonale.
  • Dans le domaine, on veut prioriser des noms qui correspondent au langage des experts. Cependant, il est tout à fait possible d'y trouver des noms davantage reliés aux solutions utilisées par les développeurs tels 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?
☑️ Solution

Bon:

  • Les concepts de Bateau et de Conteneur sont bien présents
  • Des Conteneurs peuvent être 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 une capacité en terme d'espace mais aussi de poids. Modifiez le code pour représenter ce concept.