DDD

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

Según entiendo, "todas las buenas aplicaciones DDD" debería tener 4 capas: presentación, una aplicación de dominio e Infraestructura. Se debe acceder a la base de datos usando Repositorios. Las interfaces del repositorio deben estar en la implementación del nivel de dominio y del repositorio, en Infraestructura (referencia DDD: Where to keep domain Interfaces, the Infrastructure?).

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

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

¡Gracias de antemano!

Fuente

2009-09-05 Zygimantas

Cumpliendo 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 sola entidad en su dominio. Puede encontrar Servicios en todas las capas, aunque los tipos de problemas que abordan difieren de una capa a otra y pueden ser diferentes del Servicio conceptual de DDD.

Al trabajar en el nivel conceptual, un depósito de DDD difiere de un servicio de DDD en que está específicamente vinculado a la persistencia de la entidad. Un Servicio puede abordar cualquier problema de Dominio, Aplicación o Infraestructura que pueda tener.

Se topa con enfrentamientos de terminología con DDD por todas partes. Por ejemplo, un repositorio DDD NO es lo mismo que el Repository pattern que se encuentra en el libro PoEAA de Martin Fowler, aunque puede emplear dicho patrón. Esto es a menudo una fuente de confusión para muchas personas.

Ayuda con DDD si siempre mantiene el Modelo de dominio en el centro de todo lo que hace. Cuando se trata de capas de aplicaciones DDD, a menudo elijo Jeffrey Palermo's Onion Architecture. Echale un vistazo. Descargue CodeCampServer, una aplicación de ejemplo que usa esta arquitectura. Creo que es una opción perfecta para la programación de DDD.

¡Buena suerte!

Fuente

2009-09-06 15:22:15

Lo desafortunado 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 manejar acciones, operaciones y actividades.

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

Fuente

2009-09-05 19:20:35

Bueno, tal vez malinterpretaste mi pregunta o no entendí la respuesta. Dentro de la capa de infraestructura, si tenemos un servicio que trata con Mail API, lo llamamos "servicio de correo electrónico", pero el código para recuperar datos de la base de datos se denomina "implementación del repositorio". ¿No es el mismo tipo de "servicio de infraestructura"? – Zygimantas

-1

¿Por qué debería poner implementaciones de repositorio en Infraestructura? No están relacionados con 'Infraestructura' en absoluto. Principalmente pongo las interfaces de repositorio en el 'modelo de dominio', y puse la implementación de esos repositorios también en el modelo de dominio.

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

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

Fuente

2009-09-05 21:36:53

Veo repositorios como específicos del dominio, no necesariamente específicos de la aplicación. Mirándolo de esa manera, tiene sentido tener una interfaz de repositorio definida en su capa de Modelo de Dominio. Veo el acceso a los datos como un problema de infraestructura específico del dominio, separado del código de la aplicación.Veo lo que dice sobre las bibliotecas reutilizables, pero las separo en módulos diferentes: uno (o más) módulos reutilizables, que contienen clases como EmailSender y uno (o más) módulos de infraestructura específicos del dominio, que contienen clases tales como CustomerRepository. Diferentes módulos, misma capa. –

De hecho, la implementación del repositorio no debería estar en la aplicación. Debería estar en el modelo de dominio. Sin embargo, la capa de aplicación debe controlar el alcance de la transacción que utiliza un repositorio. –

Creo que un repositorio tradicional debería implementarse fuera del modelo de dominio si alberga la infraestructura real para acceder a los datos. Pero con el concepto NWorkspace de Jimmy Nilsson, creo que los repositorios pueden hacer que la implementación sin infraestructura vuelva a la capa de dominio donde tiene más sentido. – jpierson

Quizás ayude a ver una posible estructura de proyecto.

montaje o paquete posible estructura:

Project.Domain
Project.Infrastructure.Data
Project.Infrastructure.Components
Project.Infrastructure.Services

Posible espacio de nombres o la carpeta estructura:

Project.Domain
Módulos -n-
---- Cuenta n-
------- f- Account.xx
------- f- AccountRepository.xx
----- --f- Contact.xx
---- n- comercialización
------- f- RegionRepository.xx
-n- Compartido
-n- Servicios

Project.Infrastructure .Data (OR-Mapeadores)
-n- Cuadros
-n- Vistas
Procedimientos -n-
Funciones -n-

Project.Infrastructure.Components (genéricos)
-n- correo
Criptografía -n-
IU-n

Project.Infrastructure.Services (Operaciones especiales)
-f- DoingSomethingService1.xx
-f- DoingSo methingService2.xx
-f- DoingSomethingService3.xx

entidades del dominio y tipos de valor no utilizan los servicios de dominio. La capa de aplicación usa los servicios del dominio. Los objetos de Depósito de dominio usan los objetos Infrastructure.Data para devolver objetos de Dominio.

Fuente

2010-05-12 15:24:53

El objetivo de DDD no es tener una cierta estructura de proyecto, sino más bien tener un comportamiento en sus entidades. Cuando dice "hacer copias de sus objetos ORM", parece que está usando un dominio anémico, que en realidad no es DDD en absoluto. El comportamiento (mutaciones de estado de dominio) debe estar dentro de los objetos de dominio, no en los servicios. – Ryan

Por supuesto, Ryan. DDD NO es sobre un cierto tipo de proyecto. Eso es un detalle de implementación. Es por eso que dije que podría ser útil ver una estructura de proyecto. Por "hacer copias", estoy hablando en contexto de atributos, NO el comportamiento. El objeto de dominio se parecerá a un objeto de base de datos, en su mayor parte. Qué significa eso? Significa que los atributos serán similares excepto para las asociaciones Aggreate y Composition. Como eso te confundió, eliminaré ese texto. Si te confundió, estoy seguro de que confundirá a los demás. –

Creo que te refieres a propiedades, no a atributos. No pretendo criticar, solo aclarar. Soy de la escuela de pensamiento de que las propiedades en un objeto de dominio son un antipatrón. Últimamente he estado yendo hacia una ruta cuasi-cqrs: leer solo propiedades en mi dominio y métodos para mutar el estado. Mis puntos de vista son de aproximadamente 50% de lectura de vistas DB desnormalizadas y 50% de proyección fuera del modelo de dominio. El enfoque que elijo depende de la complejidad de los datos. – Ryan

Respuesta

Cuestiones relacionadas