Cuándo es útil la arquitectura Hexagonal? Evita ser El Arquitecturras™️ de tu equipo
Vložit
- čas přidán 3. 06. 2023
- La Arquitectura Hexagonal es una de las formas más famosas para modelar nuestro código. Hoy vamos a debatir sobre cuando tiene sentido utilizarla, y sobretodo, cuando no.
Curso de Arquitectura Hexagonal: pro.codely.com/library/arquit...
Curso de Arquitectura Hexagonal en el front: pro.codely.com/library/arquit...
﹤🍍﹥ CodelyTV
├ 🎥 Suscríbete: czcams.com/users/CodelyTV?sub_co...
├ 🐦 Twitter CodelyTV: / codelytv
├ 🧔🏻 Twitter Javi: / javiercane
├ 💂♀️ Twitter Rafa: / rafaoe
├ 📸 Instagram: / codelytv
├ ℹ️ LinkedIn: / codelytv
├ 🥋 Academy: codely.com/academy
└ 📕 Catálogo cursos: bit.ly/cursos-codely - Věda a technologie
Buenísimo video, comparto totalmente todo lo que habéis comentado. También el aplicar arquitectura hexagonal depende mucho de hacia donde se visualiza que llegue el proyecto.
que bueno jajajajaja de 10 !! yo creo que a veces se entra en modo arquitecturras pero mola mola :) un placerako como siempre y un saludote a tope para tod@@@@ssss !! a tope codeeeeee
Yo estoy aprendiendo a programar y desarrollar y me llegué a marear con tantos patrones de diseños y de arquitectura. Entre tanto, me perdí y no sabía por donde comenzar ni que patrón aplicar. Al final me frustré y me estanqué por mucho tiempo. Ahora continúo viendo estos vídeos para aprender y lograr entender cuando sí cuando no. Gracias.
35:00 Tal como lo entiendo yo, el repository debe pertenecer a la capa de dominio porque solo debe cumplir las reglas de dominio (y no tanto las de aplicación, que van en su propia capa). Para eso quizás primero debería explicar que entiendo por reglas de dominio: Son las reglas comunes de negocio que se comparten entre todas las posibles aplicaciones. Esto tiene sentido sobretodo en contextos empresariales, donde es normal que existan muchas aplicaciones que en el fondo trabajen con un mismo dominio que puede ser montado en una librería a parte (aunque muchas veces esto no se hace, provocando duplicidad que termina dando lugar a errores evitables...). Actualmente por ejemplo, trabajo en un producto donde solo por parte de mi equipo, existen tres aplicaciones distintas que trabajan sobre un mismo dominio (Eso sin contar los procesos batch, que están repartidos entre varias otras aplicaciones).
Esto también quiere decir que no hay que abusar de los repository... por ejemplo, es admisible que en algunos casos concretos donde se necesiten un subconjunto de datos, se devuelvan más datos de los necesarios que a posteriori se filtren en la capa de aplicación, o que se invoquen dos métodos del repository en lugar de solo uno (siempre y cuando esto no suponga un gran impacto; o dicho de otra forma, simplemente no optimices de forma prematura)
Excelente video!
El repository es una mini capa intermedia entre el dominio y la infra. Yo la suelo poner en la infra y que siempre me devuelva una interfaz. Ademas tengo casos de uso directamente y explicitamente en la capa de dominio ya que el dominio es el que me representa la logica de negocio y no la de application. (Por lo menos desde mi punto de vista). Cada caso de uso queda completamente abstracta ya que lo puede usar cualquiera y ademas internamente tiene DI para poder cambiar la persistencia, que puede ser mongo a sql o incluso usar un API para un servicio.
Si no conoces a nadie que sea "El Arquitecturras" es porque tú eres "El Arquitecturras" 😂
50:21 Comparto completamente lo que dice Sergi de Pablos. Al menos en las consultoras, se ha hecho mucho hincapié en tener equipos felices, y extremadamente poco en hacer software de calidad que realmente entregue valor. Eso no significa que sea malo tener equipos felices... pero el no haber hecho el suficiente hincapié en el desarrollo de software de calidad, ha provocado que exista mucha mierda en producción. En mi experiencia laboral, y he pasado por bastantes proyectos, solo he visto un equipo que realmente hacía hincapié en eso... en el resto, como mucho lo hacían a medias. Y claro, como ignorar que se debe desarrollar software de calidad (o solo hacerlo a medias) se traducía en un software de mierda (ya sea en forma de bugs o en complejidad para ejecutar los cambios solicitados), eso normalmente termina generando equipos más infelices, por mucho que se esforzasen en lo contrario.
De hecho, la de proyectos inmantenibles y plagados de bugs que he visto porque se ha exigido usar tecnologías/arquitecturas que no tenían sentido en el contexto de la aplicación y olvidándose de todo lo demás (incluido el enseñar como usar dicha tecnología/arquitectura)... en fin, es que simplemente son demasiados para contarlos.
recien los descubro! excelente canal
Padre!!! Lo de la arquitectura!!! Entérese ahí de lo que están arquitectando Padre
Lo que si nadie puede negar es que le saben y un buen, ahora el hex bueno es a gusto claro está que si se necesita una arquitectura para organización y más cuando se trabaja en equipo, pero cada quien puede establecer su propia arquitectura lo que siento incómoda es que esto lo “venden” como la única solución
Todo en el desarrollo es un “Depende” pero siempre tratar de hacer código escalabre para no tener los clásicos problemas del “día 2”
La curva del flipadismo jajaja debo decir, que soy culpable. Jeje 😅
Con el tiempo he aprendido a predecir qué proyectos escalarán al grado de que sea casi imposible refactorizar en el día a día y cuáles se quedarán casi como nacieron.
Eso es aplicar la metodología GRASP
100% con vosotros, con el ejemplo de cambio de mysql a sqlite pude ser que la gente de esa argumentación, pero... ¿qué tal con el ejemplo de enviar un SMS, o cambiar de proveedor de email? Esto es algo que suele suceder más a menudo. Puede que por ahí entre más fino el paradigma.
Abrazo crackens!
Buen video
Buen contenido como siempre. 👏🏻
Respecto a lo comentado de la capa de dominio y sus repositorios, no es peligroso exponer entidades y sus repositorios fuera del dominio y dejar que la capa de aplicación modifique directamente los estados del dominio y emita los eventos? se supone que para eso son los agregados, los factories o los servicios de dominio no??
Tienen contenido sobre Rich Domain Design? Sería interesante que pudieran hablar bajo su experiencia respecto a este tópico, ya que me he topado con muchos proyectos donde implementan escandalosamente mal DDD. 😅
En el libro "Domain-Driven Design in PHP" de Carlos Buenosvinos, se explica sobre "Anemic Domain Model" vs "Rich Domain Model".
Propongo el concurso "¿Pragmatismo o desconocimiento?". Se descubre un codigo y hay que determinar cual ha sido el motor de dicha implementación.
Como primer concursante El Arquitecturras™️ : "pero esto que es!!?? niño, lo de la hexagonal ahi buena! Jefe, la 'dolorosa' del Redis! pero que sa roto aquí!!! Lo de las capas, que sepa usted lo de las capas, es que no saben..."
¿Qué se sabe de metodología GRASP?.... dicen que es para realizar programación heurística, de manera que "antes" de dar una solución a un problema aplicando patrones GOF, se previene antes el uso de algunas de esos patrones centrandose sobre todo en el "acoplamiento" del código
Esta super bueno, de hecho todos los videos que he visto de ustedes estan muy muy buenos, muchas gracias.. Solo un favor, no soy Español jejeje alguien puede explicarme que quiere decir cuando dicen por ejemplo "DDD no significa fliparse; no es flipadismo" jajaja no entiendo que quieren decir con eso !!! que es fliparse ??
a ver.. eso se llama Síndrome de Dunning Kruger.. pero eso no niega que la arquitectura que se aplica en mi empresa y en el código, lo llaman "DDD" porque lo tienen divididos por capas... pero resulta que todo el dominio depende de primero crear la tabla y campos en SQL Server... me baso en la calidad de código y el soporte ofrecido por SOLID y resto de clean code.. luego se ajusta en la arquitectura del software....
se le da mucho bombo a la arquitectura hexagonal pero al final es una forma de organizar los paquetes. que mas te da si la inferfaz del servicio esta en una paquete qeu se llama servicio y la implementacion dentro del de serivico en implementacion que el servicio en aplicacion y la implementacion en dominio? que este en un paquete o en otro no aplica una diferencia. la forma de programar si
Este tipo de videos hacen mucha falta, creo que fliparse está muy bien porque es una forma de de aprender, pero lo peligroso es qué hay gente que nunca se desciende del pico de la curva porque hacer código complejo les da un sentido de importancia.
jaja Mr. Refactor
La arquitectura hexagonal tiene sentido en Frontend?
Definitivamente
Ojo al piojo y no siempre el problema es cambio de BD y lo mas importante es la testeabilidad . Hay miles de cosas más como
ISecurity( Lightweight Directory , active directory, linux),
ICahce (redis,memcached, etc )
IEmail (y sus mil formas de manejarlo x APIs , x SMTP provider)
y mas ejemplos..
Hay muchas cosas que conviene hacerlas con Interfaces + ClasesConcretas Y en mi historia me vi muchas veces con la necesidad de reescribir la clase que impleenta pero sin cambiar la Interfaz . Con lo cual el core-engine de desarrollo Sigue sin sufrir el caos de la re-escritura de codigo
Y nos ahorro miles de horas de trabajo ya que habiamos hecho todo orientadora Interfases (Servicios SOA)
Muy acoplado a la programación orientado a objetos
Pero la realidad es que mucho ni siquiera se han leido el articulo donde ese dr. trata de explicar los que significa hexagonal que de paso, ni el mismo supo explicar. y a la final dice que todo se trata de intuicion, que inrresponsable, un dr con tanto aporte libros y al final de su carrera salga con esto. lo que hizo fue a venir a crear un enrredo y no aporto nadaaaaaa pero nada.
Ya de por sí el que haya elegido 6 lados (hexagonal) para describirlo... totalmente arbitrario. Son los principios que ya existían, pero se empaquetaron en una jerga nueva para revenderlo a las nuevas tribus...
El Arquitecturras es el pariente cercano del Arquitecto power point
Entonces que soy? 😢