Casos de Uso

En este repositorio en particular, se presenta una implementación de la Arquitectura Limpia utilizando casos de uso como un enfoque central. Los casos de uso encapsulan y implementan las reglas de negocio específicas de la aplicación, dirigiendo el flujo de datos entre las entidades y utilizando la lógica de negocio para lograr los objetivos establecidos. Los cambios en esta capa no deberían afectar a las entidades, y se espera que sean independientes de factores externos como la base de datos, el framework o la interfaz gráfica.

Además de los casos de uso, el repositorio incluye adaptadores de interfaz que se encargan de convertir los datos entre el formato más conveniente para los casos de uso y las entidades, y el formato aceptado por elementos externos como la base de datos o la interfaz de usuario. Estos adaptadores incluyen presentadores, vistas y controladores. También se hace hincapié en la separación de capas y en mantener los detalles específicos, como los frameworks y las herramientas, en el círculo externo de la arquitectura [1].

La relevancia de la arquitectura y diseño de sistemas en el desarrollo de software radica en la capacidad de crear soluciones robustas, mantenibles y escalables. Una arquitectura adecuada permite gestionar la complejidad del software, separando las preocupaciones y promoviendo la reutilización de componentes. Además, un diseño bien estructurado facilita la evolución y adaptación del sistema a medida que los requisitos cambian. La Arquitectura Limpia y el enfoque de casos de uso promueven estos principios, proporcionando una estructura clara y una separación de responsabilidades que ayuda a desarrollar sistemas de alta calidad y fáciles de mantener.

Casos de uso

Contiene reglas de negocio específicas de la aplicación. Coordinan el flujo de datos desde y hacia el modelo de dominio.

Se suele implementar una clase por caso de uso.

Nota: Los casos de uso se suelen encontrar con los sufijos Interactor, Service o CommandHandler.

“clean-architecture-with-use-case”.

Este archivo contiene una implementación de la clase RequestCourseRegistrationInteractor, que es un caso de uso relacionado con la registración de cursos. Aquí está el análisis de los ejemplos de casos de uso en el archivo:

1- La clase RequestCourseRegistrationInteractor implementa la interfaz IRequestHandler<CourseRegistrationRequestMessage, CourseRegistrationResponseMessage>. Esto indica que es responsable de manejar las solicitudes de registración de cursos y proporcionar una respuesta correspondiente.

2- Los parámetros del constructor de RequestCourseRegistrationInteractor son interfaces que representan los repositorios y servicios necesarios para realizar la registración de cursos. Estos incluyen IAuthService, IStudentRepository y ICourseRepository.

3- El método Handle es el punto de entrada del caso de uso. Toma un objeto CourseRegistrationRequestMessage como entrada y devuelve un objeto CourseRegistrationResponseMessage como resultado.

4- Dentro del método Handle, se realiza una verificación para determinar si el estudiante está autenticado antes de continuar con la registración. Si el estudiante no está autenticado, se devuelve una respuesta de error indicando que la operación ha fallado debido a la falta de autenticación.

5- Luego, se obtiene la instancia del estudiante utilizando el IStudentRepository y se crea una lista de errores para almacenar cualquier problema durante el proceso de registración.

6- A continuación, se itera sobre los códigos de los cursos seleccionados en el mensaje de solicitud y se obtiene la instancia de cada curso utilizando el ICourseRepository. Se intenta registrar al estudiante en cada curso mediante el método RegisterForCourse. Si la registración no tiene éxito, se agrega un mensaje de error a la lista de errores.

7- Después de completar la iteración, se guarda la instancia del estudiante actualizada utilizando el IStudentRepository.

8- Por último, se crea una instancia de CourseRegistrationResponseMessage con un indicador de éxito basado en la presencia o ausencia de errores, y se devuelve junto con la lista de errores.

✅

En un proyecto donde implementamos Hexagonal usamos el prefijo “UseCase” y para los servicios de domino “Service”. Esto puede variar según los proyectos y equipos, lo más importante es manejarlos con claridad a nivel empresarial.

Curiosamente nunca he visto un proyecto con Interactor, pero si he visto y he trabajado con proyectos que usan CommandHandler y Service 🤔