Qué hace limpia a una arquitectura de software

La arquitectura limpia es un enfoque de diseño de software que aplica de forma consistente paradigmas, principios, modularización y separación entre contratos e implementaciones. Si trabajas como desarrollador o arquitecto de software, entender este concepto te ayuda a construir sistemas más mantenibles, testeables y desacoplados de detalles externos.

Ahora bien, no existe una arquitectura perfecta. El grado de limpieza siempre es relativo y depende de las decisiones de diseño, las restricciones del proyecto y los trade-offs que aceptes en el camino.

¿Cómo saber si tu arquitectura es realmente limpia?

Hay criterios bastante simples para evaluar qué tan limpia es tu arquitectura. No se trata de una calificación absoluta, sino de revisar señales concretas en tu código.

• Independencia del framework: tus contratos e implementaciones deberían funcionar sin depender de los productos de un framework específico.
• Reglas de negocio testeables: puedes probar la lógica de negocio sin necesitar nada más.
• Independencia de la interfaz de usuario: las reglas de negocio no deben necesitar la UI para ser verificadas.
• Independencia de la persistencia: la base de datos es solo un detalle, no el centro del sistema.
• Independencia de sistemas externos: dependes de protocolos y estándares, no de SDKs o productos puntuales.

¿Qué tan limpia debe ser una arquitectura? Lo suficiente para que puedas testear tus reglas de negocio sin frameworks, sin base de datos y sin interfaz de usuario. Más allá de eso, todo es trade-off.

¿Por qué la base de datos es solo un detalle?

Solemos pensar en las bases de datos como un componente vital de cada sistema. Y lo son operativamente. Pero desde el punto de vista arquitectónico, la base de datos es un detalle de implementación.

Deberías poder probar tus casos de uso y tus reglas de negocio sin depender de un motor específico. Si tus tests de reglas de negocio usan directamente resultados de la base de datos, ahí tienes una señal de que la arquitectura no está tan limpia como podría estarlo.

¿Cuáles son las capas de una arquitectura limpia?

En su forma canónica, la arquitectura limpia se representa como cuatro círculos concéntricos, donde cada capa tiene una responsabilidad clara.

• Entidades del modelo de dominio: el núcleo, representado en amarillo en el centro.
• Casos de uso: procesos de negocio o workflows que usan únicamente las entidades.
• Adaptadores y transformadores de datos: reciben información externa y la vuelven utilizable para los casos de uso.
• Detalles de implementación: el círculo más externo, en azul, donde viven la base de datos y la interfaz de usuario.

La regla de oro está en cómo se leen las dependencias del código: de afuera hacia adentro. Las capas externas dependen de las internas, pero nunca al revés. Esa direccionalidad es lo que mantiene tu núcleo de negocio protegido.

¿Qué son los DTO y por qué deben ser anémicos?

Para mover información entre capas usas Data Transfer Objects, conocidos como DTO. Estos objetos deben ser anémicos, es decir, contener solo estado y ningún comportamiento.

¿Qué es una clase anémica? Es una clase que solo transporta datos, sin validaciones ni lógica de negocio. Si empiezas a meterle reglas, estás cayendo en un anti patrón.

Cuando un DTO empieza a validar datos o ejecutar lógica de negocio, deja de ser un transportador y se convierte en un punto de acoplamiento difícil de mantener.

¿Cuáles son los anti patrones más comunes?

Reconocer los anti patrones es tan importante como aplicar buenas prácticas. Aquí es donde muchas arquitecturas pierden limpieza sin que el equipo lo note.

• Capa de presentación con lógica de negocio: la UI termina ejecutando reglas que deberían vivir en los casos de uso.
• Uso directo de modelos de datos desde capas externas para modificar reglas internas.
• Tests de reglas de negocio que dependen de resultados reales de la base de datos.
• DTOs que validan o ejecutan lógica en lugar de solo transportar datos.

Estos síntomas indican fugas de responsabilidades entre capas. Y cuando las responsabilidades se mezclan, el sistema se vuelve frágil.

¿Puedes mezclar estilos arquitectónicos?

Sí, y es perfectamente válido. A veces necesitas agregar nuevos círculos conceptuales o combinar estilos según el dominio del problema. Lo importante es mantener las dependencias entre capas claramente distinguibles y verificables.

Usa transferencia de datos explícita, con contratos que dejen claro que entre capas solo viajan datos, nunca lógica implícita. Esa disciplina es la que sostiene la limpieza a lo largo del tiempo.

La arquitectura limpia no es una receta. Los patrones de software sí lo son, y son la herramienta concreta que te permite materializar estos principios en código. ¿Qué anti patrón has encontrado más seguido en tus proyectos? Cuéntalo en los comentarios.