Ce que je comprends de la conception pilotée par le domaine

DDD 101

Plus le projet est grand, plus il est difficile de le maintenir. Une façon d’aider à cela est de diviser l’application en plus petits domaines selon leurs règles commerciales, connues sous le nom de domaines.

Basiquement, un domaine est un domaine de connaissances, soit public, comme les règles des échecs, soit privé, comme les règles commerciales d’une organisation à but non lucratif.

Un domaine complexe est susceptible d’utiliser des connaissances provenant d’autres domaines. Par exemple, une ASBL qui enseigne les échecs en ligne connaîtra les échecs, l’enseignement par le biais de plateformes en ligne et, même si vous n’êtes pas facturé en tant qu’étudiant, ses finances.

Chaque sous-domaine de votre domaine est connu dans DDD comme des contextes délimités, chacun a son propre modèle du monde construit avec des unités de code spécialisées, connues sous le nom de blocs de construction. Ici, je vais me concentrer sur les entités et les objets-valeurs, les deux peuvent être référencés comme des objets.

Les entités sont des objets censés être uniques dans le domaine. Ceci est réalisé en utilisant une ou plusieurs propriétés pour identifier une entité donnée. Par exemple, deux utilisateurs utilisant le même nom dans un système auront toujours des courriels différents, car les courriels ne peuvent pas être répétés – le plus souvent, les entités sont différenciées par un id, et parfois par une combinaison de propriétés.

Les objets-valeurs, en revanche, n’ont pas d’identité, donc seules leurs propriétés peuvent être utilisées pour distinguer deux instances. Prenez par exemple deux pions (le jeton d’échecs), ils ont la même apparence s’ils proviennent du même jeu et ont la même couleur, donc cela n’a pas d’importance si vous les échangez. En DDD, les objets-valeurs sont immuables, il est donc plus facile de raisonner avec eux.

Intégrité des données

Un contexte borné n’expose pas tous ses objets pour garantir son intégrité des données. Au lieu de cela, il expose certaines racines d’agrégats comme une sorte d’interface publique à lui-même.

Un agrégat n’est rien d’autre qu’une entité qui est composée d’autres objets. Pour être plus précis, un agrégat est un groupe d’objets associés que nous traitons comme une unité lors de la modification des données.

En termes pratiques, les agrégats prendront la forme de la structure de données connue sous le nom d’arbre. Et pour cette raison, tous les agrégats ont une racine.

Le seul membre d’un agrégat auquel les autres objets peuvent se référer est sa racine, et c’est donc ce que nous exposons. On procède ainsi parce que cela empêche les autres objets de modifier les données d’une manière que l’agrégat ne peut pas contrôler.

Important de préciser qu’un contexte borné pourrait utiliser de nombreux agrégats même si leur racine n’est pas directement exposée au monde extérieur.

Gérer de multiples contextes bornés

Mais les choses peuvent devenir plus compliquées, n’est-ce pas ? Chaque contexte délimité obtient un modèle légèrement différent des mêmes objets, ayant des propriétés et des comportements différents. Ainsi, un utilisateur dans un contexte de jeu peut avoir une propriété pour gérer son score qui, dans un contexte financier, n’est pas pertinente et n’existe donc pas.

Et ce n’est pas tout. Il est également possible qu’un concept de domaine, représenté comme une entité dans un contexte borné, soit représenté comme un objet-valeur dans un autre, ou tout simplement qu’il soit complètement omis.

Par exemple, alors que le contexte d’enseignement exige que les enseignants soient représentés en tant qu’entités afin qu’ils puissent être assignés aux étudiants par leurs ids, le contexte financier préfère voir « enseignant » comme une valeur pour la propriété position de l’entité employé.

Certains des autres blocs de construction DDD sont les services, les référentiels, les usines et les événements. Je vais essayer de les décrire brièvement.

Les services sont des capacités d’un domaine qui ne correspondent pas naturellement aux entités ni aux valeurs-objets. Attention, ce sont des services de domaine, pas des services d’application ou d’infrastructure.

Les dépôts sont des ponts vers les unités de stockage – bonjour CRUD !

Les fabriques sont des méthodes pour créer des objets de domaine afin qu’ils n’aient jamais de valeurs invalides. Cette partie est ce qui m’a fait commencer à penser aux tests pilotés par les produits.

Les événements sont des objets qui représentent quelque chose qui s’est passé dans le domaine – ses experts s’en soucient. De grandes opportunités pour créer une application pilotée par les événements.

Bien que je ne me souvienne pas qu’Evans l’ait déclaré, les contextes délimités sont une belle opportunité de diviser votre code en microservices, où chaque service est un contexte à part entière. La première étape pourrait être une rupture « virtuelle » où chaque contexte est mis dans un module différent sur la même application, puis si vous détectez qu’ils sont vraiment isolés, déplacez-les vers des modules différents.

Un langage pour les gouverner tous

L’une des premières choses que les gens apprennent en étudiant DDD est que leur système devrait être décrit par un langage omniprésent. C’est-à-dire que nous devrions écrire du code en utilisant les mêmes verbes (pour les méthodes ou les services) et les mêmes noms (pour les objets) que les experts du domaine utilisent lorsqu’ils nous parlent.

Écrire du code de cette façon a l’avantage de combler le fossé de communication entre les développeurs et les experts lorsqu’ils parlent, mais c’est une simplification excessive de la vie réelle, donc je l’utilise personnellement comme une ligne directrice mais pas comme une solution finale.

Je l’ai gardé pour la fin car, pour moi, la chose la plus importante sur DDD n’est généralement pas lue, car elle se trouve dans la partie « complexe » du livre.

Récemment, j’ai appris que l’auteur lui-même a dit que l’ordre dans lequel il présente les choses dans le livre n’est pas optimal, et ce que j’ai décrit ici est plus proche de ce qui aurait été idéal 😍. Je l’ai entendu sur un podcast faisant référence à celui-ci

.