L'agrégat en DDD : une frontière de cohérence pour vos invariants

· Publié le · 2 min de lecture

Pour faire du DDD tactique dans un software, il y a un élément clé : l’agrégat (aggregate en anglais).

Derrière ce nom compliqué se cache un concept simple.

La définition officielle (Eric Evans) : un groupe d’objets liés, qu’on traite comme une seule unité pour toute modification de données. Avec une racine et une frontière.

Dit comme ça, c’est abstrait. Prenons un exemple.

Un exemple : la facture et ses items

Vous avez deux entités dans votre programme :

  • Invoice
  • InvoiceItem

Avec deux règles métier qui doivent toujours être vraies (on parle d’invariants) :

  • une facture a toujours au moins un item
  • un item de facture n’existe que dans le cadre d’une facture

Maintenant, une commande de votre application crée une facture.

Elle crée les items, puis la facture, puis sauvegarde le tout…

…et il y a une erreur quelque part.

Si la facture et ses items sont persistés dans des transactions séparées, quel que soit l’ordre, une erreur au milieu viole un de nos invariants (facture sans items, ou items orphelins…).

La solution : l’agrégat

Ce pattern dit de regrouper tout ça dans un ensemble, derrière une entité racine (l’aggregate root, ici Invoice). C’est l’unique point d’entrée de l’ensemble : dès que vous touchez une partie, la root vérifie tout en mémoire, et le tout est persisté dans une seule transaction.

=> Vos invariants deviennent inviolables, y compris au moment de la persistance.

C’est pour ça qu’on dit souvent qu’un agrégat est une frontière de cohérence (consistency boundary).

Pas d’agrégat gigantesque

Attention, n’allez pas faire un agrégat gigantissime non plus. Préférez de petits agrégats : ce qui peut être cohérent « un peu plus tard » reste dehors. Mais dès que des règles doivent être garanties ensemble, à chaque instant : hop, ça va dans le même agrégat.

Placer ces frontières, c’est un travail de modélisation que je mène avec les équipes que j’accompagne.

EDIT : merci à Michaël Azerhad pour une objection 100 % juste en commentaire du post LinkedIn d’origine ! Une simple transaction suffirait en réalité comme solution au problème énoncé. L’agrégat trouve tout son intérêt pour répondre au souci de concurrence. Son commentaire explique ça parfaitement, à lire !

PS : je fais une petite série de vulgarisation de concepts au cœur du DDD (Eric Evans, Vlad Khononov… etc). C’est du survol pour vous donner envie de creuser. Foncez, c’est passionnant ;)

Sources