Voir le flux RSS

ego

DDD j'aime..........ou pas

Noter ce billet
par
ego
, 22/12/2014 à 17h46 (933 Affichages)
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....

Envoyer le billet « DDD j'aime..........ou pas » dans le blog Viadeo Envoyer le billet « DDD j'aime..........ou pas » dans le blog Twitter Envoyer le billet « DDD j'aime..........ou pas » dans le blog Google Envoyer le billet « DDD j'aime..........ou pas » dans le blog Facebook Envoyer le billet « DDD j'aime..........ou pas » dans le blog Digg Envoyer le billet « DDD j'aime..........ou pas » dans le blog Delicious Envoyer le billet « DDD j'aime..........ou pas » dans le blog MySpace Envoyer le billet « DDD j'aime..........ou pas » dans le blog Yahoo

Commentaires

  1. Avatar de Luckyluke34
    • |
    • permalink
    Hello,

    Je ne sais pas si tu as lu le bouquin Domain Driven Design ou sa version Quickly, mais je ne reconnais pas trop DDD dans la description que tu en fais. J'ai l'impression que c'est plus une pratique superficielle de DDD ou des stéréotypes qui ont été déformés au fil des conversations.

    La notion d'identité n'est justement pas liée à un identifiant en base, c'est juste une donnée qui permet de suivre une entité pendant le cours de sa vie et de la retrouver. Ca peut être n'importe quoi - simple entier, email, plaque d'immatriculation, n° INSEE, séquence ADN, etc. Il faut l'entendre au sens "identification", "identitaire", "identique" (qu'est-ce qui fait que deux choses sont les mêmes ou différentes), ce n'est pas forcément un ID. Et le terme "numéro" ne me parait pas satisfaisant dans tous les cas non plus.

    UML permet d'exprimer des modèles, pour communiquer entre développeurs et/ou analystes, concevoir, éventuellement générer du code ou de la documentation. UML est 100% compatible avec DDD, d'ailleurs dans le bouquin, Eric Evans indique que le support du modèle du domaine importe peu, ça peut être une illustration dessinée sur un bout de nappe et être tout aussi efficace. Du coup, j'ai du mal à voir ce que représente la "modélisation standard avec les notions classiques d'UML", puisqu'UML est juste un outil, un langage dont on peut se servir de 1000 manières...

    La notion de Rôle en urbanisation est intéressante. Je pense qu'on n'est pas si éloigné de DDD, l'équivalent d'un Système étant un Contexte. Une différence majeure avec ce que tu décris cependant : en DDD, 2 contextes utilisent souvent les mêmes noms de classes, ils permettent de mieux gérer la polysémie de certains termes fonctionnels - c'est à dire précisément lorsque deux experts métier utilisent le même mot pour désigner deux réalités différentes. Un Produit dans le contexte Catalogue et un Produit dans le contexte Approvisionnement sont deux choses séparées, pourtant, difficile de les appeler autrement.
  2. Avatar de ego
    • |
    • permalink
    Je suis d'accord sur la notion d'identité qui n'est pas un id "base de données". Je n'aime pas l'usage de ce terme identité car ça peut vite être un ID technique mais ok, ce n'est pas ce qui est dit à la base dans DDD.
    Personnellement, pour ne pas qu'il y ait d'ambiguité, je préfére parler de "référence métier". Car cela permet de montrer que cette "référence métier" n'est pas un artifice technique mais bien une propriété qui existe d'un point de vue métier mais qui a une valeur particulière.

    Pour l'histoire d'UML, ce qui me gène dans les discours classiques c'est qu'on le voit trop comme un simple langage. Alors oui c'est un langage et que l'on peut l'utiliser de manières différentes mais il y a quand même des éléments sémantiques forts (généralisation, agrégation, composition). Donc quand on parle de modélisation, il me semble que l'on aurait intérêt à s'appuyer sur ces éléments sémantiques pour illustrer ce que l'on veut dire.

    Pour revenir sur la notion de Contexte, effectivement, on peut avoir 2 contextes qui utilisent le même mot pour des concepts différents. Si ces 2 contextes "ne se parlent pas" ce n'est pas grave. Par contre s'ils se parlent, là c'est grave. Et je ne suis pas d'avis de systèmatiquement conserver le même terme.
    Pour te donner un exemple réel dans le SI de ma boite. Dans un contexte de gestion des clients, on a le concept de prospect et de client. Dans un contexte de type contractualisation, on a le concept de client du contrat aussi.
    Au départ ça peut rester comme cela en disant que l'on a 2 contextes et donc on a le droit d'avoir le même terme "client". Ben en fait ce n'est pas sémantiquement juste, même si dans le langage courant les gens du métier peuvent être aménés à parler comme cela.
    Dans la réalité on a maintenant, après réflexion, la notion de Personne, la notion de Client, la notion de Prospect et la notion de Titulaire. Un même objet Personne est dans le premier contexte un "Client" et dans le second un "Titulaire".
    Un Client est une Personne et un Titulaire est une Personne. Pas d'héritage ici mais une relation d'association de type "Rôle" (ça c'est une concept "à nous", pas UML) entre Personne et Client et entre Personne et Titulaire. Les classes Client et Titulaire sont des rôles (Classes stéréotypées "Rôle") joués par la classe "Personne".

    Bref, ce que je veux dire c'est qu'il est important de creuser la sémantique quand on fait de la modélisation et ne pas s'arrêter à "j'ai 2 contextes" donc je peux garde le même mot pour 2 concepts différents. Surtout que quand on a ce cas de figure, il est possible (probable ?) que l'un des concept soit un rôle joué par l'autre.......et la recherche du terme adéquate pour ce rôle peut être bénéfique à la compréhension du métier.