🤔 Cuándo usar

🔥 ¡Aprovecha la oferta del Black Friday de CodelyTV Pro!
⮕ codely.tv/pro/blackfriday?utm...
---
Analizamos los beneficios de introducir una interface en términos de tolerancia al cambio y testabilidad. Nos planteamos cuándo sería apropiado por tanto introducir una interface en nuestro código, y sobre todo, cuándo y por qué sería algo a evitar.
❓ Preguntas a responder:
* Cuándo definís interfaces (Árbol decisional para meter una interface como el que comentamos en el vídeo)
* Inyectáis los Domain Services en los Application Services vía constructor, ¿o los instanciáis en el constructor del Application Service?
Links relacionados:
* 👨‍👩‍👧‍👦 Vídeo Composición sobre herencia: • Qué es la "Composició...
* 🎟️ Tweet a hacer RT para entrar en sorteo de training Kotlin:
* 👨‍🎓 Training Kotlin por Karumi: www.karumi.com/open-training/...
* 🐘 Repositorio ejemplos PHP: github.com/CodelyTV/cqrs-ddd-...
* ⚛️ Repositorio ejemplos Scala: github.com/CodelyTV/scala-htt...
* 👩‍💻 Curso Principios SOLID Aplicados: bit.ly/solid-codelytv
* 🎯 Curso Arquitectura Hexagonal: bit.ly/hexagonal-codelytv
* ℹ️ Post Matthias Noback al respecto: matthiasnoback.nl/2018/08/whe...

[@hernanojeda9172]

Qué bueno encontrar personas que hablen al respecto del tema! Llegué medio tarde (mas de un año), pero me les dejo mi opinión al respecto del tema de la inyección de dependencias vs instancia en el constructor: - Para el caso de los repositorios me parece que no debería existir otra manera que no sea la inyección porque sino dentro del caso de uso deberíamos conocer detalles propios del IO (DataSource, RestClient, etc) - Para el caso de los Domain Services, desde mi punto de vista debería ser igual, también deberían estar inyectados. Me parece que en mi caso de uso no debería tener conocimiento de la implementación particular del servicio, el "finder" podría llamar a uno, dos o cinco repositorios para encontrar el video, pero en el caso de uso no me debería interesar esa particularidad. Si instancio el servicio en cada caso de uso que lo utilice, entonces el caso de uso debería conocer todos los repositorios que utiliza el servicio. Por otro lado, teniendo en cuenta que el servicio no debería mantener estado, lo definiría dentro del contexto de IoC como un singleton. Para concluir, definitivamente tendría todo inyectado. Espero su devolución =) Saludos!

[@nemines001]

👍🙏 andaba buscando estilo podcast de backend casi todos los canales se enfocan al front

[@CodelyTV]

😊😊😊

[@igarriz]

Chicos esta explicación a sido buenísima como siempre. Os sigo desde hace tiempo. Chapo por vuestro contenido

[@lucianosantillan164]

Genios!

[@Ramiprops]

Voy un poco tarde al video, pero yo inyectaria el servicio de dominio. Esto evita el denominado "courier antipattern" que básicamente intenta evitar eso de necesitar dependencias de tus dependencias. Al constructor tiene que llegarle las dependencias inmediatas, no las dependencias de dependencias de dependencias... A la que tu dominio se complique un poco, se puede volver excesivamente complejo este proceso de creación del árbol de dependencias.

[@cristianmosteiro6458]

muy buenos los tips gente, muchas gracias por compartir, me gusta la forma de presentarlo tambien. de pronto como hace mucho no toco el viejo y querido php pues me cuestan un pelo mas que con ejemplo en java o c# pero como dicen ustedes en, vamos todo no se puede y los ejemplos y conceptos son cross del lenguaje. Arriba

[@softwarengineeringwithfabri]

yo los domain services los creo también en el caso de uso. Realmente es algo de dominio que está muy ligado con el caso de uso. Lo mismo pasa con Domain entities, factorias etc

[@xserrat]

Sobre este caso, no acabo de verle la ventaja a instanciar un domain service directamente en el caso de uso. Por cómo lo veo, si lo hacemos así, será necesario inyectar al caso de uso todas las dependencias que necesite tanto el propio caso de uso como el domain service. Además, si el domain service necesita de una dependencia más o menos, tendremos que cambiar todas las instanciaciones que se hayan hecho en los casos de uso... Por otro lado, le veo sentido por el hecho de que el domain service visto desde el caso de uso, dado que nos ayuda a solucionar una lógica y que puede necesitar dependencias para resolverla, le especificamos qué dependencias necesita para ejecutar esa lógica...

[@RodrigoGarcia-nr6hv]

Me parece que estaría bueno inyectar también el servicio, más que todo también para no ocultar las dependencias del caso de uso, no?

[@CosasCotidianas]

No sería interesante inyectar sólo el servicio Videofinder, al cual se le inyecte la dependencia repository?

[@compartelo007]

Si no me he perdido la clase VideoFinder es un service, así que si ese service uso interface (cosa que en este vídeo no es el caso) lo inyectaría y si no usa interface, lo instanciaría. Saludos

[@AprendizSerial1979]

Mas volumen a los vídeos, se escucha medio bajo

[@hg3dev242]

Creerian que deben comprar microfono, el tema es bueno, pero el tema del audio es un factor muy importanteee

[@josuemercally]

Todo bien, pero cuando explican en PHP ya no entiendo nada....

[@bonaoenchelcha]

Realmente, deberian explicar en java o c# :)

[@patriciabonaldy9624]

jure que era en php el codigo en el video

[@clay9963]

Que pena que no sepa PHP, yo domino mas C#