ejemplo ddd capas arquitectura c# asp.net-mvc domain-driven-design

c# - capas - Servicios de infraestructura DDD



arquitectura n capas ddd (4)

Estoy aprendiendo DDD y estoy un poco perdido en la capa de Infraestructura:

Como entiendo, "todas las buenas aplicaciones DDD" deben tener 4 capas: Presentación, Aplicación, Dominio e Infraestructura. Se debe acceder a la base de datos utilizando repositorios. Las interfaces del repositorio deben estar en la capa de dominio y la implementación del repositorio, en la infraestructura ( DDD de referencia : ¿Dónde se guardan las interfaces del dominio, la infraestructura? ).

La capa de aplicación, dominio e infraestructura debe / puede tener servicios (consulte www.lostechies.com/blogs/jimmy_bogard/archive/2008/08/21/services-in-domain-driven-design.aspx), en el ejemplo EmailService en la capa de infraestructura que envía mensajes de correo electrónico.

PERO, dentro de la capa de infraestructura tenemos implementaciones de repositorio, que se utilizan para acceder a la base de datos. Entonces, en este caso, ¿los repositorios son servicios de base de datos? ¿Cuál es la diferencia entre el servicio de infraestructura y el repositorio?

¡Gracias por adelantado!


¿Por qué pondría implementaciones de repositorio en Infraestructura? No están relacionados con ''Infraestructura'' en absoluto imho.

Según el Libro azul de Evan , los repositorios son parte del modelo de dominio. Por lo tanto, puse la interfaz del repositorio dentro del modelo de dominio. La implementación del repositorio a veces también.

La infraestructura debe contener un código de ''infraestructura'', que podría ser un servicio que le permita enviar fácilmente correo electrónico a través de smtp, o código que le resulte un acceso a la base de datos (por lo tanto, algunas clases que podría usar en su repositorio, pero su repositorio).

Por lo tanto, no coloque sus repositorios en ''infraestructura'', ya que no pertenecen a ellos. Para mí, las clases que se pueden encontrar en infraestructura, son clases que puedes usar en otros proyectos, ¿entiendes? Las clases que no están estrechamente relacionadas con su modelo de dominio o aplicación pertenecen a Infraestructura. Y una implementación de repositorio está bastante estrechamente unida a una aplicación específica. :)


Siguiendo con las definiciones de DDD, un Repositorio es diferente de un Servicio. Un repositorio se correlaciona directamente con una entidad, a menudo una raíz agregada. Un Servicio define comportamientos que realmente no pertenecen a una única Entidad en su dominio. Absolutamente puede encontrar Servicios en cada capa, aunque los tipos de problemas que abordan difieren de una capa a otra y pueden ser diferentes del Servicio conceptual de DDD.

Cuando se trabaja a nivel conceptual, un repositorio de DDD se diferencia de un servicio de DDD en que está específicamente vinculado a la persistencia de la entidad. Un servicio puede solucionar cualquier problema de dominio, aplicación o infraestructura que pueda tener.

Se encuentra con conflictos de terminología con DDD en todo el lugar. Por ejemplo, un Repositorio DDD NO es lo mismo que el patrón Repositorio que se encuentra en el libro PoEAA de Martin Fowler, aunque puede emplear ese patrón. Esto es a menudo una fuente de confusión para muchas personas.

Ayuda con DDD si siempre mantienes el Modelo de Dominio en el centro de todo lo que haces. Cuando se trata de crear aplicaciones DDD, a menudo elijo la arquitectura de cebolla de Jeffrey Palermo . Echale un vistazo. Descarga CodeCampServer , una aplicación de ejemplo que utiliza esta arquitectura. Creo que es un ajuste perfecto para la programación DDD.

¡Buena suerte!


Tal vez ayude a ver una estructura de proyecto potencial.

Posible montaje o estructura del paquete:

Proyecto.Dominio
Proyecto.Infraestructura.Datos
Proyecto.Infraestructura.Componentes
Proyecto.Infraestructura.Servicios

Posible espacio de nombres o estructura de carpetas:

Proyecto.Dominio
-n- Módulos
---- n- Cuenta
------- f- Cuenta.xx
------- f- AccountRepository.xx
------- f- Contacto.xx
---- n- Marketing
------- f- RegionRepository.xx
-n- Compartido
-n- Servicios

Project.Infrastructure.Data (OR-Mappers)
-n- Tablas
-n- Vistas
-n- Procedimientos
-n- Funciones

Project.Infrastructure.Components (Genérico)
-n- Correo
-n- Criptografía
-n- UI

Project.Infrastructure.Services (Operaciones Especiales)
-f- DoingSomethingService1.xx
-f- HaciendoAlgoServicio2.xx
-f- HaciendoAlgoServicio3.xx

Las entidades de dominio y los tipos de valor no utilizan los servicios de dominio. La capa de aplicación utiliza los servicios del dominio. Los objetos del repositorio de dominios usan los objetos Infrastructure.Data para devolver objetos de dominio.


Una cosa desafortunada acerca de DDD es la palabra ''Servicio''. Lo que debería ser es ''Servicio de dominio''. Piense en el Dominio como entidades y objetos de valor, mientras que los Servicios son una forma de tratar con acciones, operaciones y actividades.

En cuanto a los Repositorios, son solo una fachada que debería comportarse como una colección para su dominio. Si está utilizando un ORM o está escribiendo el suyo propio, esto es lo que todos los objetos de su dominio deberían atravesar para lograr la persistencia en lugar de esos servicios directamente.