Especificaciones
Un Application services no debe ser tan complejo como el Use case. Cumple tareas muy concretas, con lo que le damos una complejidad de 3.
Su función principal. Libera al Use case de las tareas repetitivas y las hace reutilizables para el resto. Así dejamos los Use case lo más delgados posible y dedicados a su función de orquestar. Todo lo que sea reutilizable y no contenga reglas de negocio, va a servicio de Application service.
Esto suele reducirlo a notificaciones orientadas exterior que tengan cierta complejidad como envíos de mails o notificaciones a APIs de terceros. Si no se usara este tipo de servicios en la Application layer, su complejidad se vería empujada a la Infrastructure layer.
Como características más destacables. Suele ir a Infrastructure layer para conseguir sus objetivos.
Se relaciona de forma natural con los Command use case y Query use case, Persistence, Search o Notifications. Estas son cartas que veremos más adelante. Son las llamadas Ability cards
Como observación. Para los fans de usar dobles de test en lugar de mocks, los Services que usa el Use case, al no estar en otra capa diferente, se inyectan sin una interfaz. Eso deja la opción, de hacer los dobles de test justo en los puntos donde el Application service quiere utilizar la Infrastructure layer a la hora de testear el caso de uso.
¿Qué valor me aporta implementar un Application service?
- Libera al caso de uso de los pequeños detalles que se suelen gestionar cuando tratamos con las capas de infraestructura. Así, cuando haya otro caso de uso que lo necesite, esos pequeños detalles estarán ya resueltos y concentrados.
¿Cómo se expresa esta carta en el mundo real?
Como indican los iconos de arriba a la izquierda, corresponde a una clase, que contendrá la funcionalidad y como estructura organizativa, es interesante dejar dichas clases dentro de una carpeta.
TODO!!!!!!! Describir escenario
|
|