ego

Un petit ressenti sur le Domain Driven Design après plusieurs années à regarder ce qui se dit...
Bon déjà, le concept j'aime bien et je défends cette idée que partir du modèle du domain est vraiment un point important pour faire de bonne application bien structurée, où on a bien partagé avec le métier et pour laquelle on a réussi à définir le bon niveau de service (api).

Mais alors, dans les discussions on sombre bien trop vite vers de l'implémentation et de la technicité. Et comme bien souvent dans ce genre de mouvement très en lien avec l'Agilité, on part dans des considérations de type management qui nous éloignent du sujet. De plus, sous prétexte de ne pas vouloir standardiser quoi que ce soit dans ce monde de l'agilité, on discute et on évite, par exemple, d'approfondir les sujets avec des notions et surtout concepts issues d'UML, pour ne prendre que cet exemple.

Bon alors qu'est ce que je propose, c'est bien de critiquer mais faut quand même proposer quelque chose......ouhai ça c'est sûr.

Bon déjà, les patterns c'est bien (Entity, aggregate, value object,...) mais revenons vers le métier, tout simplement. Dans un métier donné (un contexte), certains objets sont particuliers dans ce sens que le "client" ou le métier est capable de le connaître à partir d'une référence métier. Il ne s'agit pas de parler d'identité car ce terme est trop ambigue selon moi. Il fait trop référence à l'identité, l'id que l'on a quand on va parler de persistance.
Pour faire simple, un contrat est bien souvent connu à partir de son numéro, idem pour une commande pour laquelle le système créé un numéro de commande unique pour pouvoir suivire la dite commande. Ce numéro n'a rien d'un artifice technique, c'est bien une propriété métier de l'objet dont le format est connu par le client et/ou le métier. Rien à voir avec le "clé primaire" en base de donnée....d'où le fait que je n'aime pas que l'on parle d'identité.

Et donc oui, ces objets avec référence métier sont des Entités. Mais ce n'est pas un pattern magique que l'on applique, c'est juste la réalité, l'objet en question a été modélisé (on a fait une classe) et il a été marqué Entité, mais c'est tout.

Alors ensuite, si cet objet est constitué d'autres parties, notion d'aggrégation ou de composition en UML, alors oui, ses parties ne sont pas des Entités. Encore une fois, pas de pattern appliqué de manière spécifique mais juste de la modélisation standard avec les notions classiques d'UML. Ben ouhai en parlant UML, on n'a pas forcément besoin d'inventer de nouvelles notions...

Ensuite, j'aimerai parler des fameux contextes.
Ces contextes me paraissent un peu fumeux. Je veux dire que si dans un SI on a des contextes différents qui justifient des représentations différentes d'un même concept alors c'est que l'on a des contextes qui ne se parlent pas.
Dans le cas contraire, il me parait nécessaire de plutôt développer des principes d'urbanisation des données, je m'explique.

Dans un SI correctement urbanisé, un concept est sous la responsabilité d'un seul "système". Prenons un exemple simple avec la notion de Personne. Dans le contexte de ce SI, une personne comporte un certain nombre de propriétés dont le système responsable assurera la cohérence. Alors oui, d'autres systèmes dans le SI peuvent avoir besoin de cette personne et cet autre système pourra être tenté de dire, oui mais moi j'appelle le concept Personne plutôt avec le terme Titulaire car je gère des contrats pour lesquels la personne est titulaire.
Ok, ok, mais dans une approche "Urbanisation de données", il est préférable d'utiliser le notion de Rôle. C'est à dire que dans le système de gestion des contrats, on aura, non pas le concept Personne renommé en Titulaire, mais clairement la classe Titulaire en relation avec la class Personne. Cette dernière, sera "importée" depuis le système responsable de la Personne. Et la classe Titulaire pourra comporter les propriétés que la personne a lorsqu'elle joue le rôle de titulaire.

Avec cette approche globale, il n'y a pas vraiment de contexte mais simplement des responsabilités clairements définies au niveau du SI et des usages de concepts entre systèmes/application avec utilisation du principe de Rôle dès lors que le concept réutilisé a "besoin" d'être renommé, besoin entre guillements car vous l'avez compris, avec le pattern Rôle, il s'agit non pas d'appliquer un pattern technique mais bien de représenter la réalité, dans notre exemple une Personne existe bien en tant que telle mais joue parfois des rôles particuliers. Ce concept de rôle est facile à comprendre avec la notion de personne mais à l'usage, vous verrez qu'il s'applique à d'autres situtations. Et d'ailleurs, vous verrez que trouver un nom pour le rôle joué par le concept vous oblige à préciser le métier et donc à questionner vos collègues du métier afin qu'ils soient le plus précis possible (ex: un outil utilisé par qqun devient outil et usage, Personne qui dirige un projet devient Personne et Chef de projet, produit acheté au sein d'une commande devient Produit et Ligne de commande,...


Pour terminer mon petit billet, je dirai que le DDD c'est bien mais je préfère le GDD, Global Domain Design.

Bon si cela vous fait réagir, je peux développez un peu plus....