DDD: ¿Pueden los objetos inmutables también ser entidades?

9

He leído innumerables publicaciones sobre diferencias entre entidades y objetos de valor y, aunque creo que al menos conceptualmente entiendo cómo difieren los dos, parece que en algunas de estas publicaciones los autores consideran que un concepto de dominio particular es un VO simplemente porque es inmutable (por lo tanto, su estado nunca cambiará, al menos dentro de ese modelo de dominio particular).

¿Está de acuerdo en que si el estado de un objeto nunca cambiará dentro de un modelo de dominio particular, entonces este objeto nunca debería ser una entidad? ¿Por qué?

domain-driven-design

— bckpwrld
fuente

Tengo que aprender algo de DDD para poder responder algunas de estas preguntas de manera inteligente. Sospecho que la dificultad que muchos desarrolladores de software tienen con conceptos simples como este surge de la noción errónea de que DDD es una metodología de programación.

— Robert Harvey

4

Según el libro (Evans, 2004), "Un objeto definido principalmente por su identidad se llama ENTIDAD". Esta definición es independiente de si el objeto es mutable o inmutable. Creo que es mucho menos probable que un objeto inmutable sea una entidad en un dominio dado, por lo que es una heurística útil para decidir si un objeto es un "objeto de valor" o una "entidad", pero eso no es parte de la definición.

Por ejemplo, supongamos que tiene una entidad que representa a un empleado, que puede o no tener un supervisor directo. Si decide representar la idea de no tener un supervisor directo como referencia a un objeto supervisor "nulo", entonces el objeto supervisor "nulo" se considera razonablemente una entidad. Y probablemente podría hacer que este objeto "nulo" sea inmutable.

— Aidan Cully
fuente

1

+1 El administrador puede ser de solo lectura (inmutable) en un contexto o subdominio particular, pero eso no significa que no tenga identidad.

— Adrian Schneider

Perdóname por ser denso, pero no entiendo completamente tu ejemplo de supervisor. ¿Estás diciendo que en el dominio tendríamos dos conceptos relacionados con el supervisor? Un concepto representaría a los supervisores que tienen empleados que supervisan (en el código este concepto se implementaría como clase de Supervisor mutable) mientras que el otro concepto describiría al supervisor que no supervisa a ningún empleado (y este concepto se implementaría como nulo en el código) ?

— bckpwrld

@bckpwrld No, seguramente se refiere a un objeto nulo .

— maaartinus

2

La forma en que he leído esto es que un objeto de valor es un objeto que no tiene una identidad en sí mismo y que no tiene nada que ver con que su estado cambie o no cambie. Esto hace la diferencia entre una entidad y un objeto de valor que una entidad tiene una clave primaria, mientras que un objeto de valor no; tendrá una clave foránea para la entidad a la que pertenece.

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

Todavía puedo cambiar las propiedades del objeto de valor, pero no es necesario identificarlo independientemente de su entidad.

— Kevin
fuente

Mezclé la terminología de las bases de datos relacionales (clave principal) como identidad como metáfora, por favor no lo tome literalmente

— Kevin

Al menos a mi entender, incluso si en el código los VO están representados con un tipo mutable (por lo tanto, las instancias de este tipo pueden tener sus propiedades modificadas), conceptualmente estos VO aún son inmutables. Por lo tanto, cambiar una propiedad de una instancia que representa un VO particular significa que ahora esta misma instancia representa un VO diferente. En otras palabras, los VO son conceptualmente siempre inmutables

— bckpwrld