🍐🍎 Arquitectura Hexagonal explicada con peras y manzanas

Introducción

Imagina que tienes una aplicación que cocina peras y manzanas. Tienes la receta (la lógica de negocio) y diferentes formas de cocinarla: en horno, en microondas, o incluso en una app móvil. Pero… ¿qué pasa si cambias la forma de cocinar? ¿Tendrías que cambiar toda la receta? La arquitectura hexagonal (también llamada Ports and Adapters) nació para resolver exactamente eso.

1. El problema de las capas tradicionales

En las arquitecturas tradicionales (por ejemplo, MVC clásico), la aplicación suele estar fuertemente acoplada a frameworks, bases de datos o controladores HTTP. Por ejemplo: Si cambias tu base de datos de MySQL a MongoDB, debes modificar código en varias partes. Si agregas una nueva API REST o una interfaz gráfica, debes tocar tu capa de negocio. Esto genera dependencias cruzadas y hace que cada cambio técnico afecte la lógica central.

2. La idea central de la arquitectura hexagonal

En una arquitectura hexagonal, la lógica de negocio vive en el centro (como el corazón de la aplicación). Todo lo que la rodea (base de datos, API, mensajería, interfaz) se conecta mediante puertos (ports) y adaptadores (adapters).

En palabras simples:

La lógica no sabe si los datos vienen de una base, de una API o de un archivo JSON. Solo espera que alguien le entregue los datos con el formato correcto. Así logramos que la receta (el negocio) no dependa del tipo de cocina (la infraestructura).

3. Ejemplo con peras y manzanas

Sin arquitectura hexagonal:

public class FrutaService { 

private final FrutaRepository repository; 

public FrutaService() { 

this.repository = new FrutaRepository(); 

// ❌ Acoplamiento directo 

} 

public double calcularTotal() { 

List<Fruta> frutas = repository.obtenerFrutas(); 

return frutas.stream().mapToDouble(Fruta::getPrecio).sum(); 

} 

}

Aquí, FrutaService depende directamente del repositorio. Si mañana cambias de base de datos, tienes que modificar el servicio.

Con arquitectura hexagonal:

public interface FrutaRepository { 

List<Fruta> obtenerFrutas(); 

}

public class FrutaService { 

private final FrutaRepository repository; 

public FrutaService(FrutaRepository repository) { 

this.repository = repository; 

} 

public double calcularTotal() { 

return repository.obtenerFrutas() .stream() .mapToDouble(Fruta::getPrecio) .sum(); 

} 

}

@Repository 

public class FrutaRepositoryDB implements FrutaRepository { 

// Lógica para obtener frutas desde una BD 

} 

public class FrutaRepositoryArchivo implements FrutaRepository { 

// Lógica para obtener frutas desde un archivo JSON 

}

Resultado: tu servicio nunca cambia, aunque cambie la fuente de datos.

4. Beneficios clave

1. 🔹 Desacoplamiento total entre negocio y tecnología.
2. 🔹 Facilidad de pruebas unitarias: puedes usar mocks sin conectarte a BD.
3. 🔹 Sustituibilidad: cambia un adaptador por otro sin tocar la lógica.
4. 🔹 Escalabilidad: agrega nuevas entradas (API, CLI, eventos) sin romper nada.

5. Conclusión

En resumen, la arquitectura hexagonal es como una cocina modular: puedes usar horno, microondas o sartén… pero la receta sigue siendo la misma. El negocio no se entera del cambio, solo sabe cocinar peras y manzanas. No se trata solo de dibujar un hexágono bonito, sino de proteger tu lógica de negocio del caos tecnológico.

¿Qué opinas?

¿Ya aplicaste este patrón en tus proyectos? Déjame tu experiencia en los comentarios o sígueme en LinkedIn para más artículos de desarrollo y arquitectura.

Modos de Encriptación con Cloudflare

El tema que abordaré acontinuación es considerando la forma y los conceptos que implementa Cloudflare.
Los modos de encriptación y los tipos de certificados SSL/TLS no son exclusivos de Cloudflare. Sin embargo, la forma en que Cloudflare implementa estos modos y los términos específicos que usa pueden ser particulares de su plataforma.

Modos de Encriptación (SSL/TLS)

La idea de diferentes modos de encriptación, como "Full" o "Full (Strict)", es un concepto general en la seguridad web. Se basa en cómo una conexión segura es establecida entre un cliente (como un navegador) y un servidor de origen. Cloudflare simplemente facilita la gestión de estos modos dentro de su plataforma.

En general, los modos SSL/TLS incluyen:

• Flexible (propio de Cloudflare): La conexión entre el cliente y Cloudflare es segura, pero la conexión entre Cloudflare y el servidor de origen no usa SSL.
  
  
  
  
  
  
• Full: Usa SSL entre Cloudflare y el origen, pero sin validar el certificado del origen.
  
  
  
  
  
  
• Full (Strict): Requiere SSL entre Cloudflare y el origen, y el certificado del origen debe ser válido y confiable.
  
  
  

  
  
  
  
  
  

Otros proveedores de CDN y seguridad web pueden ofrecer configuraciones similares, aunque con nombres o implementaciones distintas.

Tipos de Certificados

Los certificados SSL/TLS mencionados (Universal, Avanzado, Personalizado, Keyless) son categorías que Cloudflare usa, pero la idea general detrás de estos tipos de certificados es común en la industria:

• Certificados gratuitos (como los de Let’s Encrypt o los que Cloudflare proporciona automáticamente).
• Certificados avanzados o gestionados (más configurables, pero aún automatizados).
• Certificados personalizados (cuando el cliente usa su propio certificado).
• Certificados sin clave (Keyless SSL) (para permitir la protección sin exponer claves privadas).

Otros proveedores como AWS CloudFront, Fastly o Akamai también ofrecen opciones de administración de certificados SSL/TLS con características similares.

En resumen, aunque los términos específicos pueden ser exclusivos de Cloudflare, los conceptos detrás de la encriptación SSL/TLS y los tipos de certificados son estándares de la industria.

Keyless SSL

Por motivos regulatorios, muchas organizaciones no pueden compartir sus claves privadas. Con Keyless SSL  (SSL sin llave), estas organizaciones aún pueden usar TLS y aprovechar la nube manteniendo la clave segura.

SSL sin clave se basa en el hecho de que solo hay un momento en el que se utiliza la clave privada durante el protocolo de enlace TLS, que ocurre al comienzo de una sesión de comunicación TLS. SSL sin llave funciona dividiendo los pasos del protocolo de enlace TLS. Un proveedor de nube que ofrece SSL sin clave mueve la parte de la clave privada del proceso a otro servidor, generalmente un servidor que el cliente mantiene en las instalaciones. En lugar de utilizar la clave privada directamente para generar claves de sesión, el proveedor de la nube obtiene las claves de sesión de la empresa a través de un canal seguro y utiliza esas claves para mantener el cifrado. Por tanto, se sigue utilizando una clave privada, pero no se comparte con nadie ajeno a la empresa.

Keyless SSL sólo es "sin llave" desde el punto de vista del proveedor de la nube: nunca ven la clave privada de su cliente, pero el cliente aún la tiene y la usa. Mientras tanto, la clave pública todavía se usa en el lado del cliente como de costumbre.

Session Keys

Una clave de sesión es cualquier clave de cifrado utilizada para cifrar simétricamente una sola sesión de comunicación. Una sesión se lleva a cabo a través de una red y comienza cuando dos dispositivos se reconocen mutuamente y abren una conexión virtual. Finaliza cuando los dos dispositivos han obtenido la información que necesitan entre sí y envían mensajes "terminados", finalizando la conexión.

Encritación

Recientemente estoy cursando un training asignado por la compañía. Y quiero compartir breves resumen de algunos tópicos. En esta ocasión hablaré brevemente sobre la Encriptación.

Que es la Encriptación?

Se puede definir como el cifrado o codificación de datos para que sólo las partes autorizadas puedan entender la información. El cifrado es el proceso de convertir texto sin formato legible por humanos en texto incomprensible, también conocido como texto cifrado.
El cifrado requiere el uso de una clave criptográfica: un conjunto de valores matemáticos que tanto el remitente como el destinatario acuerdan.

2 tipos de Encriptación

Los dos tipos principales de cifrado son el cifrado simétrico y el cifrado asimétrico. El cifrado asimétrico también se conoce como cifrado de clave pública.

Cifrado simétrico

En el cifrado simétrico, solo hay una clave y todas las partes que se comunican utilizan la misma clave (secreta) tanto para el cifrado como para el descifrado.

Cifrado asimétrico

En el cifrado asimétrico o de clave pública, hay dos claves: una clave se utiliza para el cifrado y una clave diferente para el descifrado. La clave de descifrado se mantiene privada, mientras que la clave de cifrado se comparte públicamente, para que cualquiera pueda usarla. El cifrado asimétrico es una tecnología fundamental para TLS.

¿Qué es una clave criptográfica?

En criptografía, una clave es una cadena de caracteres utilizada dentro de un algoritmo de cifrado para alterar datos para que parezcan aleatorios. Al igual que una clave física, bloquea (cifra) los datos para que sólo alguien con la clave correcta pueda desbloquearlos (descifrarlos). 

SSL/TLS requiere el uso de lo que se llama una clave pública y una clave privada, y en el caso de una empresa que utiliza el protocolo para proteger el tráfico hacia y desde su sitio web (consulte HTTPS), la clave privada normalmente permanece en posesión de la empresa. Pero cuando una empresa pasa a la nube y un proveedor proporciona cifrado TLS, el proveedor tiene la clave privada.

¿Quién inventó los patrones de diseño?

Continuando con la saga de Patrones de diseño, hoy quiero contextualizar un poco y conversar del origen. Como había mencionado en post anterior, los patrones son soluciones a problemas habituales en el coding, y, cuando una solución se repite una y otra vez, este pasa a ser bautizado con un nombre y explicar su solución a detalle. De esta manera nace un patrón.

De acuerdo a la fuente estudiada,  en 1977 surge un libro llamado "A Pattern Language"/"El lenguaje de patrones". Su contenido es orientada a la arquitectura urbana escrito por Christopher Alexander.

Básicamente, contempla una seria de patrones para describir por ejemplo: alto y tipos de ventanas, niveles de un edicto, zonas verdes de un emplazamiento, etc.

En 1995, esta idea fue traslada a las diversas problemas y soluciones que se pueden tener a la hora de codificar un software. Los autores de esta genial idea son Eric Gamma, John Vlissides, Ralph Johnson y Richard Helm en su publicación "Patrones de diseño".

Este libro presenta 23 patrones que resuelven problemas de diseño orientado a objetos. Desde entonces, se han descubierto numeroso patrones de diseño.