Los 4 pilares — encapsulamiento, herencia, polimorfismo y abstracción — y cuándo cada uno es una herramienta o una trampa. Composición vs herencia, cohesión, acoplamiento, Tell Don't Ask y Law of Demeter. Base imprescindible para entender por qué SOLID existe y qué problema resuelve cada principio.
Los cinco principios para diseño orientado a objetos acuñados y popularizados por Robert C. Martin (SRP, OCP, LSP, ISP, DIP). Sirven para clases y módulos cohesionados, extensibles y desacoplados de implementaciones concretas — puente natural entre Clean Code a nivel de función y arquitectura en capas.
Basado en Clean Code: A Handbook of Agile Software Craftsmanship. Nombres expresivos, funciones pequeñas, comentarios honestos, formato, objetos, errores, límites entre módulos y principios que emergen al refactorizar.
Basado en Refactoring: Improving the Design of Existing Code (Fowler). Catálogo de técnicas seguras para reestructurar código sin cambiar su comportamiento: Extract Method, Move Field, Replace Conditional with Polymorphism, y cuándo aplicar cada una. La contraparte ejecutiva de Clean Code.
Pirámide de testing, unit tests, integration tests, TDD, mocks & stubs, y estrategias de cobertura en proyectos de producción.
Tipos, genéricos, colecciones, Optional, streams, excepciones, módulos (JPMS); modelo de memoria y GC a alto nivel; herramientas de diagnóstico (jcmd, jstat). Base antes de concurrencia avanzada y del ecosistema Spring.
Visibilidad, orden de memoria, synchronized, locks, pools de hilos, estructuras concurrentes; virtual threads cuando apliquen; virtual threads (Java 21) y cuándo convienen. Para entender fallos bajo carga más allá del código “limpio”.
Project Reactor: Mono, Flux, operadores y backpressure. Spring WebFlux como alternativa no bloqueante a Spring MVC para I/O intensivo. Virtual Threads (Java 21) y cuándo cada modelo conviene. Un senior debe poder argumentar la elección entre imperativo y reactivo.
Contenedor IoC, beans y scopes, @Configuration, perfiles y propiedades, auto-configuración (cómo razonarla), ciclo de vida del contexto y extensión por eventos. Puente entre SOLID en código y el ensamblado real de la aplicación.
JPA/Hibernate en producción: sesión, lazy/eager, fetch joins, @Transactional (propagación, rollbackFor), Spring Data JPA, Flyway/Liquibase. Materializa en Spring lo aprendido en bases de datos relacionales y transacciones.
REST pragmático, recursos y verbos, errores y códigos, versionado, paginación, idempotencia (Idempotency-Key), OpenAPI; evolución sin romper clientes. Independiente del framework; luego se aterriza en Spring MVC.
OWASP para APIs, autenticación vs autorización, manejo de secretos, dependencias vulnerables, cookies vs tokens, CORS y superficie de ataque. Marco general antes de Spring Security.
Controllers, validación, manejo de excepciones HTTP, Spring Security (cadena de filtros, JWT/OAuth2 según el caso), Actuator, health y métricas. Lo más específico del stack tras APIs y seguridad genérica.
Modelo de memoria JVM (heap, stack, metaspace), algoritmos GC (G1, ZGC, Shenandoah), tuning de flags, profiling con Async Profiler / VisualVM, análisis de heap dumps y flame graphs. Distingue a un senior que sabe depurar producción de uno que solo escribe código.
Modelo relacional, normalización práctica, SQL, índices y planes de ejecución, consultas y antipatrones (p. ej. N+1 a nivel SQL). Agnóstico al stack; sirve de base antes de ORM y Spring Data.
ACID, niveles de aislamiento, fenómenos (dirty read, phantom…), idempotencia en escrituras, migraciones de esquema (Flyway/Liquibase como concepto). Enlaza con Spring Data donde se materializa @Transactional y JPA.
Redis como caché distribuida y estructura de datos (cache-aside, TTL, eviction, pub/sub). MongoDB como base documental (esquema flexible, índices, consistencia eventual). Patrones de caché: write-through, write-behind, invalidación.
Basado en Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, Helm, Johnson, Vlissides). Los 23 patrones clásicos en tres familias — creacionales, estructurales y de comportamiento — con intención, consecuencias y cuándo (no) aplicarlos en código actual.
Basado en Domain-Driven Design (Eric Evans). Ubiquitous Language, Bounded Contexts y Context Mapping en el diseño estratégico; Entities, Value Objects, Aggregates e invariantes en el diseño táctico; Repositories, Domain Events, Event Sourcing y CQRS para la persistencia del dominio.
Ports & Adapters, separación de dominio e infraestructura, inversión de dependencias y aplicación práctica en proyectos reales.
Basado en Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Regla de dependencia, entidades y casos de uso, boundaries, frameworks como detalle, y cómo mantener el dominio independiente de la UI, la BD y los entregables.
Imágenes, capas, Dockerfile multi-stage, volúmenes y redes, límites de recursos, buenas prácticas de seguridad en imágenes. Base inmediata para reproducir entornos y para CI/CD.
Integración continua (build, test, análisis), artefactos, pipelines, despliegue continuo vs continuo delivery, estrategias de ramas y gates de calidad. Encaja después de contenedores porque muchos pipelines empaquetan con Docker.
CAP Theorem, modelos de consistencia (fuerte, eventual, causal), BASE vs ACID en sistemas distribuidos, relojes lógicos, quórum y consenso. Marco teórico que da coherencia a Kafka, EDA, Saga y microservicios — la resiliencia práctica (Circuit Breaker, Retry) se cubre en la tarjeta de Resiliencia y mensajería.
Timeouts, retries con jitter, idempotencia, circuit breaker, bulkhead; colas, contratos de entrega (al menos una vez, exactamente una vez a nivel mental), patrón outbox. Las sagas y el estilo event-driven amplían esto en las dos tarjetas siguientes.
Eventos de dominio, publicación/suscripción, notificación vs event-carried state transfer, consistencia eventual, idempotencia en consumidores, log de eventos y streaming a alto nivel. Puente natural tras mensajería y antes de sagas y microservicios.
Apache Kafka como plataforma concreta de EDA: topics, particiones, offsets, consumer groups, garantías de entrega (at-least-once, exactly-once), log compaction y retention. Comparativa con RabbitMQ/SQS. Materializa en herramienta lo visto en EDA y Resiliencia.
Transacciones largas sin 2PC: coreografía (eventos entre servicios) vs orquestación (coordinador explícito). Pasos locales, compensaciones, estados del flujo y cuándo conviene cada estilo. Complementa EDA y microservicios con datos por servicio.
Logs estructurados, métricas (RED/USE), trazas distribuidas y correlación de trace-id. Pensado para servicios en contenedores, flujos saga y publicación de eventos.
Descomposición por límites de dominio, contratos entre equipos, datos por servicio y despliegue independiente. Comunicación en el borde con API Gateway y BFF. Red de servicios con Service Mesh. Migración incremental desde el monolito con Strangler Fig. Asume contenedores, CI/CD, resiliencia y observabilidad.
Ruta completa: arquitectura interna y control plane, workloads, networking, configuración y persistencia, Helm/Kustomize, observabilidad y troubleshooting, seguridad y quotas, GitOps y clusters gestionados (EKS, GKE, AKS). kubectl, k9s y prácticas como en producción.
Plan de 5 infografías para fundamentos AWS y repaso final antes del CLF-C02: dominios por semana, ejemplos y tips de examen.
Certificación internacional PSD I (Professional Scrum Developer): competencias del desarrollador dentro de un equipo Scrum — artefactos, eventos, calidad, trabajo incremental y colaboración en el Sprint. No es la certificación de Scrum Master (PSM); el foco es cómo aporta código y prácticas técnicas el Developer al marco.