Codigo limpio y refactorización
Clean Architecture, propuesta por Robert C. Martin, organiza el código en capas concéntricas. Las capas internas son independientes de las externas, promoviendo la separación de intereses.
Principios Clave de la Clean Architecture
-
Independencia de Frameworks:
- Los frameworks son herramientas que se usan en los bordes del sistema, no el núcleo.
- El sistema no debe depender de un framework en particular para funcionar.
-
Testabilidad:
- Las reglas de negocio y casos de uso se pueden probar de forma aislada, sin necesidad de involucrar bases de datos, interfaces gráficas, o frameworks.
-
Independencia de Interfaces de Usuario:
- La lógica de negocio es independiente de la interfaz (web, móvil, CLI).
-
Independencia de Bases de Datos:
- Cambiar de base de datos o tecnología de almacenamiento no afecta la lógica del sistema.
-
Separación de Preocupaciones:
- Cada capa tiene responsabilidades específicas, lo que reduce el acoplamiento y mejora la cohesión.
Estructura de la Clean Architecture
La Clean Architecture se organiza en capas concéntricas, donde cada capa tiene un propósito específico y depende solo de las capas más internas. Estas capas son:
-
Entidades (Entities):
- Representan los conceptos centrales del negocio (objetos de dominio).
- Contienen las reglas de negocio más generales y reutilizables.
- No dependen de otras capas.
-
Casos de Uso (Use Cases):
- Contienen la lógica específica de las acciones que puede realizar el sistema.
- Orquestan entidades para cumplir con los requisitos funcionales.
-
Adaptadores de Interfaz (Interface Adapters):
- Transforman datos entre los casos de uso y las interfaces externas (APIs, bases de datos, UI).
- Incluyen controladores, presentadores, y gateways.
-
Frameworks y Controladores Externos (Frameworks & Drivers):
- Son las herramientas externas que permiten que el sistema interactúe con el mundo (bases de datos, interfaces web, etc.).
- Están en la capa más externa y no afectan la lógica central.
Diagrama de la Clean Architecture
1+------------------------------------------------+ 2| Frameworks y Controladores | 3| (Frameworks & Drivers) | 4+------------------------------------------------+ 5| Adaptadores de Interfaz (UI) | 6+------------------------------------------------+ 7| Casos de Uso (Use Cases) | 8+------------------------------------------------+ 9| Entidades (Entities) | 10+------------------------------------------------+
Regla de Dependencia
La regla de dependencia establece que:
- Las dependencias siempre deben apuntar hacia el núcleo del sistema.
- Las capas externas pueden depender de las internas, pero nunca al revés.
Esto garantiza que los detalles de implementación (bases de datos, frameworks, etc.) puedan cambiar sin afectar la lógica del negocio.
Ventajas de la Clean Architecture
-
Mantenibilidad: Las responsabilidades claras y las capas independientes facilitan el mantenimiento y los cambios en el sistema.
-
Escalabilidad: Permite agregar nuevas funcionalidades sin afectar otras partes del sistema.
-
Testabilidad: Las reglas de negocio se pueden probar sin necesidad de ejecutar todo el sistema.
-
Flexibilidad: Facilita el cambio de tecnologías (por ejemplo, cambiar de base de datos o frontend).
Ejemplo Simplificado
Dominio: Sistema de Reservas de Hotel
- Entidad: Cliente (nombre, email, etc.).
- Caso de Uso: Crear reserva (asegurarse de que el cliente exista y de que haya disponibilidad).
- Adaptadores: Un API que recibe los datos de la reserva y un repositorio para interactuar con la base de datos.
- Framework: Express.js para el servidor y MongoDB para la base de datos.
Estructura típica
src/
├── domain/ # Entidades y lógica de dominio
│ └── Cliente.ts
├── usecases/ # Casos de uso
│ └── CrearReserva.ts
├── adapters/ # Adaptadores de interfaz
│ ├── controllers/
│ │ └── ReservaController.ts
│ ├── repositories/
│ │ └── ReservaRepository.ts
├── infrastructure/ # Frameworks y herramientas externas
│ ├── express/
│ │ └── routes.ts
│ ├── database/
│ │ └── MongoConnection.ts
└── app.ts # Configuración principal