¿Debo recurrir siempre a los servicios cuando trato de seguir DDD?¿Debo usar siempre el servicio o puedo usar los repositorios directamente?
¿O puedo usar un repositorio directamente para obtener un objeto de dominio?
Personalmente, no me gusta ver repositorios en los controladores, o en la capa de presentación en general. Pero lo he visto muchas veces y no hay nada de malo en el contexto de DDD.
Creo que la respuesta es que depende de cuán grande sea su proyecto. Una capa de servicio se encuentra con mayor frecuencia en proyectos más complejos. Mientras que los sitios web más simples de MVC, por ejemplo, simplemente usan repositorios directamente.
¿O puedo usar un repositorio directamente para obtener un objeto de dominio?
Usted definitivamente puede. Es precisamente el objetivo de los repositorios. Me pregunto qué tipo de servicio usarías para eso (excepto en el contexto específico de una arquitectura SOA o basada en servicios web).
Mi pregunta (intencionada) fue si puedo eludir los servicios y obtener entidades de dominio directamente de los repositorios (por ejemplo, en un controlador MVC) – jgauffin
Bueno, lo hice bien y la respuesta es sí :) Es gracioso ver que algo se considera perfectamente normal y común si miras el libro original de DDD y el movimiento ahora parece asustar a la gente ... – guillaume31
No tengo miedo. Solo quería saber cuál es la mejor práctica. El libro fue lanzado hace nueve años y puede haber sucedido una o dos cosas desde entonces ... – jgauffin
Después de completar mi primer proyecto estructurado usando los principios DDD: D, encontré que es útil tener tanto servicios de dominio como repositorios que están disponibles para que la capa de aplicación los consuma.
PUNTO CLAVE: La capa de aplicación puede ser sus servicios WCF o el código en sus servicios web si está utilizando esa arquitectura. Todo depende de tu implementación. Si se adapta a su implementación, su capa de aplicación puede ser la misma que su capa de presentación, por lo tanto, tiene el código de capa de aplicación en sus controladores o en el código de formularios web.
Los repositorios funcionan como colecciones en memoria. Para la capa de aplicación, el código debería verse como si estuvieras usando cualquier colección anterior.
Los servicios de dominio funcionan más como procesadores o accionadores de información que nunca serán actualizados, procesados, pero no actualizados directamente. Para la capa de aplicación, el código debería parecerse a que está utilizando cualquier servicio web antiguo.
Dicho esto, voy a explicar más con algunos ejemplos:
repositorios
Mis repositorios realidad heredan de una colección genérica mecanografiado con un objeto aplicación creé que encapsula la clave de la base de datos y el negocio modelar juntos. Usando este enfoque, puedo definir un controlador paso a paso en mi interfaz, como
BusinessObject this[int index];
y puedo tener un captador que devolverá el objeto de negocio basado en el índice de la colección subyacente y un regulador que buscar la clave de datos de la colección subyacente y guarde el objeto en la base de datos. Esto hace que el código de la aplicación extremadamente simple, por ejemplo
IBusinessObjectRepository repository = new SqlBusinessObjectRepository(sqlString);
BusinessObject obj = repository[0]; //Get first object in the list.
//Make some changes to the business object by setting properties or calling methods to process business logic.
repository[0] = obj; //Save the object back to the database.
Servicios
utilizo los servicios para recuperar las listas de entidades y objetos de valor que no voy a editar de forma individual y, en mi caso, son solo se utiliza como selecciones o valores disponibles cuando se invocan métodos en la raíz agregada.En general, guardo en caché esta información en el servidor web. Este no es el único uso para un servicio de dominio, solo mi ejemplo. El código de la capa de aplicación sigue siendo relativamente simple.
IBusinessService service = new ImplBusinessService(implementationArgs);
List<BusinessObject> objsToCache = service.GetBusinessObjects();
//cache the objects on the web server.
En conclusión y de mi comprensión de los principios DDD, la capa de aplicación debe ser capaz de acceder a los objetos de negocio ya sea de servicios o repositorios. La elección entre ellos se reduce a lo que mejor se ajusta al modelo de dominio.
"No me gusta ver repositorios en los controladores" => ¿Puede explicar por qué y qué capa intermedia agregaría entre el controlador y el repositorio? – guillaume31
Los controladores tienden a hincharse muy rápido. Una de las razones para esto es porque los desarrolladores terminan pegando lógica de negocios en sus controladores. La lógica empresarial solo debe vivir en la capa de dominio principalmente, y luego en la capa de servicio, no en el controlador ni en el repositorio. Al usar un Servicio (de Aplicación) en su controlador, lo evita. Por ejemplo, llamaría a accountService.GetUserByEmail (correo electrónico) o catalogueService.GetProductViewModel. Su controlador se mantiene agradable y delgado y su servicio de aplicaciones coordina hablando con varios repositorios. – autonomatt
El hecho de que obtenga un objeto de un repositorio no significa que trabaje en lógica comercial. Solo se trata * de hacer que el objeto * desde la capa de dominio se use en otra capa. Y no puedo ver cómo una sola línea userRepository.GetUserByEmail (email) hincha el controlador más que accountService.GetUserByEmail (email). – guillaume31