En serio, a veces me siento un poco tonto cuando leo documentación sobre patrones de software. Estoy leyendo un libro sobre arquitectura hexagonal (ports and adapters), y cuando empieza ahblar de "driving actors, driven actors, driving adapters, driven adapters, interactors, required interfaces, provided interfaces... me da un parraque y tengo que parar, releer cuatro veces, buscar en internet para entenderlo mejor... y entonces sí, las cosas empiezan a encajar. Pero es lento, me siento lento.
@kastwey yo he mirado hexagonal unas cuantas veces y no entiendo nada. Creo que describen cosas bastante normalitas, pero con una terminología nueva... no parece aportarme mucho.
Con Domain-Driven Design igual. He dejado dos libros a medias. Antes seguía conversaciones sobre DDD y no entendía nada (parecía que se liaban mucho para cosas simples).
Pero hay gente que admiro que recomienda ambas cosas, así que estoy un poco perdido...
@yo A ver, aportar sí que aportan, yo los uso ambos en mi día a día, pero antes tienes que entenderlos y empezar a aplicarlos... y montarte en tu cabeza unas explicaciones que a ti te funcionen. pero es que estoy leyendo estoy te juro que me dan ganas de reescribir el libro con ejemplos para tontos.
@yo @kastwey Yo los casos en que realmente aprendí algo fue en temas de estructura a gran escala, vamos a decir: model-view-controller, entity-component-system, etc. Porque en lo micro creo que todos más o menos sabemos resolver de un modo u otro y no hay soluciones generales que funcionen bien siempre.
@kastwey precisamente a mí lo que me faltan son los ejemplos para tontos, PERO con el "antes" y el "despues". Porque lo que muchas veces me falla es visualizar "lo contrario de arquitectura hexagonal". Me parece que es lo que sale naturalmente si haces componentes de una única responsabilidad, pero sospecho que me falta alguna pieza.
El problema que le veo es que no sé si esos ejemplos pueden ser concisos o deben ser extensos.
@yo porque tú lo haces bien desde el principio. Hexagonal no deja de ser usar interfaces e implementaciones para desacoplar las cosas y poder testear tu aplicación por componentes separados.
@kastwey no creas. Soy un perro y hago muchas cosas a saco. E incluso a menudo con buenas intenciones acabo empantanado.
Entonces, ¿eres un poco de la opinión que hexagonal es más bien sentido común? Eso es lo que me parece, pero me siento "cuñado" porque eso es el típico análisis simplista.
Tengo pendiente encontrar buenas explicaciones sobre hexagonal y DDD.
(Hoy como con un colega que está en una empresa practicante. A ver qué me explica.)
@yo Simplificando, sí. Al final los ports son las interfaces en lenguajes typados, y los adapters las implementaciones. Si estás acostumbrado a desacoplar componentes y a utilizar inyección de dependencias para pasar las implementaciones entre componentes (el configurador), estás aplicando hexagonal, porque el patrón no te exige una estructura de carpetas concreta. Lo que sí te sugiere son nomenclaturas para los puertos basadas en acciones, pero vamos, que eso es lo de menos.
Si usas DDD, y te montas tus servicios de aplicación, tus entidades de dominio, tus repositorios para infraestructura, tus interfaces para los servicios, ETC... al final es hexagonal también, tal y como yo lo entiendo.