CRUD en DDD Application Services?

Question

Soy nuevo en DDD, pero estoy tratando de incorporar conceptos de DDD en mi proyecto actual.

Para muchas entidades en mi dominio, los clientes necesitan realizar todas las operaciones CRUD estándar independientemente de cualquier flujo de trabajo particular. Me encuentro con una serie de servicios de nivel de aplicación con nombres como UserService o LocationService que hacen poco más que actuar como fachadas para los respectivos repositorios.

¿Son estas aplicaciones de servicios como repositorio de fachadas de una aplicación "correcta" del patrón de servicios de aplicaciones? ¿O deberían los métodos exclusivos de CRUD permanecer fuera de los servicios de aplicaciones? De ser así, ¿debería haber una fachada de repositorio en la capa de interfaz?

Answer 1

Esto, por supuesto, depende de la aplicación y también puede ser una cuestión de gusto donde algunos optan por un enfoque más directo y exponen el repositorio directamente a los clientes. Un beneficio de este enfoque es la simplicidad. No estás atravesando capas para rastrear la ejecución del código. Por otro lado, un rol del servicio de aplicación es el de una fachada o API para la capa de dominio.

En otras palabras, los servicios de aplicaciones encapsulan la capa de dominio y orquestan la ejecución de la lógica de dominio. Con este token, el repositorio también puede ser encapsulado por el servicio de la aplicación. El beneficio en este caso puede ser la consistencia, ya que todos los clientes de la capa de dominio interactúan con ella a través de servicios de aplicación, ya sea que emitan comandos o recuperen datos.

La mejor solución depende de su aplicación. Si toda la funcionalidad requerida es CRUD o mayoritariamente CRUD, no hay necesidad de un servicio de aplicación (o DDD completo para ese asunto) porque en este caso todo lo que hace el servicio es delegar en repositorios y, por lo tanto, agrega una complejidad innecesaria. Sin embargo, el servicio de aplicaciones también puede ser un cruce conveniente para administrar transacciones y unidades de trabajo, que el repositorio no debería tener que manejar.

Una alternativa es delegar esta responsabilidad en la infraestructura del entorno de alojamiento, como filtros de acción en una aplicación ASP.NET MVC.

---

Answer 2

Sus métodos en los servicios de su aplicación deben tener nombres que representen sus casos de uso. A menudo se dice en DDD que debe evitar CRUD, pero en mi experiencia, los propietarios de productos/expertos de dominio a menudo hablan en términos de 'crear' o 'agregar' una entidad, y 'actualizar', 'editar' o 'modificar' y entidad. Si esos son los casos de uso que se le ha encomendado implementar, seguramente estarán en su capa de aplicación.

Si los propietarios del producto están hablando en términos de reflejar CRUD, entonces debería estar allí, pero si están hablando en términos que no reflejan CRUD, entonces debe evitarlo.

Answer 3

Si su dominio requiere casos de uso de tipo CRUD, entonces ellos son correctas.

En mi opinión, exponer los repositorios directamente sería incorrecto, ya que las responsabilidades de los servicios de la aplicación incluyen algo más que "solo" el caso de uso funcional; eso es control de transacción, seguridad y validación de entrada básica.