Implementacion de service

[GonGarciaFontenla]

Buenas tardes! Como andan?
Estaba pensando implementaciones para LivreStream y me surgió una duda respecto a la responsabilidad del registro de usuarios. Entiendo que, desde un enfoque orientado a objetos, la clase PersonaRegistrada no debería encargarse de su propia creación, ya que aún no existe como instancia. Por eso, estuve considerando delegar esta lógica a una clase separada, como un ServicioDeRegistro, que se encargue de validar, crear y guardar nuevos usuarios.

Esta separación me resulta útil porque permite mantener una única responsabilidad por clase, aplicar validaciones antes de instanciar el objeto, y facilitar los tests. También pensé en complementar esto con un RepositorioDeUsuarios, como una interfaz que encapsule el acceso al almacenamiento de usuarios, lo cual ayudaría a desacoplar la lógica del dominio de la infraestructura.

Es correcto o recomendable utilizar un service para manejar el registro de usuarios, y acompañarlo con un repositorio para la persistencia? O sería preferible abordar esta responsabilidad desde otro patrón o clase, para mantener un diseño más orientado a objetos?

[GonGarciaFontenla]

Buenas! Me está volviendo a surgir la misma duda que plantee hace un rato.

En este caso, estoy trabajando con el requerimiento:
"Como persona internauta, deseo poder registrarme y crear mi canal en LivreStream."

La parte del registro ya la resolví, pero cuando fui a implementar la creación del canal, automáticamente pensé en crear un ServicioDeCanal que se encargue de validar si la persona ya tiene un canal, instanciar uno nuevo y guardarlo. Básicamente, un service que coordine la lógica.

Sin embargo, entiendo que la creacion de services no siempre es lo más adecuado desde el diseño puramente orientado a objetos. Por eso estuve explorando una alternativa, que sería darle esa responsabilidad directamente al objeto PersonaRegistrada, haciendo algo como:

public void crearCanal(String nombre) {
if (this.canal != null) {
throw new RuntimeException("Ya tiene un canal");
}
this.canal = new Canal(nombre, this);
}
Esto evita la clase service. Pero entonces me vuelve la duda:

Cuando aparece la necesidad de validaciones externas (por ejemplo: ya existe un canal para esta persona?, el nombre está en uso?, persistimos el canal?), siento que inevitablemente vuelvo a necesitar un service, porque esa lógica ya no pertenece al objeto en sí mismo.

Entonces mi pregunta es:
Qué criterio recomienda usar para decidir cuándo conviene delegar este tipo de responsabilidades a un service, y cuándo conviene resolverlo desde los mismos objetos del modelo?

Me interesa poder entender mejor cuándo cada enfoque es más apropiado, ya que en la práctica me está costando evitar el uso de services sin romper otras buenas prácticas o dejar el modelo acoplado a cosas que no le corresponden.

[ParedesMicaela]

Hola buenas noches! Leyendo lo que planteas, me parece que estás encarando la solución muy desde el lado de la persistencia y validación de datos. Si bien eso es importante, yo le pondría más foco a cómo se resuelven los requerimientos de negocio más que en cómo se hacen las validaciones de los usuarios. Y contestando a la pregunta, pensá que en esta parte del año lo que más nos importa son las cualidades de diseño, siempre apuntá a un diseño que refleje cohesividad, bajo acoplamiento, mantenibilidad y que cada clase encapsule responsabilidades concretas.

[GonGarciaFontenla]

Hola Micaela!
Primero que nada, muchas gracias por responder.

Entiendo lo que me comentás y coincido en la importancia. Justamente vengo intentando aplicar estas ideas que mencionas, pero me encuentro con dificultad cuando aparecen ciertas reglas que no están explícitas en la sección de requerimientos, pero que parecen necesarias para que el dominio tenga coherencia.
Por ejemplo:

"Una persona registrada no puede tener más de un canal".

Ese tipo de reglas me llevan a pensar automáticamente en soluciones más técnicas, como crear un servicio para validar o coordinar esa lógica, o usar un repositorio para manejar la persistencia. Y ahí es donde me cuesta no desviarme de un diseño centrado en el modelo de dominio.

Lo mismo me pasa en otros requerimientos propios del sistema como:

"Como persona internauta, deseo poder listar canales"

En este caso también me viene la idea de repositorios a la cabeza.

Entonces, mi duda es:

¿En esta instancia del año, conviene dejar de lado las validaciones y temas de persistencia para enfocarme exclusivamente en el diseño del dominio? Entiendo que esto podría complicar la implementación de ciertos requerimientos, como el listado de canales, pero quisiera saber si es recomendable priorizar un diseño enfocado, justamente, en las cualidades de diseño.

Muchas gracias!

[flbulgarelli]

¡Hola, @GonGarciaFontenla!

¿En esta instancia del año, conviene dejar de lado las validaciones y temas de persistencia para enfocarme exclusivamente en el diseño del dominio? Entiendo que esto podría complicar la implementación de ciertos requerimientos, como el listado de canales, pero quisiera saber si es recomendable priorizar un diseño enfocado, justamente, en las cualidades de diseño.

Sobre esto, no tengo mucho para agregar a la respuesta anterior de @ParedesMicaela. Simplemente insisto en su recomendación: concentrate en el modelado de dominio orientado a objetos, las cualidades de diseño, los code smells, los patrones de diseño, patrones de comunicación y todo otro concepto que hayamos trabajado que se desprenda de allí, porque de eso se trata el primer parcial. Todos los requerimientos del parcial tienen que ser abordados desde esos ejes.

Persistencia y presentación son temas que no sólo no entran en el primer parcial sino que no los trabajamos en lo absoluto en el primer cuatrimestre; tratar de resolver los requerimientos del parcial aplicando preconceptos que no desarrollamos ni discutimos en clase no sólo te hará perder tiempo, sino que incluso podría llevarte por caminos contrarios a lo que estamos estudiando en esta parte del año.

"Una persona registrada no puede tener más de un canal".

Ese tipo de reglas me llevan a pensar automáticamente en soluciones más técnicas, como crear un servicio para validar o coordinar esa lógica, o usar un repositorio para manejar la persistencia. Y ahí es donde me cuesta no desviarme de un diseño centrado en el modelo de dominio.

Sin cambiar la esencia de la respuesta, resalto que eso que vos planteás no son soluciones más técnicas (porque todo lo anterior también se basa en la aplicación de técnicas) sino que en todo caso son soluciones que presumen ciertas ideas (debatibles y con sus pros y sus contras) de arquitectura lógica que no trabajamos aún en la materia (o directamente no trabajaremos).

Sin ir más lejos y retomando lo que te decía en el párrafo anterior, notá como esos preconceptos arquitectónicos están sumando un montón de complejidad accidental ante una idea (la persona registrada sólo tiene un canal) que puede ser expresada fácilmente en términos de dominio (planteando adecuadamente las relaciones).

"Como persona internauta, deseo poder listar canales"

En este caso también me viene la idea de repositorios a la cabeza.

Sobre esto último, es válido que apliques el concepto de repositorio para resolver algún requerimiento (o una parte), porque es una técnica de diseño del dominio. De todas formas, acá es importante dejar en claro que por repositorio me refiero a la idea de un objeto globalmente accessible que es responsable de conocer a todas las instancias de un tipo, clase o familia de objetos y cuyo comportamiento está exclusivamente orientado a operar ese conjunto de instancias.

Como ves, no estoy utilizando a éste concepto bajo la interpretación (más acotada y que se trabaja en otras materias) de una capa de acceso a datos o un objeto encargado de gestionar el ciclo de vida de objetos persistentes ni tampoco estoy hablando de interfaces para posibilitar el tratamiento polimórfico de medios de almacenamiento. Si bien la intuición de que hay un vínculo fuerte entre todas estas interpretaciones es correcta, nuevamente, merece mayor estudio en el segundo cuatrimestre. Pensar en cuestiones de persistencia está totalmente fuera del alcance del primer parcial.

¡Decinos si quedó claro!

[GonGarciaFontenla]

¡Buenas noches @flbulgarelli!

¡Quedó todo clarísimo! Muchas gracias por tomarte el tiempo para responder, y también muchas gracias a @ParedesMicaela por la explicación.

Cierro la discusión. ¡Buen fin de semana!