Servicios y repositorios en DDD (C#)

Question

¿Cómo se relacionan Services y Repositories entre sí en DDD? Quiero decir, he estado leyendo sobre DDD durante los últimos 2 días y en todos lados, siempre hay una capa Service y siempre hay una capa Repository. ¿Cómo se diferencian o se complementan?

Por lo que he leído, ¿no es Repository la capa responsable de delegar las interacciones entre la aplicación y los datos?

Así que, ¿cuál es la necesidad de que la capa Service si se tiene que poner en práctica el Repository para interactuar con los datos de todos modos a pesar de que la Repository probablemente ya implementa los métodos necesarios para hacerlo?

Agradeceré algunas aclaraciones sobre el tema.

P.S. No sé si esto ayudará, pero estoy trabajando con una aplicación ASP.NET MVC 2 en la que estoy tratando de implementar el patrón Repositorio. Acabo de terminar la ejecución del patrón de inyección de dependencia (por primera vez en la historia) ...

ACTUALIZACIÓN

bien, con tantas respuestas, creo que entiendo cuál es la diferencia. Por lo tanto, para revisar (corríjanme si me equivoco):

• Una capa Repository interactúa sólo con un único objeto fuera de la base de datos o el ORM, IEmployeeRepository ->Employee.

• A Service capa encapsula la funcionalidad más compleja en los objetos devueltos desde Repositories, ya sea uno o varios.

Entonces, entonces tengo una pregunta secundaria. ¿Se considera una mala práctica crear objetos abstractos para enviar a mis puntos de vista? Por ejemplo, un AEmployee (A para abstract porque para mí I significa interface) que contiene propiedades de Employee y X o X?

En realidad, una sub-demanda más. Si una capa Service se puede considerar "sintonizada" para una aplicación, ¿necesita implementarse con una interfaz?

Answer 1

Es cierto que un repositorio funciona con datos (es decir, SQL, servicio web, etc.) pero ese es el único trabajo. Operaciones CRUD, nada más. No hay lugar para la lógica de busines basada en procedimientos almacenados.

El servicio (o capa de lógica de negocios) proporciona la funcionalidad. Cómo para completar una solicitud de negocio (es decir.calcular el salario), qué tienes que hacer.

Ah, y este es un muy buen libro DDD: http://www.infoq.com/minibooks/domain-driven-design-quickly

Answer 2

Por lo que recuerdo, el repositorio es la clase final antes de los datos. La clase de servicio puede actuar sobre los datos recuperados del repositorio. El repositorio realmente solo tiene la intención de obtener datos para que otra persona haga el trabajo. La capa de servicio puede proporcionar elementos tales como la lógica comercial por la que deben pasar todos los datos. También podría proporcionar una traducción entre la lógica de la aplicación y la capa de datos. Pero, nuevamente, esto es solo lo que puedo recordar.

Answer 3

no hay un estándar de oro que define un servicio o un repositorio. En mis aplicaciones, un repositorio es (como usted dice) una interfaz en una base de datos. Un servicio tiene acceso completo a un repositorio, pero el servicio expone un subconjunto de funcionalidades a sus consumidores.

Piense en el repositorio como de un nivel más bajo. El repositorio debe exponer muchas formas de acceder a la base de datos subyacente. Un servicio puede combinar llamadas a un repositorio con otro código que solo tiene sentido a nivel de código (es decir, no en la base de datos), como el acceso a otro estado en la aplicación o validación/lógica comercial que no se puede aplicar fácilmente en una base de datos

Answer 4

El Servicio utilizará un Repositorio para recuperar una Entidad y luego invocará métodos en ella (la Entidad) para realizar el Comando/tarea.

Answer 5

Como ejemplo concreto una aplicación de Compras podría tener los siguientes servicios:

ShoppingCartService - maneja un carro de artículos con añadir/quitar la actualización de soporte/etc

OrderService - tomar una carro, lo convierte en un pedido y maneja el proceso de pago, etc.

cada uno de estos servicios necesita hablar una "fuente de datos" para las operaciones CRUD. Aquí es donde el patrón Repository es útil ya que abstrae la carga y el guardado de datos hacia y desde la fuente de datos, ya sea una base de datos, un servicio web o incluso un caché en memoria.

Cuando desee crear un prototipo rápido de su aplicación sin tener que ocuparse de la configuración de la base de datos, el esquema, los procedimientos almacenados, los permisos, etc., puede crear una memoria caché o repositorio falso en cuestión de minutos.

Para el ejemplo anterior de su prototipo podría comenzar con lo siguiente:

• FakeCustomerRepository
• FakeAddressRepository
• FakeCartRepository
• FakeCartLineItemRepository
• FakeOrderRepository
• FakeOrderLineItemRepository

una vez que su prototipo está listo para evolucionar al siguiente nivel se puede poner en práctica estas en contra de una base de datos real:

• SQLCustomerRepository
• SQLAddressRepository
• SQLCartRepository
• SQLCartLineItemRepository
• SQLOrderRepository
• SQLOrderLineItemRepository