@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.
