Preguntas relacionadas con el diseño impulsado por el dominio

Question

Después de leer el diseño impulsado por el dominio de Eric Evans, tengo algunas preguntas. Busqué pero no pude encontrar respuestas satisfactorias. Por favor, avíseme si alguno de ustedes tiene una comprensión clara debajo de las preguntas.

Mis preocupaciones son

1. repositorio es para obtener agregados ya existentes de DB, el servicio Web. Si es así, puede tener también repositorio transacción pide a esta entidad (es decir, la cantidad de transferencia, enviar detalles de la cuenta ... etc)

2. Puede Entidad tienen métodos que tienen la lógica de negocio en el que se llama servicios de capa de infraestructura para el envío de mensajes de correo electrónico. .registros, etc. (métodos de entidad que llaman directamente a los servicios IS).

3. La implementación del repositorio y las clases de fábrica residirán en la capa de infraestructura. ¿Es esa declaración correcta?

4. ¿Puede la capa de la interfaz de usuario (controladora) llamar a los métodos Repositry directamente? o deberíamos llamarlos desde la capa de Aplicación?

Todavía hay muchos porción confusión en mi mente ... por favor me guía ... Libros que estoy usando el desing dominio impulsado de Eric Evan ...... Driven Design dominios .NET con C#

Answer 1

1. Existe un gran debate acerca de si los repositorios deben ser de solo lectura o permitir transacciones. DDD no dicta ninguna de estas vistas. Puedes hacer ambas cosas Los defensores de los repositorios de solo lectura prefieren la Unidad de trabajo para todas las operaciones de CUD.

2. La mayoría de las personas (incluidas) consideran una buena práctica que las entidades son persistentes-Ignorantes. Extender un poco ese principio indicaría que deberían ser autónomos y estar libres de todos los servicios de la capa de infraestructura, incluso en forma de resumen. Por lo tanto, diría que las llamadas a servicios de infraestructura pertenecen a clases de servicios que operan en entidades.

3. Parece correcto que las implementaciones del repositorio y las fábricas (si las hay) deben residir en la capa de infraestructura. Sus interfaces, sin embargo, deben residir en la capa de dominio para que los servicios de dominio puedan interactuar con ellos sin tener dependencias en la capa de infraestructura.

4. DDD realmente no dicta si se puede saltar capas o no. Al final del libro, Evans habla un poco acerca de las capas y lo llama Capa Relajada cuando permite esto, así que supongo que simplemente lo ve como una opción entre varias. Personalmente, prefiero evitar el salto de capas, ya que hace que sea más fácil inyectar algún comportamiento en el futuro si las llamadas ya pasan por las capas correctas.

Answer 2

1. Personalmente, en mi última DDD-proyecto, utilizo una unidad de trabajo que lleva a cabo una sesión de NHibernate. La UoW se inyecta en los repositorios, dándoles el único responsable de Agregar, Eliminar y Buscar.

2. Evans ha declarado que una pieza del rompecabezas que falta en el libro DDD es «Eventos de dominio». Usar algo como Udi Dahan's DomainEvents le dará una arquitectura totalmente desacoplada (el objeto de dominio simplemente genera un evento).Personalmente, uso una versión modificada de Domain Events y StructureMap para el cableado. Funciona muy bien para mis necesidades.

3. Recomiendo, en base a otras recomendaciones, que las interfaces del Repositorio sean parte del modelo, y sus implementaciones sean parte de la infraestructura.

4. Sí! Personalmente trabajé en tres proyectos web de DDD en los que se inyectaron servicios y repositorios a los presentadores/controladores (ASP.NET/ASP.NET MVC) y tuvo mucho sentido en nuestro contexto.

Answer 3

1. El repositorio debe ser sólo para la localización y el ahorro de entidades, no debería haber ninguna lógica de negocio en esa capa. Por ejemplo:

   repository.TransferAmount (amount, toAcount); // esto es malo

2. Las entidades pueden hacer cosas como enviar correos electrónicos, siempre y cuando dependan de las abstracciones definidas en su dominio. La implementación debe estar en su capa de infraestructura.

3. Sí, pone su implementación de repositorio en su capa de infraestructura.

4. ¿Puede la capa de la interfaz de usuario (controladora) llamar a los métodos Repositry directamente? o deberíamos llamarlos desde la capa de Aplicación?

Sí, trato de seguir este patrón en su mayor parte:

[UnitOfWork] 
public ActionResult MyControllerAction(int id) 
{ 
    var entity = repository.FindById(id); 
    entity.DoSomeBusinessLogic(); 
    repository.Update(entity); 
}