c# - microservicios - domain entity

Servicios y Repositorios en DDD(C#) (5)

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

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

Entonces, ¿cuál es la necesidad de la capa de Service si tiene que implementar el Repository para interactuar con los datos de todos modos, aunque probablemente el Repository ya implementa los métodos necesarios para hacerlo?

Apreciaría un poco de iluminación sobre el tema.

PS 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 Repository. Acabo de terminar de implementar el patrón de inyección de dependencia (por primera vez) ...

ACTUALIZAR

De acuerdo, con tantas respuestas, creo que entiendo cuál es la diferencia. Entonces, para revisar (corríjame si me equivoco):

Una capa de Repository interactúa solo con un solo objeto fuera de la base de datos o el ORM, IEmployeeRepository -> Employee .
Una capa de Service encapsula una funcionalidad más compleja en los objetos devueltos desde los Repositories , ya sea uno o varios.

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

En realidad, una subpregunta más. Si una capa de Service puede considerarse "ajustada" para una aplicación, ¿debe implementarse con una interfaz?

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

ShoppingCartService : administra un carro de artículos con soporte para agregar / eliminar / actualizar, etc.

OrderService : tome un carrito, lo convierte en un pedido y se encarga del proceso de pago, etc.

cada uno de estos servicios necesita hablar de una "fuente de datos" para las operaciones de CRUD. Aquí es donde el patrón de Repository es útil ya que resume la carga y el almacenamiento 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 lidiar con la configuración de la base de datos, el esquema, los procedimientos almacenados, los permisos, etc., puede crear una memoria caché o un repositorio falso en cuestión de minutos.

Para el ejemplo anterior, 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, puede implementar esto en una base de datos real:

SQLCustomerRepository
SQLAddressRepository
SQLCartRepository
SQLCartLineItemRepository
SQLOrderRepository
SQLOrderLineItemRepository

De lo que puedo recordar, el repositorio es la clase final antes de los datos. La clase de servicio puede actuar sobre los datos recuperados del repositorio. El repositorio está realmente destinado a obtener datos para que otra persona haga el trabajo. La capa de servicio puede proporcionar cosas como la lógica de negocios que todos los datos deben pasar. También podría proporcionar una traducción entre la lógica de la aplicación y la capa de datos. Pero una vez más, esto es justo lo que puedo recordar.

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

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

El servicio (o capa lógica empresarial) proporciona la funcionalidad. Cómo completar una solicitud comercial (es decir, calcular el salario), lo que tiene que hacer.

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

No hay un estándar de oro que defina 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 funcionalidad a sus consumidores.

Piense en el repositorio como un nivel más bajo. El repositorio debe exponer muchas formas de acceder a la base de datos subyacente. Un servicio puede combinar las llamadas a un repositorio con otro código que solo tenga 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 la lógica de validación / negocio que no se puede aplicar fácilmente en una base de datos