¿Cómo aplican las empresas reales una arquitectura limpia en producción? Aquí encontrarás dos casos prácticos, uno de Netflix y otro de la startup Makerwatch, que muestran cómo esta arquitectura protege la lógica de negocio, facilita los cambios y crea mejores hábitos de equipo.

¿Cómo implementó Netflix una arquitectura hexagonal?

En 2020, Netflix documentó un sistema relacionado con su proceso creativo de producciones originales que necesitaba agregar datos de múltiples fuentes. Para resolverlo definieron una arquitectura hexagonal con tres elementos centrales en el dominio: entidades, repositorios e interactors [1:00].

¿Qué son los interactors en una arquitectura limpia?

Los interactors son otra forma de referirse a los casos de uso, es decir, el lugar donde viven las reglas de negocio. Netflix los ubicó en el core de la aplicación junto con las entidades y los repositorios, dándole a estos últimos un protagonismo que no siempre aparece tan explícito en arquitecturas de referencia clásicas.

En la capa externa, Netflix organizó dos grandes categorías:

• Fuentes de datos, desde donde se extrae la información.
• Capa de transporte, que actúa como actores primarios para llevar información al sistema.

Dentro de la capa de transporte usaron HTTP (probablemente vía API REST) y SQS, el sistema de colas de Amazon donde un mensaje se deposita en un lugar específico para que llegue luego a su destino [2:30]. Además sumaron una base de datos y una API en gRPC.

¿Qué es SQS? Es un sistema de colas de Amazon en el que pones un mensaje en un lugar específico y ese lugar se encarga de entregarlo a la otra parte del sistema.

¿Por qué Netflix migró su API en pocas horas?

Netflix tenía un monolito enorme con código muy acoplado al que se integraban a través de un JSON API. Cuando esa aplicación empezó a fallar por problemas de escalabilidad y mantenimiento, hicieron el cambio a un GraphQL API en cuestión de horas, sin afectar absolutamente nada [4:30].

¿La clave? Los repositorios. La aplicación solo conocía interfaces, mientras que los detalles de implementación estaban completamente ocultos. Algo similar ocurrió cuando necesitaron una integración personalizada para traer un volumen mucho mayor de datos en bloque: hicieron toda la implementación en la capa de infraestructura y fue invisible para el resto de la aplicación. Estos son ejemplos puros del principio abierto/cerrado en acción.

¿Cómo aplica Makerwatch arquitectura limpia en una startup?

Makerwatch es una startup de marketing de influenciadores que contrata cientos de creadores de contenido, principalmente en YouTube, y los conecta con marcas que quieren patrocinar sus videos. Como es una operación a escala, la tecnología es crucial para encontrarlos, negociar y gestionar el resto del proceso [6:30].

No llegaron a la arquitectura limpia por moda. Empezaron con una arquitectura de tres capas y, a medida que sumaban integraciones de terceros para automatizar procesos manuales, esa estructura se quedó corta. No era claro dónde colocar cada nueva pieza.

¿Cómo evolucionó la estructura del proyecto?

Para un nuevo desarrollo arrancaron con servicios, entidades e infraestructura, pero con un detalle interesante: no comenzaron por la capa de entidades en el centro. Iniciaron solo con los servicios y, cuando aparecieron problemas de mantenimiento, nació la capa de entidades [8:00]. Recién después incorporaron la infraestructura con elementos muy específicos a su negocio:

• Integraciones con redes sociales para corroborar publicaciones y patrocinios.
• Mensajería con Slack, ya que son un equipo remoto.
• APIs REST y conexiones con los distintos servicios de su plataforma.

Todo esto está construido en Python, lo cual demuestra que la arquitectura limpia se aplica a cualquier lenguaje de programación. Aunque las implementaciones más comunes aparecen en Java o C#, también funciona en TypeScript, JavaScript o el lenguaje que prefieras. La clave está en la estructura y el manejo correcto de dependencias.

La estructura que siguen hoy combina una capa de dominio, una capa de infraestructura y, separadas, las pruebas unitarias y de integración.

¿Sirve la arquitectura limpia solo para lenguajes tipados? No. Funciona en cualquier lenguaje, incluido Python, JavaScript o TypeScript. Lo que importa es la organización de las dependencias, no la sintaxis.

¿Qué beneficios reales aporta una arquitectura limpia?

El equipo de Makerwatch identifica tres ganancias concretas tras adoptar este enfoque [10:30].

• Proteger la lógica de negocio: cuando aparecen muchas integraciones, la lógica tiende a acoplarse a ellas. Separarlas permite cambiar herramientas sin tocar el corazón del sistema.
• Iterar rápido: cambiar integraciones, eliminar aplicaciones y traer otras nuevas se vuelve un movimiento sencillo y de bajo riesgo.
• Probar más fácil la lógica: tener integraciones aisladas permite usar objetos de prueba y verificar la lógica con agilidad.

Hay un cuarto beneficio del que poco se habla: una buena arquitectura crea hábitos sanos en el equipo. Cuando todos saben exactamente dónde va cada pieza del código, las revisiones son más rápidas y los desarrolladores juniors reducen su carga mental. Ya no tienen que adivinar dónde poner una integración nueva ni rehacer trabajo después de una revisión.

¿Has aplicado arquitectura limpia en algún proyecto propio? Cuéntame en los comentarios qué dependencias inestables decidiste aislar primero.