DAO, Repositorios y Servicios en DDD

Después de leer varios artículos, estoy empezando a entender la diferencia entre DAO y Repositorios, pero me encuentro en problemas tratando de entender la diferencia entre Repositorios y Servicios.

Para poner en términos cortos, en el paradigma OO:

  • DAO : Clase que contiene el CRUD operations básico para una clase de entidad. Tiene el código necesario para obtener o recuperar cosas del sistema de almacenamiento persistente subyacente. En términos generales, el los métodos reciben entidades de objeto como parámetros, excepto en el método retrieve donde usar un tipo del Identificador es válido.

  • Repositorios : En un nivel superior de abstracción.. como generalmente he leído es una especie de lugar donde poner código que maneja operaciones sobre objetos agregados (objetos que tienen objetos hijos). Utiliza los DAOs para recuperar objetos de la base de datos, y al final expone una interfaz en el lenguaje "business" del dominio. (Pero de nuevo, creo es muy válido usar tipos de datos de ids). Ejemplo: Un addSomething muy simple donde something es un objeto hijo del padre cuyas instancias, por cierto, son gestionadas como un todo por el Repositorio.

  • Servicios : De nuevo, está en un nivel más alto de abstracción. Para mi humilde punto de vista, son un buen lugar para conectar dos clases que no comparten la relación padre-hijo, sino que están tan lejos (en términos de abstracción) como Repositorio. Ejemplo : El método transferCash entre dos bank accounts.

Entonces, esas son mis lecturas, pero estoy preguntando aquí que los pensamientos anteriores son correctos o no. O cómo debería pensar. O algo que me señale a entender realmente la diferencia de todos estos conceptos.

Algunas de las fuentes :

Author: Community, 2013-11-12
Source

3 answers

Los repositorios son - como usted dice - una abstracción. Se originan a partir del Patrón de consulta de objetos de Martin Fowler. Tanto los repositorios como los DTO pueden simplificar la persistencia de la base de datos al asignar datos persistentes a una colección equivalente de objetos de entidad. Sin embargo, los repositorios son más gruesos que los DAOs, ya que proporcionan el control de toda una Raíz agregada (AG) a menudo ocultando mucho estado interno del cliente. DAO, por otro lado, puede ser tan fino como estar dedicado a un objeto de entidad única. Tanto para Repositorios como para DAOs, es común usar Hibernate u otros Marcos de trabajo de Mapeo de Objetos/Relacionales (Object) en lugar de escribir su propia implementación.

Normalmente, los servicios pueden residir en una Capa de Servicio y pueden actuar tanto como fachada de funcionalidad, capa anticorrupción y coordinador para el almacenamiento en caché y las transacciones. A menudo son un buen lugar para llevar a cabo la tala. Servicios de grano grueso y orientados al uso, por ejemplo, Service.updateCustomerAdress() o Service.sendOrder(). Los repositorios pueden ser demasiado fino para que los clientes lo consuman, p. ej. Customer.add(…), Order.modify(…).

Los repositorios y los DAOs tienen el mismo propósito: conservar los datos de forma permanente. Los servicios, por otro lado, deben ser ignorantes de la persistencia y no tener conocimiento sobre su base de datos. Por lo general, trabajan estrechamente junto con servicios de dominio, repositorios, núcleo de dominio.

 21
Author: Magnus Backeus,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 12:02:44

Los repositorios son interfaces para almacenar y recuperar Raíces agregadas (AR), no Entidades individuales. Tiene un repositorio para cada AR de su Modelo de Dominio.

Según el Patrón de repositorio de Fowler , los repositorios actúan como colección de objetos en memoria y esta es una de las principales diferencias comparándolos con DAOs.

Las interfaces de repositorios son un medio para que el cliente del Modelo de Dominio (y por lo tanto son parte del Modelo de Dominio) comience a trabajar con Modelo de Dominio. Los clientes tienen la intención de obtener una instancia AR de un Repositorio, llamar a algún método en él, que generalmente modifica su estado interno, y luego almacenarlo de nuevo en el Repositorio.

 13
Author: Enrico Sanguin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 12:17:55

No estoy seguro de qué es "DAO". Los repositorios son una abstracción para cargar entidades. Usted debe ser capaz de obtener una entidad y Salvar a uno, eso es todo. Sin preguntas. Si desea consultar algunos datos, escriba una consulta (tal vez incluso dentro de un método de acción MVC, o con la más simple de las abstracciones simples que permiten ejecutar algunos SQL y devolver algunos DTOS que se pueden renderizar directamente en el HTML).

Los servicios, por otro lado, son complicados. Para empezar el plazo es sobrecargado. Los" Servicios de aplicación", tal como se definen en el libro DDD de Eric Evans, existen porque los objetos en el Modelo de Dominio no tienen permitido acceder a problemas de infraestructura como bases de datos, mensajería, almacenamiento en caché, etc. Necesitan que todo eso se haga por ellos y se les entregue en un plato, y los Servicios de aplicaciones hacen precisamente eso. Los Servicios de aplicaciones, por su parte no contienen ninguna lógica. No esperaría ver ICustomerService.ChangeAddress() hacer otra cosa que:

  1. Cargar el Cliente entidad.
  2. Call Customer.ChangeAddress(newAddress)
  3. Guardar el cliente.
  4. Tal vez publicar algunos eventos.

Si tiene un servicio que está cargando a un cliente, configurando su propiedad de dirección y guardándola, entonces ese servicio es en realidad un Script de Transacción y el Cliente es un DTO. Lo que significa que definitivamente tiene una abstracción con fugas y es probable que tenga un modelo de dominio anémico. Los objetos del modelo de dominio no deben tener configuradores públicos, y cuando se combina DDD con CQRS, es posible que su modelo de dominio ni siquiera tenga ningún estado público más allá de los valores principales de ID de entidad.

 2
Author: Neil Barnwell,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-11-14 00:15:58