Ya no necesitas buscar más por todo internet ya que estás al espacio justo, contamos con la respuesta que deseas y sin liarte.
Solución:
Entidad
Entity significa un objeto que es un elemento único con el que trabaja la lógica empresarial, más específicamente aquellos que tienen algún tipo de identidad.
Por lo tanto, muchas personas se refieren a los objetos mapeados con ORM como entidades.
Algunos se refieren como “entidad” a una clase cuya instancia representa una sola fila en una base de datos.
Algunas otras personas prefieren llamar “entidad” solo a aquellas de estas clases que también contienen reglas comerciales, validación y comportamiento general, y llaman a las otras como “objetos de transferencia de datos“.
Modelo
UN Model es algo que no está directamente relacionado con la interfaz de usuario (=View) y caudal de control (=Controller) de una aplicación, sino más bien de cómo funciona el acceso a los datos y la abstracción de los datos principales de la aplicación.
Básicamente, cualquier cosa puede ser un modelo que se ajuste a lo anterior.
MVC
Puede usar entidades como sus modelos en MVC. Significan dos cosas diferentes, pero las mismas clases pueden llamarse ambas.
Ejemplos
- UN
Customerclass es en gran medida una entidad (generalmente), y también la usa como parte del acceso a datos en su aplicación. Es a la vez una entidad y un modelo en este caso. - UN
RepositoryLa clase puede ser parte del Modelo, pero claramente no es una entidad. - Si hay una clase que usa en medio de su capa de lógica de negocios pero no la expone al resto de la aplicación, puede ser una entidad, pero claramente no es un Modelo desde la perspectiva de la aplicación MVC.
tu ejemplo
En cuanto a sus ejemplos de código, preferiría el primero.
Un modelo es una clase que se utiliza como medio de extracción de datos de una aplicación, no una clase que tiene un nombre con el sufijo “Modelo”. Mucha gente considera este último bloatware.
Prácticamente puede considerar su clase de Repositorio como parte de su modelo, incluso si su nombre no tiene el sufijo “Modelo”.
A eso le agregaría el hecho de que también es más fácil trabajar con el primero, y para otras personas que luego puedan tener que entender tu código, es más fácil de entender.
Todas las respuestas son una gran mezcla de cosas diferentes y simplemente incorrectas.
Un modelo en DDD es muy parecido a un modelo en el mundo real: una simplificación y abstracción de algo. Ni menos ni más. No tiene nada que ver con datos ni objetos ni nada más. Es simplemente el concepto de una parte de dominio. Y también en cada dominio complejo siempre hay más de un modelo, por ejemplo, comercio, facturación, logística.
Una entidad no es un “modelo con identidad” sino simplemente un objeto con identidad.
Un repositorio no es solo un caché de primer nivel, sino también una parte del dominio. Da la ilusión de objetos en memoria y es responsable de obtener agregados (¡no entidades!) de cualquier lugar y guardarlos, es decir, mantener el ciclo de vida de los objetos.
El “modelo” en su aplicación es el bit que contiene sus datos. La “entidad” en el diseño dirigido por el dominio es, si no recuerdo mal, un modelo con identidad. Es decir, una entidad es un modelo que suele corresponder directamente a un elemento “físico” de una base de datos o archivo. Creo que DDD define dos tipos de modelos, uno es la entidad, el otro es el valor, que es solo un modelo sin identidad.
El patrón Repository es solo un tipo de colección indexada de modelos/entidades. Entonces, por ejemplo, si su código quiere el pedido n. ° 13, primero lo solicitará al repositorio, y si no puede obtenerlo desde allí, irá a buscarlo desde cualquier lugar. Básicamente es un caché de nivel 1, por así decirlo. No hay diferencia en cómo actúa con un modelo y cómo actúa con una entidad, pero dado que la idea de un repositorio es poder obtener modelos usando sus ID, en términos de DDD, solo las entidades podrían ingresar al repositorio.
Si tienes alguna sospecha o capacidad de afinar nuestro división puedes dejar una disquisición y con gusto lo ojearemos.