Curso de Arquitectura Microservicios y DDD en NodeJS para empresas

¿Qué es Domain-Driven Design y qué problemas pretende resolver?

Diferencia entre utilizar DDD y limitarse a organizar código en carpetas.

Problemas de negocio como punto de partida de las decisiones arquitectónicas.

Descubrimiento del conocimiento mediante colaboración entre especialistas técnicos y de negocio.

Identificación del Core Domain como área de mayor diferenciación o valor empresarial.

Identificación de Supporting Subdomains y Generic Subdomains.

Diferencias entre dominio, subdominio, modelo y servicio.

Lenguaje ubicuo como vocabulario compartido entre negocio y tecnología.

Construcción progresiva del lenguaje ubicuo a partir de conceptos reales del negocio.

Detección de términos ambiguos o con significados distintos entre departamentos.

Qué es un modelo de dominio y por qué no pretende reproducir literalmente la realidad.

Modelado efectivo centrado en comportamientos, reglas y decisiones relevantes.

Event Storming como técnica para descubrir procesos, eventos, comandos, políticas y puntos de decisión.

Identificación de capacidades de negocio antes de decidir la división física de servicios.

Qué es un Bounded Context y por qué protege la consistencia de un modelo.

Diferencia entre subdominio y Bounded Context.

Identificación de límites conceptuales, organizativos, físicos y de propiedad.

Relación entre Bounded Contexts y equipos responsables.

Context Mapping para representar relaciones entre diferentes modelos.

Patrones Shared Kernel, Customer/Supplier y Conformist.

Anti-Corruption Layer para proteger un modelo frente a conceptos externos.

Open Host Service y Published Language para integraciones estables.

Detección de modelos inconsistentes provocados por límites mal definidos.

Técnicas de descomposición de un dominio sin crear servicios excesivamente pequeños.

Utilización del dominio para definir candidatos iniciales a microservicios.

Papel de Node.js en arquitecturas de microservicios orientadas a I/O y concurrencia.

Modelo de ejecución de Node.js y funcionamiento general del event loop.

I/O asíncrona y consecuencias para el diseño de servicios.

Diferencias entre tareas I/O-bound y CPU-bound.

Selección de tecnologías según requisitos del servicio y no por uniformidad artificial.

Uso de TypeScript para expresar contratos, modelos y límites con mayor precisión.

Organización de módulos evitando dependencias circulares entre componentes.

Separación entre lógica de dominio, aplicación e infraestructura.

Creación de un servicio Node.js que no acople el dominio al framework HTTP.

Encapsulación de Express, Fastify, NestJS u otro framework dentro de adaptadores.

Estructuración de configuración mediante variables de entorno.

Validación de configuración al iniciar el proceso.

Gestión diferenciada de configuración por entorno.

Gestión de dependencias npm y control mediante archivos lock.

Versionado de paquetes y políticas de actualización de dependencias.

Diseño de servicios stateless cuando el caso de uso lo permite.

Gestión correcta del ciclo de vida de conexiones a recursos externos.

Inicio y parada ordenada mediante graceful startup y graceful shutdown.

Gestión de señales del sistema y cierre seguro de recursos.

Health checks de proceso y dependencias.

Readiness y liveness como conceptos diferentes.

Contenedorización de un servicio Node.js.

Configuración y despliegue de infraestructura necesaria para ejecutar varios servicios.

Estructura de repositorios en modelos monorepo y multirepo.

Convenciones que permiten mantener múltiples microservicios de forma homogénea.

Diferencias entre patrones estratégicos y patrones tácticos de DDD.

Qué son los Domain Objects y qué responsabilidad deben asumir.

Diferencia entre objetos de dominio y estructuras utilizadas únicamente para transportar datos.

Entities como objetos definidos por identidad y continuidad.

Value Objects como conceptos definidos completamente por sus atributos.

Inmutabilidad y validación de invariantes en Value Objects.

Diseño de comportamiento dentro del modelo frente a modelos de dominio anémicos.

Agregados como fronteras de consistencia transaccional.

Aggregate Root como único punto autorizado para modificar un agregado desde el exterior.

Definición de invariantes que deben mantenerse dentro de un agregado.

Criterios para evitar agregados excesivamente grandes.

Referencias entre agregados mediante identidad.

Domain Services para reglas que no pertenecen naturalmente a una Entity o Value Object.

Domain Events para representar hechos relevantes que ya han ocurrido.

Diferencias entre Domain Events e Integration Events.

Repositories como abstracción para recuperar y persistir agregados.

Factories para encapsular procesos de construcción complejos.

Specifications para expresar reglas combinables cuando aportan claridad.

Excepciones y errores propios del dominio.

Separación entre validación sintáctica de entrada e invariantes del modelo.

Persistencia del agregado sin filtrar detalles de infraestructura al dominio.

Mapeo entre modelos de dominio y modelos de persistencia.

Diseño de módulos TypeScript que protegen invariantes y dependencias.

Aplicación de agregados, Value Objects y Domain Events en servicios Node.js.

Origen y objetivos de la arquitectura hexagonal o Ports and Adapters.

Principio de dependencia hacia el núcleo de negocio.

Diferencias entre arquitectura por capas, Hexagonal, Clean Architecture y Onion Architecture.

Capa de presentación en una arquitectura tradicional.

Capa de lógica empresarial.

Capa de acceso a datos.

Problemas derivados del acoplamiento rígido entre capas.

Dominio como núcleo independiente de frameworks y mecanismos externos.

Capa de aplicación como orquestadora de casos de uso.

Qué es un caso de uso y qué responsabilidad debe asumir.

Diferencia entre caso de uso y lógica interna de una Entity o Aggregate.

Puertos de entrada como contratos ofrecidos por la aplicación.

Puertos de salida como necesidades que la aplicación delega al exterior.

Relación entre puertos, Domain Objects y casos de uso.

Adaptadores de entrada HTTP, CLI, jobs, mensajes y otros mecanismos.

Adaptadores de salida para bases de datos, brokers, APIs y almacenamiento.

Dependency Inversion aplicada a proyectos Node.js.

Dependency Injection sin acoplar el dominio a un contenedor concreto.

Scopes singleton, request y transient y su impacto en el ciclo de vida de dependencias.

Implementación de un puerto de repositorio mediante interfaces TypeScript.

Implementación de adaptadores intercambiables para infraestructura.

Sustitución del framework web sin modificar el núcleo del dominio.

Separación entre DTOs de transporte y objetos del dominio.

Mappers para convertir representaciones entre capas.

Tratamiento consistente de errores entre dominio, aplicación e infraestructura.

Organización física de un proyecto Node.js bajo arquitectura hexagonal.

Conversión progresiva de un servicio acoplado hacia una arquitectura basada en puertos y adaptadores.

Diferencias entre comunicación dentro de un proceso y comunicación distribuida.

Comunicación síncrona mediante HTTP.

REST como estilo para diseñar interfaces orientadas a recursos.

Uso de JSON y otros formatos de intercambio.

Diseño de contratos claros entre consumidores y proveedores.

OpenAPI para documentar y formalizar contratos HTTP.

DTOs de entrada y salida como frontera de transporte.

Validación de payloads antes de alcanzar la lógica de negocio.

Versionado de APIs y estrategias para mantener compatibilidad.

Evolución aditiva de contratos frente a cambios incompatibles.

Timeouts obligatorios en llamadas entre servicios.

Propagación de errores sin revelar detalles internos.

Correlation IDs y propagación de contexto entre peticiones.

Comunicación síncrona directa entre microservicios.

Coste de las cadenas largas de llamadas síncronas.

API Gateway como punto de entrada para clientes externos.

Routing, autenticación y controles transversales en un gateway.

API Composition para construir respuestas a partir de múltiples servicios.

Backend for Frontend cuando diferentes clientes necesitan interfaces distintas.

Descubrimiento de servicios en infraestructuras dinámicas.

Service Registry como patrón de registro y localización.

Server-side y client-side service discovery.

DNS y descubrimiento proporcionado por plataformas de orquestación.

Kubernetes Services como mecanismo de localización estable.

Balanceo de carga entre réplicas de un servicio.

Gestión de fallos y degradación en dependencias síncronas.

Diferencias entre llamada síncrona, mensaje, comando y evento.

Comunicación asíncrona para desacoplar temporalmente servicios.

Event-driven architecture aplicada a microservicios.

Integración mediante brokers de mensajería.

Colas de trabajo frente a publicación-suscripción.

Patrón Publish/Subscribe para distribuir eventos entre múltiples consumidores.

Routing de mensajes según tipo, clave o dominio.

Semánticas at-most-once, at-least-once y límites prácticos de exactly-once.

Duplicación de mensajes como condición normal en sistemas distribuidos.

Diseño de consumidores idempotentes.

Dead-letter queues para mensajes que no pueden procesarse correctamente.

Reintentos controlados sin generar bucles infinitos.

Backoff y jitter para distribuir nuevos intentos.

Orden de eventos y situaciones donde debe garantizarse.

Particionado de mensajes cuando se necesita preservar orden por agregado.

Domain Events frente a Integration Events.

Traducción de modelos sin estado entre contextos.

Traducción de modelos con estado cuando la integración necesita conservar correspondencias.

Anti-Corruption Layer para adaptar mensajes entre modelos distintos.

Transactional Outbox para publicar eventos de forma consistente con una transacción local.

Procesamiento del Outbox y entrega posterior al broker.

Inbox Pattern para controlar mensajes ya procesados.

Saga como patrón para coordinar transacciones distribuidas.

Saga basada en coreografía mediante eventos.

Saga basada en orquestación mediante un coordinador.

Acciones compensatorias cuando una operación distribuida no puede completarse.

Process Manager para gestionar procesos de negocio de larga duración.

Gestión de estado y timeouts en procesos distribuidos.

AsyncAPI como mecanismo para documentar contratos orientados a eventos.

Evolución compatible de esquemas de mensajes.

Principio Database per Service para preservar autonomía de los microservicios.

Problemas generados por compartir directamente una misma base de datos entre servicios.

Separación entre propiedad de los datos y tecnología utilizada para almacenarlos.

Polyglot Persistence cuando dominios diferentes necesitan modelos de almacenamiento distintos.

Transacciones locales dentro de un servicio.

Por qué las transacciones ACID globales dificultan la autonomía.

Consistencia eventual como consecuencia habitual de la distribución.

Diseño del negocio para tolerar periodos de inconsistencia controlada.

Lecturas desde otros servicios sin acceder directamente a sus tablas.

Replicación de datos entre contextos mediante eventos.

Read models especializados para consultas.

Patrón CQRS y separación entre comandos y consultas.

Diferencias entre CQRS lógico y separación física completa de modelos.

Casos donde CQRS aporta claridad frente a casos donde añade complejidad innecesaria.

Construcción de proyecciones a partir de eventos.

Actualización de read models de forma asíncrona.

Manejo de retrasos entre escritura y disponibilidad de la proyección.

Caché local y caché distribuida.

Redis como infraestructura para caching compartido.

Cache-aside como patrón de acceso.

Invalidación de caché y riesgo de servir información obsoleta.

TTL y selección de tiempos de expiración.

Prevención del cache stampede.

Bases de datos replicadas para aumentar capacidad de lectura y disponibilidad.

Réplicas de lectura y retraso de replicación.

Sharding y particionado cuando un único nodo deja de ser suficiente.

Backups y restauración como parte del diseño de datos.

Relación entre RPO, RTO y estrategia de recuperación.

Decisiones de consistencia basadas en reglas reales del negocio.

Fallos parciales como comportamiento esperado de un sistema distribuido.

Diferencia entre error de negocio, error técnico y fallo de infraestructura.

Diseño para impedir que un fallo local se propague por todo el sistema.

Timeouts como primera barrera frente a dependencias bloqueadas.

Reintentos únicamente sobre operaciones donde repetir sea seguro.

Idempotencia como requisito para reintentos fiables.

Exponential backoff y jitter.

Circuit Breaker para dejar temporalmente de consumir una dependencia degradada.

Estados closed, open y half-open de un circuit breaker.

Fallbacks que mantienen funcionalidad degradada cuando existe una alternativa válida.

Bulkhead Pattern para separar capacidad y evitar agotamiento global.

Rate limiting para controlar presión sobre servicios.

Load shedding cuando el sistema debe rechazar trabajo para protegerse.

Colas y buffers para absorber picos controlados de demanda.

Backpressure para impedir que productores saturen consumidores.

Límites de concurrencia en servicios Node.js.

Deadlines propagados entre varias llamadas distribuidas.

Gestión centralizada y clasificación de errores.

Recuperación después de reinicios inesperados.

Graceful shutdown sin abandonar operaciones críticas.

Health checks que reflejan capacidad real para atender tráfico.

Pruebas de resiliencia y validación de hipótesis de recuperación.

Chaos Engineering como disciplina para comprobar comportamiento ante fallos.

Evitación de dependencias críticas únicas.

Degradación controlada de funcionalidades no esenciales.

Diseño antifrágil como búsqueda de aprendizaje y mejora tras incidentes y estrés operacional.

Postmortems sin culpabilización orientados a evitar recurrencias.

Arquitecturas capaces de detectar, contener, recuperar y aprender de los fallos.

Diferencia entre rendimiento, throughput, latencia, capacidad y escalabilidad.

Cómo detectar que un servicio está alcanzando sus límites.

Identificación de CPU, memoria, I/O, red, base de datos y dependencias como posibles cuellos de botella.

Escalabilidad vertical mediante aumento de recursos de una instancia.

Escalabilidad horizontal mediante múltiples réplicas.

Diseño stateless como facilitador del escalado horizontal.

Balanceadores de carga para distribuir peticiones.

Estrategias de load balancing.

Afinidad de sesión y costes de introducir estado asociado a una instancia.

Escalado independiente de servicios según su perfil de carga.

Réplicas de lectura para descargar consultas intensivas.

Caché para reducir trabajo repetitivo.

CQRS para escalar de forma diferente lecturas y escrituras.

Colas para desacoplar picos de entrada de la capacidad de procesamiento.

Serverless y funciones bajo demanda para cargas discontinuas.

AWS Lambda como ejemplo de ejecución Node.js activada por demanda.

Cold starts y su impacto en determinados workloads serverless.

Event loop lag como indicador de saturación de un proceso Node.js.

CPU-bound workloads y riesgo de bloquear el event loop.

Worker Threads para tareas computacionalmente intensivas.

Múltiples procesos y aprovechamiento de varios núcleos.

Streams para procesar información sin cargar datasets completos en memoria.

Backpressure en streams de Node.js.

Pools de conexiones y configuración adecuada de sus límites.

Optimización de consultas a base de datos.

Prevención del problema N+1 en accesos distribuidos o persistencia.

Compresión, serialización y tamaño de los payloads.

Keep-alive y reutilización de conexiones HTTP.

Load testing para encontrar límites antes de producción.

Métricas de percentiles p95 y p99 frente a promedios engañosos.

Escalado automático basado en métricas.

Kubernetes Horizontal Pod Autoscaler como mecanismo de escalado horizontal.

Ajuste de requests y limits de CPU y memoria.

Optimización del rendimiento manteniendo consistencia y claridad arquitectónica.

Superficie de ataque adicional introducida por la distribución.

Diferencia entre autenticación y autorización.

OAuth 2.0 y OpenID Connect en arquitecturas modernas.

Tokens JWT y validación correcta de firma, issuer, audience y expiración.

Autorización basada en roles, permisos o atributos.

Identidad del usuario frente a identidad del servicio.

Autenticación service-to-service.

mTLS para autenticar y cifrar comunicaciones internas cuando la arquitectura lo requiere.

API Gateway como punto para aplicar determinadas políticas transversales.

Zero Trust aplicado a servicios internos.

Principio de mínimo privilegio.

Gestión externa de secrets y credenciales.

Prohibición de incorporar secretos en repositorios o imágenes.

Rotación de secretos y credenciales.

Protección de variables de entorno sensibles.

Validación estricta de entradas.

Prevención de inyección en consultas y comandos.

Serialización segura de datos.

Rate limiting y protección frente a abuso.

CORS cuando existen clientes web.

Cabeceras de seguridad HTTP.

Limitación del detalle incluido en mensajes de error.

Dependencias npm y riesgos de software supply chain.

Auditoría y actualización continua de dependencias.

Imágenes de contenedor mínimas y reducción de superficie de ataque.

Ejecución de contenedores sin privilegios innecesarios.

Segmentación de red entre componentes.

Trazabilidad de acciones sensibles.

Protección de información personal y confidencial en logs.

Seguridad como característica transversal desde el diseño del bounded context hasta producción.

Organización de tests en proyectos Node.js estructurados mediante DDD.

Pirámide de testing adaptada a sistemas distribuidos.

Tests unitarios sobre Value Objects, Entities y Aggregates.

Validación de invariantes mediante tests de dominio.

Tests de Domain Services.

Tests de casos de uso en la capa de aplicación.

Uso de dobles de prueba para puertos de salida.

Evitación de mocks innecesarios dentro del dominio.

Tests de adaptadores de persistencia.

Tests de adaptadores HTTP.

Integration tests con bases de datos reales aisladas.

Testcontainers para proporcionar dependencias efímeras reproducibles.

Integración de brokers reales en tests de mensajería.

Tests de serialización y deserialización de eventos.

Contract testing entre consumidores y proveedores.

Prevención de cambios incompatibles en APIs.

Validación de contratos asíncronos.

Tests de integración entre varios microservicios.

End-to-end testing sobre recorridos de negocio críticos.

Evitación de suites E2E excesivamente grandes y frágiles.

Tests de idempotencia de consumidores.

Tests sobre Outbox, Saga y procesos compensatorios.

Validación de timeouts, retries y circuit breakers.

Pruebas de resiliencia frente a dependencias no disponibles.

Performance testing y load testing.

Security testing integrado en el ciclo de desarrollo.

Datos de prueba y aislamiento entre ejecuciones.

Organización de fixtures y builders de objetos de dominio.

Estrategias de testing para arquitectura hexagonal.

Cobertura como indicador auxiliar y no como sustituto de la calidad.

Testing como mecanismo para preservar límites arquitectónicos durante la evolución del sistema.

Diferencia entre monitorización y observabilidad.

Logs, métricas y trazas como señales complementarias.

Structured Logging en servicios Node.js.

Niveles de log y criterios para seleccionar qué registrar.

Correlation IDs para seguir una operación entre servicios.

Distributed Tracing para reconstruir recorridos completos.

Spans y relaciones padre-hijo entre operaciones.

Propagación de contexto a través de HTTP y mensajería.

OpenTelemetry como estándar para instrumentar sistemas distribuidos.

Instrumentación de Node.js mediante OpenTelemetry SDK y auto-instrumentation.

Métricas técnicas de CPU, memoria, event loop y garbage collection.

Métricas de aplicación relacionadas con tráfico, errores y latencia.

Métricas de negocio relacionadas con los procesos del dominio.

SLIs, SLOs y error budgets.

Dashboards orientados a operación y diagnóstico.

Alertas basadas en síntomas relevantes y no únicamente en recursos.

Detección de cuellos de botella mediante trazas distribuidas.

Diagnóstico de errores que atraviesan varios microservicios.

Investigación de dependencias lentas.

Monitorización de colas, consumidores y mensajes pendientes.

Descubrimiento y registro de servicios en entornos dinámicos.

Configuración y variables de entorno en despliegues distribuidos.

Contenedores como unidad de despliegue.

Docker Compose para entornos locales compuestos por varios servicios.

Kubernetes como plataforma de orquestación.

Deployments, Pods y Services.

ConfigMaps y Secrets para configuración de runtime.

Readiness, liveness y startup probes.

Autoscaling y control de recursos.

Rolling updates y recuperación ante versiones defectuosas.

Estrategias de backup y restauración de componentes persistentes.

Monitorización del proceso de recuperación.

Runbooks para incidencias recurrentes.

Mejora continua utilizando métricas, incidentes y datos de producción.

Evaluación objetiva de una arquitectura existente antes de decidir una migración.

Identificación de problemas que realmente justifican evolucionar hacia microservicios.

Identificación de funcionalidades candidatas a ser extraídas.

Utilización de Bounded Contexts para establecer fronteras de migración.

Priorización del Core Domain frente a componentes de menor valor estratégico.

Strangler Fig Pattern para sustituir progresivamente partes del sistema.

Extracción de capacidades manteniendo temporalmente el monolito en funcionamiento.

Anti-Corruption Layer entre el modelo existente y los nuevos servicios.

Estrategias de ejecución paralela durante una transición.

Migración gradual de tráfico.

Gestión de contratos entre componentes antiguos y nuevos.

Separación progresiva de bases de datos compartidas.

Migración de datos sin romper procesos activos.

Replicación temporal y sincronización durante la transición.

Change Data Capture como alternativa para determinadas migraciones.

Gestión de dependencias todavía no extraídas.

Riesgos de crear un monolito distribuido durante una migración incorrecta.

Observabilidad específica para comparar comportamiento antes y después del cambio.

Estrategias de rollback durante la extracción de servicios.

Versionado independiente de microservicios.

Compatibilidad hacia atrás durante despliegues graduales.

Estandarización de estructura de proyectos Node.js.

Convenciones para nombres, configuración, logs, errores, APIs y eventos.

Plantillas y scaffolding para nuevos microservicios.

Bibliotecas compartidas frente al riesgo de introducir acoplamiento entre servicios.

Definición de qué componentes deben estandarizarse y cuáles pueden evolucionar independientemente.

Architectural Decision Records para documentar decisiones relevantes.

Fitness Functions para comprobar automáticamente restricciones arquitectónicas.

Métricas de calidad, entrega, disponibilidad y operación.

Gobierno de contratos de APIs y eventos.

Catálogo de servicios y ownership.

Golden Paths para proporcionar una forma recomendada de crear nuevos servicios.

Estandarización de CI/CD, observabilidad, seguridad y despliegue.

Revisión periódica de límites entre servicios a medida que cambia el dominio.

Detección de servicios que deben dividirse, fusionarse o regresar a un módulo.

Gestión de deuda técnica distribuida.

Evolución de la arquitectura sin convertir estándares en barreras para los equipos.

Revisión sistemática de proyectos para comprobar coherencia con DDD, arquitectura hexagonal y principios de microservicios.

Identificación del problema empresarial que debe resolver la solución.

Descubrimiento del dominio y construcción inicial del lenguaje ubicuo.

Identificación de Core Domain, Supporting Subdomains y Generic Subdomains.

Definición de Bounded Contexts y relaciones mediante Context Mapping.

Selección razonada de los límites de cada microservicio.

Definición de ownership funcional y de datos.

Diseño de la arquitectura general y sus dependencias.

Aplicación de arquitectura hexagonal en cada servicio.

Separación entre dominio, aplicación e infraestructura.

Creación de Entities y Value Objects.

Diseño de Aggregates y Aggregate Roots.

Implementación de invariantes del dominio.

Definición de casos de uso.

Creación de puertos de entrada y salida.

Implementación de adaptadores HTTP y persistencia.

Diseño de contratos síncronos entre servicios.

Incorporación de API Gateway cuando la arquitectura lo requiere.

Definición de eventos de integración.

Implementación de comunicación basada en publicación-suscripción.

Utilización de Transactional Outbox para garantizar publicación consistente.

Diseño de consumidores idempotentes.

Modelado de un proceso distribuido mediante Saga o Process Manager.

Separación de comandos y consultas mediante CQRS donde aporte valor.

Construcción de read models para consultas especializadas.

Definición de estrategia de consistencia de datos.

Incorporación de caché en los puntos donde exista una necesidad real de rendimiento.

Aplicación de balanceo y escalado horizontal.

Identificación de workloads adecuados para ejecución serverless.

Diseño de timeouts, retries, circuit breakers y fallbacks.

Aplicación de rate limiting y límites de concurrencia.

Definición de autenticación y autorización.

Gestión de identidad entre servicios.

Protección de secretos y configuración.

Redacción de tests unitarios para el modelo de dominio.

Construcción de tests de aplicación e integración.

Validación de contratos entre servicios.

Comprobación de escenarios de fallo y recuperación.

Contenedorización de todos los componentes.

Despliegue sobre Kubernetes.

Configuración de service discovery, health checks y autoscaling.

Instrumentación de trazas y métricas mediante OpenTelemetry.

Centralización de logs estructurados.

Definición de indicadores y alertas relevantes.

Preparación de backup, recuperación y runbooks.

Aplicación de convenciones comunes entre servicios.

Documentación de decisiones mediante ADRs.

Análisis de rendimiento y cuellos de botella.

Revisión de dependencias y acoplamientos entre bounded contexts.

Evaluación de seguridad, resiliencia, escalabilidad y mantenibilidad.

Análisis de resultados y detección de mejoras arquitectónicas.

Elaboración de una hoja de ruta para evolucionar la solución después de su primera versión.