Tengo entendido que el patrón de arquitectura hexagonal no prioriza la segmentación del código en capas, sino mas bien persigue una segmentación orientada a definir que piezas del código son clases adaptadores (implementaciones) , cuales son los contratos de esas clases (los puertos), que parte del código pertenece a la lógica de negocio y que por tanto esta ultima debe estar desacoplada de las implementaciones de librerías y frameworks etc.
gracias por la explicación, tengo un par de preguntas: Para este ejemplo en especifico, que viene siendo el archivo main.ts? Con respecto a la estructuras de carpetas como debería de quedar la estructura de UI si estuviera usando jetpack compose?
Buenísimo el contenido como siempre. Lo bueno de la arquitectura hexagonal es que al ser agnóstica a la capa o al lenguaje, puedes aplicarla tanto a front como a back. Grandes Moure y grandes la gente de Codely 👏🏼👏🏼.
He visto que aveces ponen dentro del Domain la carpeta Services (que son los casos de uso) y no en la carpeta application, consideras que está bien también?
Entiendo que hay servicios de aplicación, infraestructura y dominio, cada uno con su objetivo. Un servicio de dominio encapsula lógica de negocio repetitiva entre diferentes casos de uso, siendo más complejo que las entidades y actuando como orquestador. En resumen, son clases que no pertenecen a un caso de uso específico, pero que manejan funciones repetitivas y complejas relacionadas con la lógica de negocio.
¿Qué te ha parecido el "Hola Mundo day"? La conferencia de programación creada por y para la comunidad.
🔗 holamundo.day
Muchas gracias por el contenido increíble , saludos desde Chile 🇨🇱
Con esto si entendí lo que me hacia falta, grande Moure por traer esos dos grandes (Nuria te amo)
buen extracto de hexagonal en frontEnd, seria genial que compartan el git
gracias y sigan los éxitos
Genial Nuria, le quita peso a tanta teoría y lo lleva a un terreno más práctico.
hay algún repo construido para ver ejemplo en código.
Tengo entendido que el patrón de arquitectura hexagonal no prioriza la segmentación del código en capas, sino mas bien persigue una segmentación orientada a definir que piezas del código son clases adaptadores (implementaciones) , cuales son los contratos de esas clases (los puertos), que parte del código pertenece a la lógica de negocio y que por tanto esta ultima debe estar desacoplada de las implementaciones de librerías y frameworks etc.
en el caso que use una libreria externa para la validacion que pasaria con los valueObjects?
Primero!, Gran conferencia por cierto!
el repo es publico??
gracias por la explicación, tengo un par de preguntas:
Para este ejemplo en especifico, que viene siendo el archivo main.ts?
Con respecto a la estructuras de carpetas como debería de quedar la estructura de UI si estuviera usando jetpack compose?
Buenísimo el contenido como siempre. Lo bueno de la arquitectura hexagonal es que al ser agnóstica a la capa o al lenguaje, puedes aplicarla tanto a front como a back.
Grandes Moure y grandes la gente de Codely 👏🏼👏🏼.
¿Cuál es el repositorio?
Gran contenido, cuando usarla y cuando no ?
Rafa Gómez eso es un bajo eléctrico o una guitarra lo que está detrás?
quisiera saber si los casos de usos es como los data transfer object (DTO)
He visto que aveces ponen dentro del Domain la carpeta Services (que son los casos de uso) y no en la carpeta application, consideras que está bien también?
Entiendo que hay servicios de aplicación, infraestructura y dominio, cada uno con su objetivo. Un servicio de dominio encapsula lógica de negocio repetitiva entre diferentes casos de uso, siendo más complejo que las entidades y actuando como orquestador. En resumen, son clases que no pertenecen a un caso de uso específico, pero que manejan funciones repetitivas y complejas relacionadas con la lógica de negocio.
Estria bien el codigo..
Segundo!
que mal explican, saludos.