GLO-4002 - Site du cours 2024

DDD : Aggrégats

Vue d'ensemble

Un aggrégat est un regroupement d'objets. C'est un concept assez simple mais qui cache de nombreuses subtilités. Commençons par les règles de base d'un aggrégat

  • Une frontière claire : les objets qui font partie de l'aggrégat sont internes à celui ci, les objets qui n'en font pas partie sont externes.
  • Un point d'entrée unique : les objets externes inter-agissent avec l'aggrégat via un seul objet qui s'appelle la tête d'aggrégat.

Règle fondamentale d'un aggrégat : tous les interactions provenant d'objets externes doivent passer par la tête d'aggrégat

Cela signifie que les objets externes ne peuvent pas manipuler les objets internes, ils ne peuvent interagir qu'avec la tête d'aggrégat. Généralement, les aggrégats ne doivent pas avoir de "fuites", c'est à dire que la tête d'aggrégat ne doit pas passer de références vers ses objets internes à l'extérieur.

Vue d'ensemble d'un aggregat

Pourquoi des aggrégats?

À votre avis, pourquoi utiliser des aggrégats dans votre domaine? A. Rendre les objets internes immuables B. Simplifier les interactions entre les objets du domaine C. Préserver des règles d'intégrité du domaine D. Rendre le cours plus compliqué pour les étudiants

Réponse B et C :

B: Très souvent, la complexité du domaine, et notamment les interactions/relations entre ses différents concepts, ne peut être représentée telle qu'elle dans le code. C'est une sur-simplification de penser que l'orienté objet a pour but de représenter la réalité. En empêchant des interactions directs avec ses objets internes, l'aggrégat permet de simplifier le modèle d'interaction dans le code.

C: La tête d'aggrégat joue un rôle clé pour maintenir l'intégrité du domaine. En tant que point d'entrée des interactions externes à l'aggrégat, elle s'assure que l'état interne de l'aggrégat reste cohérent dans le temps.

La réponse A est fausse car on n'empêche pas les objets internes de changer, on veut simplement contrôler la façon dont ils sont manipulés.

La réponse D est fausse car le cours est assez compliqué sans devoir en rajouter :)

Exercice

Notre logiciel de gestion de clinique a du succès, de nouveaux besoins apparaissent notamment pour gérer l'assurabilité des patients. Ouvrez le code dans ce repository github, vous y trouverez un exemple d'aggrégat :

  • la tête d'aggrégat est PatientAssurable, elle contient un HistoriquePatient
  • un HistoriquePatient contient les dates significatives dans la vie du patient (naissance, inscription, décès) ainsi que la liste des SejoursHorsQuebec
  • un SejourHorsQuebec contient une date de départ, une durée en jours et une raison (séjour personnel ou professionel/études)

Prenez le temps de lire le code, quel diagramme correspond au design de ce code?

Diagramme

Reponse 1.

  • La reponse 2 est fausse car un HistoriquePatient ne donne pas accès à HistoriquePatient (pas de méthode obtenirHistorique). Cela briserait l'encapsulation de l'aggrégat.
  • La reponse 3 est fausse car un PatientAssurable n'a pas de SejourHorsQuebec directement.

Implementation de l'aggregat

Ouvrez le code dans le projet clinic-aggregate, votre but est de faire passer les tests unitaires en implementant l'aggregat PatientAssurable.

  1. Commencez par faire passer les tests de SejourHorsQuebec
  2. Ensuite, faites passer les tests de HistoriquePatient
  3. Terminez par faire passer les tests de PatientAssurable

Pour chaque serie de test, facilitez-vous la vie en les faisant passer un à la fois et non tous d'un coup !

suivant