Différence entre objet de valeur et de l'entité est, que vous ne se soucient pas de l'identité des objets de valeur. Cela n'a pas vraiment d'importance si vous opérez sur un objet de valeur ou un autre, parce que, bien ... leur but entier de l'existence ne vous sert que de valeur. L'entité est cependant distinguée entre les autres entités et il importe de savoir si vous faites référence à l'un ou l'autre, même si les propriétés ont les mêmes valeurs.
Par exemple, vous pourriez avoir suivant objet de valeur
PersonalData
{
string Firstname;
string Lastname;
}
et entité comme celui-ci
Person
{
PersonalData personData;
}
Peu importe si vous utilisez une instance d'objet de valeur ou l'autre puisque tout ce que vous se soucient de la valeur elle-même. D'un autre côté, vous vous souciez de la personne sur laquelle vous opérez. Même si deux objets ont les mêmes valeurs Firstname et Lastname, ils peuvent être des entités complètement différentes! Donc, en répondant à votre question - il n'y a pas de raison que l'objet de valeur soit une racine agrégée puisque les agrégats sont distingués entre eux par un ID unique et que l'objet de valeur ne se soucie pas du tout d'identité. S'il vous plaît gardez à l'esprit que je ne parle pas d'ID technique (utilisé par exemple pour stocker l'objet de valeur dans un magasin de persistance), mais à propos de certains ID de domaine. En ce qui concerne votre deuxième question, fournir de tels objets de valeur vous aide à suivre plus étroitement les histoires de vos experts de domaine dans votre code, car il (elle) ne dirait pas obtenir le client par son ID qui est une chaîne, mais la plupart probablement dire quelque chose comme obtenir le client par id du client. Tout le but de DDD est que votre code soit une représentation proche du domaine qu'il supporte.
Non, un AggregateRoot ne peut pas être un VO puisque, par définition, un AR est une entité et les deux concepts s'excluent mutuellement. Cependant, une copie de l'état d'un AR peut être considérée comme une valeur même si elle porte l'identité de l'AR. – plalx
Si vous essayez de conserver la copie (en BC 2) d'un AR vivant en BC 1 synchronisé mais que vous ne voulez pas modéliser le processus de synchronisation en tant que partie du modèle, la copie peut être considérée comme un AR immuable la perspective du domaine BC 2, mais c'est toujours une entité car la copie est recherchée par identité pour être synchronisée. – plalx