Langage ubiquitaire

La conception pilotée par le domaine (DDD) n’est pas un sujet nouveau (Eric Evans a formalisé le concept il y a plus de dix ans). Cependant, il est curieux de voir comment, jusqu’à aujourd’hui, les concepts de base sur le sujet suscitent l’intérêt, notamment dans les communautés .NET. Plus étrange encore est la façon dont ces mêmes concepts sont mal interprétés.

Le fondement de DDD réside dans le concept de langage omniprésent. Il ne réside pas dans la détermination de ce qu’est une entité, un objet de valeur, un agrégat, un service ou un dépôt.

L’impression que nous avons est que toute personne qui commence à étudier DDD lit les premières pages du livre d’Evans ou du livre de Vernon et saute rapidement aux pages qui décrivent les patterns.

Nous parlons souvent à des informaticiens qui pensent qu’avoir un langage ubiquitaire défini signifie que le nom des classes et des propriétés, écrites par des programmeurs, se conforme au vocabulaire des experts du domaine. Cependant, il s’agit d’une simplification grossière.

Pour comprendre l’importance du langage ubiquitaire, commençons par l' »entité » listée ci-dessous :

public class Employee{ public string Id { get; set; } public string Name { get; set; } public string Cpf { get; set; } public decimal Salary { get; set; }}

Voici un excellent exemple de mise en œuvre anémique ! Mais avant de poursuivre votre lecture, essayez de comprendre pourquoi.

Dans notre travail quotidien, lorsque nous utilisons cet exemple, nous entendons des suggestions selon lesquelles cette classe manque de comportements (Ce qui est juste !). Cependant, lorsque nous demandons quels seraient ces « comportements », nous constatons que les gens répètent des arguments génériques (de personnes qui n’ont pas non plus « compris » l’idée) et ne peuvent pas identifier ce qui ne va pas !

L’un des arguments les plus fréquents est que les setters de propriétés devraient être privés. A leur place, nous devrions avoir des méthodes « DefineXXX » qui implémenteraient des validations. Cette idée n’a aucun sens car le but des setters est précisément de fixer les valeurs des propriétés, et il n’y aurait aucun problème à y implémenter une logique de validation.

Les méthodes d’une entité doivent expliciter les motivations de ses changements d’état. De plus, il doit y avoir au moins un constructeur capable d’instancier l’entité depuis le début, dans un état valide.

Il n’est pas rare de trouver des implémentations de classes avec des propriétés qui vérifient, par exemple, si la valeur que vous essayez de définir est non nulle, même lorsque ces mêmes propriétés ont null comme valeur par défaut. Quelle est la logique ici ?

Voyez un autre exemple de classe anémique :

public class Customer { public string Name { get; private set; } public string Email { get; private set; } public DateTime BirthDate { get; private set; } public Customer(Guid id, string name, string email, DateTime birthDate) { Id = id; Name = name; Email = email; BirthDate = birthDate; } }

Dans la classe ci-dessus, nous avons un « enregistrement » typique pour une implémentation fonctionnelle. Mais dans un langage orienté objet, ce n’est pas une entité.

L’idée aurait même un sens dans un langage purement fonctionnel où l' »entité » est conceptuellement répartie dans diverses fonctions qui définissent le comportement, mais en C#, cela n’a aucun sens.

Essayons une deuxième version pour la classe Employé:

public class Employee{ public string Id { get; private set; } public string Name { get; private set; } public string Cpf { get; private set; } public decimal Salary { get; private set; } public Employee(string name, string cpf) { //.. } public void RaiseSalary(decimal amount) { //.. }}

Cette fois, l’entité est moins anémique. Après tout, les motivations qui poussent à changer la valeur des propriétés sont évidentes. Remarquez comment même la valeur de l’écriture des tests devient plus explicite.

De toute façon, nous avons encore des problèmes. Nous avons nommé la méthode « RaiseSalary », cependant, ce n’est pas la façon dont les experts du domaine décrivent cette opération. La seule façon de définir les raisons réelles de changer les valeurs des propriétés est de parler avec ces experts.

Pour réfléchir…

Identifier et mettre en œuvre le langage omniprésent ne consiste pas seulement à définir les noms de classe ou les propriétés. Le langage ubiquitaire doit se révéler principalement dans les motivations des changements d’état de nos entités de manière explicite.

Comprendre le langage ubiquitaire est bien plus important que d’apprendre les normes. Sans une réelle connaissance du domaine, la valeur des design patterns est nulle.

S’inquiéter d’abord d’apprendre le plus important. Prenez le temps et l’effort de bien comprendre le domaine et d’expliciter son langage omniprésent. Ensuite, il sera peut-être même judicieux de penser à associer DDD à des concepts techniques plus avancés.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.