DDD: Les objets immuables peuvent-ils également être des entités?

9

J'ai lu d'innombrables articles sur les différences entre les objets Entités et Valeur et bien que je pense qu'au moins conceptuellement, je comprends comment les deux diffèrent, il semble que dans certains de ces articles, les auteurs considèrent qu'un concept de domaine particulier est une VO simplement parce qu'il est immuable (ainsi son état ne changera jamais, au moins dans ce modèle de domaine particulier).

Êtes-vous d'accord que si l'état d'un objet ne changera jamais dans un modèle de domaine particulier, cet objet ne devrait jamais être une entité? Pourquoi?

domain-driven-design

— bckpwrld
source

Je dois apprendre un DDD pour pouvoir répondre intelligemment à certaines de ces questions. Je soupçonne que la difficulté que de nombreux développeurs de logiciels rencontrent avec des concepts simples comme celui-ci provient de la notion erronée que DDD est une méthodologie de programmation.

— Robert Harvey

4

D'après le livre (Evans, 2004), "Un objet défini principalement par son identité est appelé une ENTITÉ". Cette définition est indépendante du fait que l'objet soit mutable ou immuable. Je pense qu'il est beaucoup moins probable qu'un objet immuable soit une entité dans un domaine donné, c'est donc une heuristique utile pour décider si un objet est un "objet de valeur" ou une "entité", mais cela ne fait pas partie de la définition.

Par exemple, supposons que vous ayez une entité représentant un employé, qui peut ou non avoir un superviseur direct. Si vous décidez de représenter l'idée de ne pas avoir de superviseur direct comme référence à un objet superviseur "nul", alors l'objet superviseur "nul" est raisonnablement considéré comme une entité. Et vous pourriez probablement rendre cet objet "nul" immuable.

— Aidan Cully
source

1

+1 Le gestionnaire peut être en lecture seule (immuable) dans un contexte ou un sous-domaine particulier, mais cela ne signifie pas qu'il n'a pas d'identité.

— Adrian Schneider

Pardonnez-moi d'être dense, mais je ne comprends pas complètement l'exemple de votre superviseur. Êtes-vous en train de dire que dans le domaine, nous aurions deux concepts liés au superviseur? Un concept représenterait des superviseurs qui ont des employés qu'ils supervisent (dans le code, ce concept serait implémenté en tant que classe de superviseur mutable) tandis que l'autre concept décrirait un superviseur qui ne supervise aucun employé (et ce concept serait implémenté comme nul dans le code) ?

— bckpwrld

@bckpwrld Non, il signifie sûrement un objet nul .

— maaartinus

2

La façon dont j'ai lu ceci est qu'un objet de valeur est un objet qui n'a pas d'identité en soi et qui n'a rien à voir avec son état changeant ou non. Cela fait la différence entre une entité et un objet valeur qu'une entité possède une clé primaire, contrairement à un objet valeur; il aura une clé étrangère pour l'entité à laquelle il appartient.

http://lostechies.com/joeocampo/2007/04/23/a-discussion-on-domain-driven-design-value-objects/

Je peux toujours changer les propriétés de l'objet de valeur, mais il n'a pas besoin d'être identifié indépendamment de son entité.

— Kevin
source

J'ai mélangé la terminologie des bases de données relationnelles (clé primaire) comme identité comme métaphore, s'il vous plaît ne le prenez pas au pied de la lettre

— Kevin

À ma connaissance au moins, même si dans le code les VO sont représentés avec un type mutable (ainsi les instances de ce type peuvent voir leurs propriétés modifiées), conceptuellement ces VO sont toujours immuables. Ainsi, la modification d'une propriété d'une instance représentant une VO particulière signifie que cette même instance représente désormais une VO différente. En d'autres termes, les VO sont conceptuellement toujours immuables

— bckpwrld