Arquitectura Limpia

Las dependencias del código fuente solo pueden apuntar hacia adentro — nada en un círculo interior puede saber nada de un círculo exterior, manteniendo el núcleo de negocio estable y reutilizable.

La base de datos, la capa web y los frameworks son mecanismos de entrega — un buen arquitecto postpone estas decisiones y mantiene las reglas de negocio independientes para evitar un matrimonio tecnológico costoso.

Atar la lógica de negocio a dispositivos de E/S específicos es un error costoso — la arquitectura debe ser agnóstica a si los datos vienen de tarjetas, terminales, archivos o APIs.

Las dependencias del código fuente deben apuntar solo a abstracciones — las Fábricas Abstractas crean la frontera arquitectónica entre el código concreto volátil y la política estable.

Con interfaces, los arquitectos hacen que las dependencias del código apunten contra el flujo de control, dando control absoluto sobre el acoplamiento.

La arquitectura es importante pero rara vez urgente. Los desarrolladores deben defender la buena estructura frente a la presión del negocio.

Las Entidades contienen reglas de negocio críticas que existen en toda la empresa; los Casos de Uso orquestan flujos específicos de la aplicación y están aislados de los cambios de UI y base de datos.

La programación funcional disciplina la asignación. La inmutabilidad elimina condiciones de carrera, deadlocks y problemas de actualización concurrente.

El diseño y la arquitectura son lo mismo: su verdadera medida es el esfuerzo necesario para satisfacer al cliente minimizando el costo a largo plazo.

Separa el comportamiento difícil de probar del fácil de probar — el Presentador prepara toda la lógica en un ViewModel testeable; la Vista es un humble object que solo muestra lo que recibe.

La mejor arquitectura fracasa sin un uso disciplinado de los modificadores de acceso — el compilador es tu aliado más fuerte para hacer cumplir las reglas de Clean Architecture en todo el equipo.

Los Adaptadores de Interfaz convierten datos entre el formato que entienden los casos de uso y el que necesitan los sistemas externos — los límites siempre se cruzan con DTOs simples, nunca con entidades crudas o filas de BD.

No dependas de cosas que no usas — las interfaces gordas fuerzan recompilaciones innecesarias y acoplamiento a fallos en código no relacionado.

Un buen arquitecto maximiza el número de decisiones aún no tomadas — separando la política de los detalles para que las elecciones de base de datos y framework puedan postponerse hasta saber más.

Separa lo que cambia a diferentes ritmos — UI, reglas de negocio de aplicación, reglas de dominio y base de datos cambian por razones distintas y deben ser capas horizontales.

Los subtipos deben ser sustituibles por sus tipos base — las violaciones del LSP fuerzan lógica costosa de casos especiales en el diseño.

Main es el componente más sucio y de más bajo nivel — el punto de entrada que conecta todas las dependencias y entrega el control a la arquitectura limpia que está sobre él.

Los componentes deben equilibrar Abstracción (A) e Inestabilidad (I) — la Zona de Dolor (estable+concreto) y la Zona de Inutilidad (abstracto+inestable) son antipatrones a evitar.

Los artefactos de software deben estar abiertos para extensión pero cerrados para modificación — añadir nuevo comportamiento debe añadir código, no cambiarlo.

La POO no inventó la encapsulación — C tenía encapsulación perfecta antes de que C++ y Java la debilitaran con los archivos de cabecera.

Agrupa toda la responsabilidad de un límite de funcionalidad limpio en un paquete — la persistencia interna y la lógica permanecen privadas, el compilador hace cumplir lo que es visible para el resto del sistema.

Agrupa el código por funcionalidad de dominio — los paquetes de nivel superior revelan el negocio, cada funcionalidad está co-ubicada y la búsqueda mejora drásticamente a medida que el sistema crece.

La organización de código más simple agrupa por capa técnica (web/servicio/repositorio) — fácil de comenzar pero oculta la intención del negocio y permite atajos peligrosos entre capas.

Los límites arquitectónicos completos son costosos — los límites parciales usando patrones Strategy o Facade preservan puntos de separación futura sin el costo total inicial.

El antipatrón periférico ocurre cuando el código de infraestructura habla directamente con otro código de infraestructura, saltándose el dominio — como el anillo de París, el tráfico fluye alrededor de la ciudad en lugar de a través de ella.

El nivel es la distancia a las entradas y salidas — cuanto más lejos de la E/S, mayor el nivel. Las dependencias del código fuente siempre deben apuntar hacia las políticas de más alto nivel y más estables.

El polimorfismo permite tratar dependencias externas como plugins intercambiables, haciendo que la lógica central sea independiente del dispositivo.

El interior es el dominio; el exterior es la infraestructura — el exterior depende del interior, los puertos hablan el lenguaje del dominio y los adaptadores traducen entre el dominio y los sistemas externos.

Las pruebas no demuestran corrección, demuestran ausencia de incorrecciones conocidas. La buena arquitectura produce módulos fácilmente falsificables.

Los tres paradigmas imponen disciplina eliminando capacidades, no añadiéndolas.

REP agrupa las clases que se liberan juntas; CCP agrupa las que cambian juntas por la misma razón — ambas reflejan el SRP a escala de componente.

Un componente debe ser tan abstracto como estable — los componentes más estables deben ser interfaces puras para poder extenderse sin modificarse.

La estructura de carpetas debe revelar qué hace el sistema, no qué framework usa — un sistema de salud grita 'Salud', no 'Rails'.

Depende en la dirección de la estabilidad — un componente volátil nunca debe ser dependido por uno estable, o esa estabilidad queda comprometida permanentemente.

Los servicios no definen la arquitectura — un servicio con estructura interna pobre es solo una llamada de función costosa. Los límites arquitectónicos reales pueden existir dentro de un monolito o entre servicios.

Un módulo debe ser responsable ante un solo actor, evitando que los cambios de un departamento rompan accidentalmente otro.

Dijkstra demostró que el goto sin restricciones es perjudicial. La secuencia, selección e iteración son suficientes para módulos correctos y descomponibles.

Los tests son el círculo arquitectónico más externo — los tests frágiles acoplados a detalles de implementación hacen el sistema rígido; una API de Test desacopla la estructura de tests de la estructura de la aplicación.

El software tiene valor por su comportamiento y su estructura. Un sistema rígido dejará de funcionar cuando los requisitos cambien.

Los casos de uso son cortes verticales que atraviesan todas las capas — desacoplarlos permite que cada uno evolucione independientemente sin que los cambios de un caso de uso colisionen con los de otro.