Curso de Arquitectura Limpia para Equipos de Desarrollo en Empresas

Revisar el principio de responsabilidad única desde una perspectiva práctica y no dogmática.

Aplicar abierto/cerrado para extender comportamiento sin romper código estable.

Entender sustitución de Liskov y su relación con herencia, contratos y polimorfismo seguro.

Aplicar segregación de interfaces para evitar dependencias infladas y módulos obligados a conocer demasiado.

Usar inversión de dependencias para que el negocio no dependa de detalles técnicos.

Diferenciar cohesión funcional, lógica, temporal, accidental y de dominio.

Identificar acoplamiento fuerte, acoplamiento temporal, acoplamiento estructural y acoplamiento a frameworks.

Diseñar código pensando en cambios previsibles, no en todas las posibilidades imaginables.

Detectar abstracciones prematuras que aumentan complejidad sin aportar flexibilidad real.

Usar SOLID como criterio de conversación técnica, revisión de código y evolución arquitectónica.

Comprender la regla de dependencia: las capas internas no deben depender de detalles externos.

Diferenciar dominio, aplicación, infraestructura, presentación, persistencia, integración y configuración.

Identificar qué código representa reglas de negocio y qué código representa mecanismos técnicos.

Evitar que entidades de dominio dependan de ORMs, frameworks, controladores, colas o bases de datos.

Separar casos de uso de controladores, endpoints, comandos, jobs, workers o interfaces gráficas.

Diseñar límites claros entre lo que el sistema hace y cómo lo ejecuta técnicamente.

Controlar dependencias mediante interfaces, puertos, contratos, adaptadores e inversión de dependencias.

Evitar que la infraestructura contamine la lógica de aplicación con detalles de librerías externas.

Revisar errores habituales: inyectar repositorios técnicos en entidades, usar modelos ORM como dominio o mezclar validaciones de UI con reglas de negocio.

Definir una estructura base de carpetas, paquetes, proyectos o módulos coherente con la dirección de dependencias.

Comprender qué es una entidad de dominio y cuándo tiene identidad propia.

Diferenciar entidad, objeto de valor, agregado, DTO, modelo de persistencia y modelo de vista.

Diseñar objetos de valor para representar conceptos como dinero, email, rango, fecha, porcentaje, estado o identificador.

Encapsular invariantes para impedir estados inválidos dentro del dominio.

Evitar modelos anémicos donde toda la lógica vive fuera de los objetos principales.

Diseñar métodos de dominio con lenguaje cercano al negocio.

Gestionar validaciones de dominio frente a validaciones de entrada, formato o transporte.

Separar comportamiento de negocio de operaciones técnicas como guardar, serializar o mapear.

Diseñar entidades persistibles sin quedar atrapadas por el ORM.

Crear un modelo de dominio que sea entendible por perfiles técnicos y de negocio.

Comprender el papel de los casos de uso como núcleo de la lógica de aplicación.

Diferenciar caso de uso, servicio de dominio, servicio de aplicación, comando, handler, controlador y endpoint.

Diseñar casos de uso con una intención clara y un nombre orientado a negocio.

Orquestar entidades, repositorios, políticas, validadores, eventos y servicios externos sin mezclar responsabilidades.

Definir entradas y salidas de casos de uso mediante comandos, queries, DTOs o modelos específicos.

Mantener casos de uso independientes de HTTP, CLI, UI, colas, cron jobs o frameworks.

Gestionar transacciones, autorización, validación y publicación de eventos con límites bien definidos.

Evitar servicios de aplicación gigantes que concentran demasiadas reglas y ramificaciones.

Separar operaciones de escritura, lectura, consulta, proceso batch y tareas asíncronas.

Diseñar casos de uso testeables sin levantar servidor, base de datos o infraestructura externa.

Comprender el patrón de puertos y adaptadores como forma de proteger el núcleo de negocio.

Diferenciar puertos de entrada, puertos de salida, adaptadores primarios y adaptadores secundarios.

Diseñar adaptadores HTTP, CLI, jobs, consumidores de eventos, controladores y resolvers GraphQL.

Diseñar adaptadores para persistencia, email, pagos, almacenamiento, colas, APIs externas y servicios cloud.

Crear interfaces en la capa correcta para invertir dependencias sin duplicar abstracciones innecesarias.

Evitar interfaces creadas solo por costumbre cuando no existe variabilidad real.

Gestionar múltiples adaptadores para el mismo caso de uso: API, worker, script, prueba o interfaz interna.

Mantener adaptadores delgados que traduzcan formatos y deleguen la lógica al caso de uso.

Diseñar contratos estables entre núcleo y mundo exterior.

Aplicar arquitectura hexagonal sin convertir el proyecto en una colección de capas vacías.

Diferenciar DTO, request model, response model, domain model, persistence model, view model y event payload.

Diseñar DTOs que respondan a necesidades de frontera, no a comodidad del ORM.

Evitar exponer entidades de dominio directamente en APIs, vistas, colas o contratos externos.

Crear mappers entre capas cuando aportan protección, estabilidad y claridad.

Gestionar campos calculados, formatos, localización, normalización y serialización sin contaminar el dominio.

Separar validación sintáctica de entrada y validación semántica de negocio.

Diseñar respuestas de casos de uso para consumidores distintos sin duplicar lógica crítica.

Mantener compatibilidad de contratos externos aunque el modelo interno evolucione.

Evitar mappers excesivamente complejos que esconden reglas de negocio.

Documentar modelos de frontera para facilitar integración, testing y evolución.

Comprender el patrón repositorio como abstracción de colección de objetos o acceso a persistencia.

Diferenciar repositorio de dominio, DAO, gateway, query service y modelo ORM.

Evitar que reglas de negocio dependan de consultas SQL, anotaciones ORM o detalles de base de datos.

Diseñar repositorios con métodos alineados con necesidades de negocio y no con operaciones genéricas indiscriminadas.

Separar persistencia de escritura y modelos optimizados de lectura cuando el caso lo requiere.

Gestionar transacciones, unidad de trabajo, concurrencia, bloqueos y consistencia.

Trabajar con bases relacionales, NoSQL, almacenamiento documental, caché o servicios externos sin contaminar capas internas.

Controlar migraciones, cambios de schema y evolución del modelo de persistencia.

Evitar repositorios que devuelven estructuras técnicas incompatibles con el dominio.

Diseñar acceso a datos testeable, reemplazable y observable.

Comprender qué pruebas necesita una arquitectura limpia y qué debe comprobar cada tipo de test.

Probar entidades y objetos de valor sin infraestructura.

Probar casos de uso con dobles, fakes o adaptadores de prueba.

Probar adaptadores de infraestructura con base de datos, colas, APIs o servicios reales controlados.

Diseñar pruebas de contrato para APIs internas, eventos, integraciones y proveedores externos.

Evitar tests frágiles que dependen de detalles internos o mocks excesivos.

Definir pirámide de testing adaptada a arquitectura limpia.

Usar tests para proteger reglas de negocio, no solo endpoints felices.

Incorporar pruebas de arquitectura para evitar dependencias prohibidas entre capas.

Integrar testing en CI/CD con calidad, velocidad y trazabilidad.

Comprender qué aporta Domain-Driven Design a la Arquitectura Limpia.

Diferenciar dominio, subdominio, core domain, supporting domain y generic domain.

Crear lenguaje ubicuo entre negocio, producto y desarrollo.

Identificar bounded contexts para separar modelos que no deben mezclarse.

Evitar un único modelo global que intenta representar toda la empresa.

Diseñar agregados, entidades, objetos de valor, servicios de dominio y eventos de dominio.

Gestionar invariantes dentro de límites consistentes.

Relacionar casos de uso con procesos de negocio reales.

Diferenciar DDD táctico útil de complejidad accidental innecesaria.

Usar DDD para decidir módulos, nombres, límites, contratos y responsabilidades.

Comprender el monolito modular como alternativa potente a microservicios prematuros.

Diseñar módulos con límites claros, APIs internas, ownership y dependencias controladas.

Evitar paquetes técnicos que agrupan por controladores, servicios y repositorios sin reflejar negocio.

Organizar módulos por capacidades de negocio, contextos o vertical slices.

Identificar dependencias permitidas, dependencias prohibidas y mecanismos de integración entre módulos.

Gestionar datos compartidos, transacciones, eventos internos y consistencia.

Detectar cuándo un módulo puede extraerse a microservicio sin romper el sistema.

Evaluar microservicios por autonomía, despliegue, escala, ownership, datos y coste operativo.

Evitar distribuir una mala arquitectura monolítica en servicios más difíciles de mantener.

Diseñar una estrategia gradual de modularización y extracción cuando el negocio lo exige.

Comprender cuándo usar eventos de dominio, eventos de integración y mensajes asíncronos.

Diferenciar evento, comando, query, notificación, job y tarea programada.

Diseñar eventos como hechos de negocio, no como llamadas remotas disfrazadas.

Aplicar CQRS cuando separar lectura y escritura aporta claridad, rendimiento o escalabilidad.

Gestionar consistencia eventual, idempotencia, reintentos, duplicados y orden de eventos.

Diseñar handlers, subscribers, consumers y publishers sin acoplar módulos indebidamente.

Integrar colas, buses, brokers, outbox pattern y procesos asíncronos con arquitectura limpia.

Evitar usar eventos para ocultar dependencias mal diseñadas o procesos incomprensibles.

Documentar contratos de eventos y evolución de versiones.

Diseñar integración externa sin que APIs de terceros definan el modelo interno.

Separar autenticación, autorización, permisos, políticas de negocio y validaciones de entrada.

Definir dónde colocar reglas de seguridad según su naturaleza técnica, de aplicación o de negocio.

Evitar lógica de permisos dispersa en controladores, vistas o endpoints.

Diseñar políticas de autorización testeables y reutilizables.

Gestionar validación de input, validación de dominio, validación de estado y validación de workflow.

Incorporar auditoría, trazabilidad, logs, correlación y evidencias sin contaminar entidades.

Controlar errores, excepciones, mensajes al usuario y detalles técnicos expuestos.

Gestionar datos sensibles, secretos, cifrado, privacidad y cumplimiento desde la arquitectura.

Diseñar cross-cutting concerns mediante middlewares, decorators, interceptors, pipelines o aspectos controlados.

Evitar que seguridad, logging, caché o transacciones generen acoplamiento invisible.

Diseñar aplicaciones observables desde el inicio: logs, métricas, trazas, eventos y errores.

Diferenciar logging técnico, logging de negocio, auditoría y monitorización operativa.

Añadir correlación entre request, caso de uso, evento, job y operación externa.

Medir latencia por capa: entrada, caso de uso, persistencia, integración y respuesta.

Identificar cuellos de botella sin romper separación de responsabilidades.

Incorporar caching sin convertirlo en dependencia del dominio.

Diseñar límites para timeouts, retries, circuit breakers y tolerancia a fallos.

Preparar health checks, readiness, liveness y señales operativas.

Evitar optimizaciones prematuras que complican el diseño sin datos.

Conectar arquitectura limpia con DevOps, CI/CD, despliegue, operación y soporte.

Diagnosticar arquitectura actual mediante dependencias, tamaño de clases, acoplamiento, duplicidad y pruebas.

Identificar seams o puntos de corte para introducir casos de uso, interfaces y adaptadores.

Refactorizar controladores grandes separando entrada, orquestación, dominio e infraestructura.

Extraer lógica de negocio desde servicios acoplados, modelos ORM o helpers dispersos.

Introducir pruebas de caracterización antes de modificar código crítico.

Crear módulos nuevos con arquitectura limpia mientras se convive con código legado.

Aplicar strangler fig pattern para reemplazar partes sin reescribir todo el sistema.

Gestionar deuda técnica con prioridades, roadmap, riesgos y valor de negocio.

Evitar migraciones arquitectónicas masivas sin entregas incrementales.

Definir estrategia de adopción por equipos: estándares, plantillas, revisiones, formación y métricas.

Diseñar una aplicación empresarial completa aplicando principios de Arquitectura Limpia.

Definir contexto de negocio, usuarios, procesos, reglas principales, restricciones y casos de uso.

Identificar entidades, objetos de valor, servicios de dominio, eventos y reglas invariantes.

Diseñar capas de dominio, aplicación, infraestructura y presentación con dependencias correctas.

Crear casos de uso principales con entradas, salidas, reglas, errores y transacciones.

Diseñar puertos de entrada y salida para persistencia, notificaciones, pagos, APIs externas o almacenamiento.

Definir adaptadores HTTP, CLI, jobs, repositorios, clientes externos y persistencia.

Separar DTOs, modelos de dominio, modelos de persistencia, modelos de respuesta y eventos.

Diseñar estrategia de testing: dominio, casos de uso, adaptadores, contratos, integración y end-to-end.

Crear estructura modular basada en capacidades de negocio o bounded contexts.

Definir cómo se gestionan seguridad, autorización, validación, logging, errores y observabilidad.

Evaluar si el sistema debe empezar como monolito modular, microservicio o conjunto de módulos internos.

Diseñar evolución futura con eventos, CQRS, integración externa o extracción de servicios.

Preparar plan de refactorización si el punto de partida es una aplicación existente.

Presentar la arquitectura final defendiendo decisiones, límites, trade-offs, riesgos, testabilidad y mantenibilidad.