DDD: ¿Dónde guardar las interfaces de dominio, la infraestructura?

Question

¿Tiene sentido agrupar todas las interfaces de su capa de dominio (módulos, modelos, entidades, servicios de dominio, etc.) dentro de la capa de infraestructura? Si no es así, ¿tiene sentido crear un proyecto/componente "compartido" que agrupe todos estos en una biblioteca compartida? Después de todo, la definición de "capa de infraestructura" incluye "bibliotecas compartidas para capas de dominio, aplicaciones y UI".

Estoy pensando en diseñar mi código base alrededor de las capas DDD: UI, Aplicación, Dominio, Infraestructura. Esto crearía 4 proyectos respetuosamente. Mi punto es que usted hace referencia a la capa de infraestructura desde la capa de dominio. Pero si define las interfaces en el proyecto de capa de dominio, digamos para IPost, tendrá una referencia circulur cuando tenga que hacer referencia al proyecto de capa de dominio del proyecto de infraestructura cuando esté definiendo el método IPostRepository.Save (IPost post) . Por lo tanto, la idea de "definir todas las interfaces en la biblioteca compartida".

Quizás los repositorios no deberían esperar que un objeto se guarde (IPostRepository.Save (publicación de IPost); en cambio, se esperan los params del objeto (que podría ser un conjunto largo de params en el Guardar()). , esto podría ser una situación ideal que muestra cuando un objeto está recibiendo demasiado complejo, y adicionales objetos de valor debe ser estudiado para ello.

Pensamientos?

Answer 1

Eric, Estaba ausente por un par, así que perdónenme por responder tan tarde. En cuanto a dónde colocar los repositorios, personalmente siempre pongo los repositorios en una capa de infraestructura dedicada (por ejemplo, MyApp.Data.Oracle) pero declaro las interfaces a las que los repositorios tienen que ajustarse en la capa de dominio.
En mis proyectos, la capa de aplicación debe acceder al dominio y a la capa de infraestructura porque es responsable de configurar el dominio y la capa de infraestructura.
La capa de aplicación es responsable de inyectar la infraestructura adecuada en el dominio. El dominio no sabe con qué infraestructura está hablando, solo sabe cómo llamarlo. Por supuesto, uso contenedores IOC como Structuremap para inyectar las dependencias en el dominio. Una vez más, no declaro que esta es la forma en que DDD recomienda estructurar sus proyectos, es solo el camino, yo diseño mis aplicaciones. Saludos.

Answer 2

estoy tranquila nuevo en DDD por lo que no dude para comentar si no está de acuerdo, ya que estoy aquí para aprender.

Personalmente, no entiendo por qué debería consultar ce la capa de infraestructura de su dominio. En mi opinión, el dominio no debe depender de la infraestructura. Los objetos de Dominio deben ignorar por completo en qué base de datos se están ejecutando o qué tipo de servidor de correo se utiliza para enviar correos. Al abstraer el dominio de la infraestructura, es más fácil de reutilizar; porque el dominio no sabe en qué infraestructura se está ejecutando.

Lo que hago en mi código es hacer referencia a la capa de dominio de mi capa de infraestructura (pero no al revés). Los repositorios conocen los objetos del dominio porque su función es preservar el estado del dominio. Mis repositorios contienen mis operaciones CRUD básicas para mis agregados raíz (get (id), getall(), save (object), delete (object) y se llaman desde mis controladores.

Lo que hice en mi último proyecto (mi enfoque no es puramente DDD pero funcionó bastante bien) es que abstraí mis Repositorios con interfaces. Los agregados raíz tuvieron que ser instanciados pasando un tipo concreto de un Repositorio:

El agregado raíz tuvo que ser instanciado mediante un repositorio usando el método Get (ID) o Create() del repositorio. El Repositorio concreto que construye el objeto se pasa para que el agregado pueda preservar su estado y el estado de sus objetos secundarios pero sin saber nada de la implementación concreta del repositorio. ej .:

public class PostRepository:IPostRepository 
{ 
    ... 
    public Post Create() 
    { 
     Post post=new Post(this); 
     dbContext.PostTable.Insert(post); 
     return post; 
    } 
    public Save(post) 
    { 
     Post exitingPost=GetPost(post.ID); 
     existingPost = post; 
     dbContext.SubmitChanges(); 
    } 
} 

public class Post 
{ 

    private IPostRepository _repository 
    internal Post(IPostRepository repository) 
    { 
     _repository = repository; 
    } 
    ... 
    Public Save() 
    { 
     _repository.Save(this); 
    } 

} 

Answer 3

Te aconsejaría que tener en cuenta Onion architecture. Se adapta muy bien a DDD. La idea es que las interfaces de repositorio se sientan en una capa justo fuera del dominio de referencia y entidades directamente:

IPostRepository.Save(Post post)

dominio no necesita saber acerca de los repositorios de todos.

La capa de infraestructura no está referenciada por el dominio ni por ninguna otra persona y contiene implementaciones concretas de repositorios entre otras cosas relacionadas con E/S.La biblioteca común con varios ayudantes se llama Application Core en este caso, y cualquier persona puede hacer referencia a ella.