Objets de valeur et objets d'entité (Domain Driven Design)

Question

Je viens de commencer à lire DDD. Je ne parviens pas à saisir complètement le concept d'entité par rapport aux objets de valeur. Quelqu'un peut-il m'expliquer les problèmes (maintenabilité, performance, etc.) auxquels un système peut être confronté lorsqu'un objet de valeur est conçu comme un objet d'entité ? Un exemple serait bien...

Answer 1

Réduite à la distinction essentielle, l'identité compte pour les entités, mais pas pour les objets de valeur. Par exemple, le nom d'une personne est un objet de valeur. Une entité Client pourrait être composée d'un Nom de client (objet de valeur), d'une Liste<Order> OrderHistory (Liste d'entités), et peut-être d'une Adresse par défaut (typiquement un objet de valeur). L'entité Customer aurait un ID, et chaque commande aurait un ID, mais un Name ne devrait pas ; en général, dans le modèle objet de toute façon, l'identité d'une Address n'a probablement pas d'importance.

Les objets de valeur peuvent généralement être représentés comme des objets immuables ; la modification d'une propriété d'un objet de valeur détruit essentiellement l'ancien objet et en crée un nouveau, car l'identité n'est pas aussi importante que le contenu. La méthode d'instance Equals sur Name renvoie "true" tant que les propriétés de l'objet sont identiques à celles d'une autre instance.

Cependant, la modification d'un attribut d'une entité comme le client ne détruit pas le client ; une entité client est généralement mutable. L'identité reste la même (au moins une fois que l'objet a été persisté).

Vous créez probablement des objets de valeur sans vous en rendre compte ; chaque fois que vous représentez un aspect d'une entité en créant une classe à grain fin, vous avez un objet de valeur. Par exemple, une classe IPAddress, qui a certaines contraintes sur les valeurs valides mais qui est composée de types de données plus simples, serait un objet de valeur. Une EmailAddress pourrait être une chaîne de caractères, ou un objet de valeur avec son propre ensemble de comportements.

Il est tout à fait possible que même les éléments qui ont une identité dans votre base de données n'aient pas d'identité dans votre modèle d'objet. Mais le cas le plus simple est un composite de quelques attributs qui ont un sens ensemble. Vous n'avez probablement pas envie d'avoir Customer.FirstName, Customer.LastName, Customer.MiddleInitial et Customer.Title alors que vous pouvez les composer ensemble en tant que Customer.Name ; ils seront probablement des champs multiples dans votre base de données au moment où vous penserez à la persistance, mais votre modèle objet s'en moque.

Answer 2

Tout objet qui est défini collectivement par l'ensemble de ses attributs est un objet de valeur. Si l'un des attributs change, on obtient une nouvelle instance d'un objet valeur. C'est pourquoi les objets de valeur sont définis comme immuables.

Si l'objet n'est pas entièrement défini par tous ses attributs, il existe un sous-ensemble d'attributs qui constituent l'identité de l'objet. Les autres attributs peuvent changer sans redéfinir l'objet. Ce type d'objet ne peut pas être défini comme immuable.

Une façon plus simple de faire la distinction est de considérer les objets de valeur comme des données statiques qui ne changeront jamais et les entités comme des données qui évoluent dans votre application.

Answer 3

Types de valeurs :

• Les types de valeurs n'existent pas par eux-mêmes, ils dépendent des types d'entités.
• L'objet Value Type appartient à un objet Entity Type.
• La durée de vie d'une instance de type valeur est limitée par la durée de vie de l'instance d'entité propriétaire.
• Trois types de valeurs : Basic (types de données primitives), Composite (adresse) et Collection (carte, liste, tableaux).

Entités :

• Les types d'entités peuvent exister par elles-mêmes (Identité).
• Une entité a son propre cycle de vie. Elle peut exister indépendamment de toute autre entité.
• Par exemple : Personne, Organisation, Collège, Mobile, Maison, etc. chaque objet a sa propre identité.

Answer 4

Je ne sais pas si ce qui suit est correct, mais je dirais que dans le cas d'un objet Adresse, nous voulons l'utiliser comme un Value Object au lieu d'une Entité parce que les changements apportés à l'entité seraient reflétés sur tous les objets liés (une Personne par exemple).

Prenez ce cas : Vous vivez dans votre maison avec d'autres personnes. Si nous utilisions Entity pour l'adresse, je dirais qu'il y aurait une adresse unique à laquelle tous les objets Person seraient liés. Si une personne déménage, vous voulez mettre à jour son adresse. Si vous mettez à jour les propriétés de l'entité Address, toutes les personnes auront une adresse différente. Dans le cas d'un Value Object, nous ne pourrions pas modifier l'adresse (puisqu'elle est immuable) et nous serions obligés de fournir une nouvelle adresse pour cette personne.

Cela vous semble-t-il correct ? Je dois dire que j'étais/je suis toujours aussi confus à propos de cette différence, après avoir lu le livre DDD.

Pour aller plus loin, comment cela serait-il modélisé dans la base de données ? Toutes les propriétés de l'objet Adresse seraient-elles des colonnes de la table Personne ou bien créeriez-vous une table Adresse distincte qui aurait également un identifiant unique ? Dans ce dernier cas, les personnes vivant dans la même maison auraient chacune une instance différente d'un objet Adresse, mais ces objets seraient identiques à l'exception de leur propriété ID.

Answer 5

L'adresse peut être une entité ou un objet de valeur qui dépend du processus de l'entreprise. l'objet adresse peut être une entité dans une application de service de messagerie mais l'adresse peut être un objet de valeur dans une autre application. dans l'application de messagerie, l'identité compte pour l'objet adresse.