Mejoras en entidades - K3001 - Vultaggio Martín Salvador

[MartinVulta]

Punto 5:
a.
• Tuve que crear la entidad Alerta. Para eso, cree la entidad junto con Clima e Email, e hice que tuviera un asunto, una ciudad, una temperatura en Celsius, una humedad, una condición, una velocidad del viento en km/h y un mensaje, además de un builder.
• Para aplicar la entidad Alerta en AlertasService, hice que, al generarYEnviarEmail, reciba un clima, creé una alerta con la información de ese clima, y enviase para cada destinatario un email con el asunto de la alerta y su mensaje.
• Por último, por si nos interesase persistir las alertas generadas en memoria, creé un repositorio de alertas.
• Creé DTOs, EmailInput, EmailOutput y ClimaInput. Para eso les puse a cada uno la info. básica que contenían sus entidades de dominio, permaneciendo DTOs, aunque contasen con un builder.
• Apliqué a todos los services y al EmailController que utilizasen estos DTOs en vez de mapear las entidades Clima e Email.
• En procesar emails pendientes, para abarcar el caso de que el envío de un email fallase, creé la excepción EmailNoEnviadoException y utilicé un try catch para tirar dicha excepción.
• Le inyecté a AlertasService una CondicionAlerta para que utilizase el método de ésta para evaluar si un clima cumplía las condiciones de alerta.

b.
• Porque creé una Alerta?
Para encapsular los datos del clima y poder manejar su almacenamiento y envío por separado, así, la lógica de detección de alertas, su creación y almacenamiento están mejor separados. Así el código es más fácil de entender y modificar. Además, al agrupar los datos relevantes del clima en un objeto propio, la alerta, otros componentes pueden trabajar con esta entidad sin conocer los detalles del clima. Por otra parte, al guardar las alertas en un repositorio, permite que estas puedan persistir para ser reutilizadas con otro fin en el futuro.

• Porque utilicé DTOs?
Para proteger las entidades de dominio (clima e email), controlando que datos se exponen entre ellos, y encapsular la lógica de negocio de la de los controladores, y separar la responsabilidad entre las capas.

• Porque tuve que considerar el caso de que un envío de email fallase?
Porque es fundamental que el código considere situaciones en las que algo no funcione correctamente (en este caso el envío de un email), así evitar una interrupción en todo el sistema.

• Porque tuve que modificar la aplicación de la condición?
Para empezar, para separar la lógica de verificación de alerta de un clima del código de AlertaService, para además quitarle esa responsabilidad al código y para poder modificar la condición en cual se verificase si era una alerta sin modificar el código de AlertaService.