Las arquitecturas de software como la hexagonal, cebolla o limpia no son recetas rígidas: son puntos de partida que necesitas adaptar a tu contexto. Aquí entenderás cómo personalizar capas, respetar la regla de la dependencia y manejar la convención de nombres que usaremos en el curso.

¿Por qué debes adaptar la arquitectura a tu contexto?

Ninguna arquitectura es universal. Lo que funciona en un proyecto puede no encajar en otro, y esa es justamente la razón por la que debes tomarlas como base flexible.

En la arquitectura hexagonal, por ejemplo, el número de puertos y adaptadores no tiene que ser seis. Puede crecer o reducirse según lo que tu sistema necesite comunicar con el exterior. Lo mismo pasa con las capas del dominio: puedes tener una sola, dos o incluso más, y en la capa externa aplica la misma lógica.

Me gusta mucho la definición de Ralph Johnson, uno de los autores del libro clásico sobre patrones de diseño: la arquitectura es acerca de las cosas importantes, sean las que estas sean. Traducción práctica: lo que es crítico en tu negocio debería estar reflejado como ciudadano de primer nivel en tu arquitectura.

En MakerWatch, por ejemplo, las redes sociales son el corazón del negocio. Por eso, cuando trabajamos con una arquitectura limpia, ese elemento quedó reflejado como pieza central. En tu caso, identifica qué es lo que mueve tu negocio y dale ese mismo trato.

¿Existe una arquitectura de software perfecta? No. La arquitectura correcta depende del contexto, del negocio y de lo que sea importante para tu sistema. Lo que funciona en una app social puede ser excesivo en una herramienta interna.

¿Qué regla nunca puedes romper en una arquitectura limpia?

Aquí viene la única restricción fuerte: la regla de la dependencia es sagrada. Tienes libertad para decidir cuántas capas usas en el dominio o en la capa externa, pero el sentido de las dependencias siempre apunta hacia adentro.

Esa regla es la que te permite controlar el acoplamiento y, sobre todo, proteger la lógica de negocio de los detalles externos como bases de datos, frameworks o APIs. Si la rompes, pierdes la razón de ser de toda la arquitectura.

¿Por qué los nombres de arquitecturas y capas se usan de forma arbitraria?

Cuando explores código en GitHub, artículos o repositorios, vas a notar algo curioso: los nombres se intercambian todo el tiempo. Lo que en un lugar llaman arquitectura cebolla, en otro lo presentan como hexagonal, y viceversa. Pasa igual con las capas.

No te obsesiones con el nombre exacto. Lo que importa es entender qué es una arquitectura limpia, cómo se organiza y por qué fluyen así las dependencias. Por eso en el curso nos apegamos a las definiciones originales de los autores, evitando interpretaciones que generen ambigüedad.

¿Arquitectura hexagonal y arquitectura cebolla son lo mismo? No exactamente, aunque comparten principios como la regla de la dependencia y la separación entre dominio y capa externa. Los nombres se usan indistintamente en la práctica.

¿Cuál es la convención de capas que usaremos en el curso?

Para evitar confusiones con la variedad de términos que circulan, fijamos una convención clara. El elemento central siempre será el dominio, y todo lo que lo rodea lo llamaremos la capa externa.

El dominio, además, lo separamos en dos capas internas:

• Modelo de dominio: la parte más central, donde viven las entidades del negocio.
• Capa de aplicación: orquesta los casos de uso y conecta el modelo con el exterior.
• Capa externa: contiene adaptadores, infraestructura y todo lo que se comunica con el mundo.

Esta terminología está alineada con varias arquitecturas de referencia y nos dará un lenguaje común para las próximas unidades, donde profundizaremos en el dominio.

Me encantaría leer en los comentarios cuáles son los principales aprendizajes que te llevas de este módulo y cómo piensas adaptar estas ideas a tu propio proyecto.