Que no Neo; que no hay cuchara.

En DDD las entidades no existen. ¡BUM! Toma locura gorda; contradiciendo todos los textos existentes sobre el tema... o no ;-)

Ahora que tengo tu atención y antes de que escribas una diatriba pedante en los comentarios; poniéndome a caer de un burro; voy a extenderme para dar una explicación lógica a esto.

A lo que me refiero arriba es que en DDD; con un acercamiento y enfoque más moderno que los textos (con todos mis respetos; no les quito el gran merito que les merece; pero están anticuados y anclados a una visión OOP que genera una gran cantidad de artefactos indeseados) de Eric Evans, Vaughn Vernon y Martin Fowler; las entidades no se deben modelar como elementos reutilizables, representando la vida real, con los que trabajar por parte de los agregados y la capa de servicio de aplicación.

Probemos con una entidad Customer creada para ser reutilizada por todo el sistema. Pronto nos daremos cuenta que esta entidad esta incluyendo información y métodos para el sistema de ventas, de marketing, de facturación, de reviews, etc. Feo, no nos vale.

Pasamos a crear una entidad Customer por cada Bounded Context (BC). También, muy pronto, nos encontraremos que para ciertas operaciones, aunque sean del mismo BC, no necesitamos ni la mitad de la información que contiene el Customer. Feo, no nos vale tampoco.

¿Que hacemos entonces?

Cada agregado debe tener la información del Customer justa y necesaria para aplicar las reglas de dominio e invariantes. Aquí, Customer como entidad no tiene por qué ser una plantilla de datos (ni clase, ni estructura, ni nada); eso son detalles de implementación; aquí, cada Customer de cada agregado es una entidad como Rol asignado; un rol conocido por el agregado, que sabe que si la acción que realiza resulta en un cambio de un atributo del Customer, entonces como información a persistir debe retornar el nuevo valor del atributo y el Identificador único del Customer.

Las entidades son elementos internos a cada agregado. No existen fuera del agregado. No son una plantilla de datos para usar en la capa de aplicación. No son elementos referenciables desde ningún sitio fuera de su propio agregado y son únicas (ver más abajo) para cada agregado.

Obviamente se terminaran teniendo agregados que con la misma información puedan aplicar varias acciones o estructura de datos que representen parte del Customer que pueden ser comunes para varios agregados; por lo que al final terminaremos creando plantillas que representan a una entidad Customer para ciertas acciones del dominio; pero estas no se utilizarán más que para que el agregado cree/obtenga una referencia a ella e internamente trabaje con ella; y tendremos varias. Esta es la parte de los detalles de la implementación que requiere un buen diseño OOP y buenas prácticas SOLID.

Para el diseño del sistema utilizando DDD (detalles de implementación aparte) lo importante es darse cuenta de que las entidades, como elemento de representación de un concepto de la vida real para todo el sistema (o BC), no existen.