Forma a tu equipo sin coste para tu empresa. Este curso de Arquitectura de Hexagonal, DDD, EDA y CQRS para .Net es hasta 100% bonificable a través de FUNDAE.
Potencia las competencias clave de tus profesionales.
Accede a una formación práctica, actualizada y orientada a resultados.
Prepara a tu equipo para los retos del entorno laboral actual.
Nos ocupamos de la gestión con FUNDAE si tu empresa lo necesita.
A medida
Formación en Arquitectura de Hexagonal, DDD, EDA y CQRS para .Net a medida
Descubre el mejor curso de Arquitectura de Hexagonal, DDD, EDA y CQRS para .Net para empresas con nuestra Aula Virtual Personalizada:
Sesiones en vivo por videoconferencia.
Temario totalmente personalizado.
Fechas y horarios adaptados a tu empresa.
Acceso a grabaciones.
Aprende practicando
Totalmente Práctico y Aplicable
Formación diseñada para que apliques cada concepto en situaciones reales de tu trabajo, con enfoque práctico y útil desde el primer momento.
Aprendizaje 100% práctico, enfocado en lo que realmente necesitas.
Casos reales y ejercicios adaptados a tu entorno profesional.
Aplica cada conocimiento directamente en tus tareas diarias.
Mejora tu rendimiento y el de tu equipo desde el primer día.
¿Por qué un curso en Arquitectura de Hexagonal, DDD, EDA y CQRS para .Net?
Una plataforma practica, con IA integrada y pensada para que mejores desarrollando. Se adapta a tu ritmo, te corrige al instante y te muestra tu progreso real.
Correccion magica
Feedback inteligente
Aprende de cada acierto y fallo con explicaciones claras
¿A quién va dirigida esta formación en Arquitectura de Hexagonal, DDD, EDA y CQRS para .Net?
Pensado para quienes deben dominar Arquitectura de Hexagonal, DDD, EDA y CQRS para .Net en su día a día
Desarrolladores backend .NET
Este curso encaja con desarrolladores que ya trabajan con C#, ASP.NET Core, APIs, Entity Framework Core, servicios backend o aplicaciones empresariales y quieren dar un salto de calidad arquitectónica. Aprenderán a separar dominio, aplicación e infraestructura, modelar reglas de negocio, diseñar comandos y consultas, trabajar con eventos y evitar que la lógica crítica quede repartida entre controladores, servicios anémicos y repositorios genéricos.
Desarrolladores senior y tech leads
Los perfiles con responsabilidad técnica podrán utilizar el curso para definir estándares de arquitectura, revisar pull requests, orientar refactorizaciones, reducir deuda y guiar a equipos que necesitan mantener sistemas complejos. La formación les aporta criterio para decidir cuándo usar DDD, CQRS, eventos, arquitectura hexagonal o una solución más simple.
Equipos que mantienen aplicaciones legacy .NET
Los equipos que trabajan con monolitos, aplicaciones n-capas, servicios acoplados, bases de datos compartidas o lógica de negocio dispersa podrán aprender estrategias de evolución gradual. El curso trabaja refactorización hacia arquitectura hexagonal, extracción de dominio, pruebas de caracterización, eventos y separación de responsabilidades sin reescrituras arriesgadas.
Arquitectos de software
Los perfiles de arquitectura podrán profundizar en decisiones de diseño, boundaries, bounded contexts, integración, consistencia eventual, contratos, eventos, read models, anti-corruption layers y gobernanza técnica. El curso ofrece una visión aplicable para diseñar sistemas .NET sostenibles y alineados con negocio.
Equipos de microservicios y plataformas distribuidas
Los equipos que trabajan con microservicios, APIs, colas, eventos, workers y plataformas cloud podrán aplicar DDD, EDA y CQRS con más control. La formación ayuda a evitar servicios mal delimitados, eventos ambiguos, dependencias circulares, transacciones distribuidas frágiles y modelos de datos compartidos sin ownership claro.
QA técnico, DevOps y perfiles de calidad
Los perfiles de calidad y plataforma podrán entender cómo probar, desplegar y observar sistemas diseñados con hexagonal, DDD, EDA y CQRS. El curso conecta arquitectura con pruebas de dominio, contrato, integración, consumidores de eventos, CI/CD, trazas, métricas, resiliencia y soporte real en producción.
Proveedor con 16 años de experiencia en formación empresarial
Sobre
En Imagina Formación llevamos más de 16 años ayudando a profesionales y empresas a mejorar sus habilidades con formación práctica y totalmente adaptada a sus necesidades. Durante este tiempo, hemos formado a más de 480.000 personas y colaborado con más de 3.500 empresas, convirtiéndonos en un referente en el sector.
16
Años de liderazgo
+480.000
Alumnos formados en Imagina
¿Tienes dudas?
Resolvemos todas tus dudas sobre nuestra formación en Arquitectura de Hexagonal, DDD, EDA y CQRS para .Net
Explora las respuestas a las preguntas que guian a nuestra comunidad. Aqui encontraras claridad sobre como funciona todo, desde el acceso hasta los detalles de los cursos. Si buscas respuestas, este es el lugar para comenzar.
Es un curso de arquitectura aplicada con implementación en .NET. Se trabajan conceptos de diseño, pero siempre bajados a C#, ASP.NET Core, EF Core, eventos, comandos, queries, pruebas, CI/CD y casos reales.
No es imprescindible, pero sí se recomienda tener experiencia backend con .NET. El curso explica DDD desde fundamentos estratégicos y tácticos, avanzando después hacia agregados, eventos, CQRS, EDA y migraciones.
Sí. El curso se plantea sobre .NET 10 como referencia actual LTS para proyectos empresariales .NET. Microsoft documenta que .NET 10 es una versión de soporte a largo plazo con tres años de soporte.
Sí. Se trabaja CQRS desde el enfoque conceptual hasta implementación con comandos, queries, handlers, modelos de lectura, proyecciones, consistencia eventual y criterios para decidir cuándo aplicarlo.
Sí. El curso cubre EDA con domain events, integration events, brokers, consumidores, Outbox, Inbox, Sagas, process managers, idempotencia, DLQ, versionado, observabilidad y pruebas de contrato.
Sí. Se diseñan puertos, adaptadores, casos de uso, infraestructura, APIs, persistencia y mensajería. El objetivo es proteger el dominio de frameworks y tecnologías externas sin añadir abstracciones inútiles.
Sí. Se trabaja EF Core desde una perspectiva DDD: agregados, value objects, owned types, Fluent API, repositorios orientados a dominio, migraciones, consultas y separación entre escritura y lectura.
Sí. El curso sirve tanto para monolitos modulares como para microservicios. De hecho, se insiste en no saltar a microservicios sin boundaries, ownership, eventos, datos y operación bien diseñados.
Sí. Hay bloques específicos sobre refactorización desde n-capas, anti-corruption layers, pruebas de caracterización, migración gradual a CQRS/EDA y evolución hacia monolito modular o servicios desacoplados.
Sí. Se cubre como patrón avanzado, explicando cuándo aporta valor y cuándo no. También se trabajan streams, snapshots, proyecciones, upcasting, pruebas Given-When-Then y riesgos operativos.
No. Es una formación corporativa práctica para equipos .NET. Puede ayudar a reforzar criterio de arquitectura, pero no sustituye una preparación oficial específica de ninguna certificación.
Sí. Al tratarse de una formación corporativa en desarrollo .NET, arquitectura de software, calidad, DevOps, seguridad y competencias digitales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.
Es un curso de arquitectura aplicada con implementación en .NET. Se trabajan conceptos de diseño, pero siempre bajados a C#, ASP.NET Core, EF Core, eventos, comandos, queries, pruebas, CI/CD y casos reales.
No es imprescindible, pero sí se recomienda tener experiencia backend con .NET. El curso explica DDD desde fundamentos estratégicos y tácticos, avanzando después hacia agregados, eventos, CQRS, EDA y migraciones.
Sí. El curso se plantea sobre .NET 10 como referencia actual LTS para proyectos empresariales .NET. Microsoft documenta que .NET 10 es una versión de soporte a largo plazo con tres años de soporte.
Sí. Se trabaja CQRS desde el enfoque conceptual hasta implementación con comandos, queries, handlers, modelos de lectura, proyecciones, consistencia eventual y criterios para decidir cuándo aplicarlo.
Sí. El curso cubre EDA con domain events, integration events, brokers, consumidores, Outbox, Inbox, Sagas, process managers, idempotencia, DLQ, versionado, observabilidad y pruebas de contrato.
Sí. Se diseñan puertos, adaptadores, casos de uso, infraestructura, APIs, persistencia y mensajería. El objetivo es proteger el dominio de frameworks y tecnologías externas sin añadir abstracciones inútiles.
Sí. Se trabaja EF Core desde una perspectiva DDD: agregados, value objects, owned types, Fluent API, repositorios orientados a dominio, migraciones, consultas y separación entre escritura y lectura.
Sí. El curso sirve tanto para monolitos modulares como para microservicios. De hecho, se insiste en no saltar a microservicios sin boundaries, ownership, eventos, datos y operación bien diseñados.
Sí. Hay bloques específicos sobre refactorización desde n-capas, anti-corruption layers, pruebas de caracterización, migración gradual a CQRS/EDA y evolución hacia monolito modular o servicios desacoplados.
Sí. Se cubre como patrón avanzado, explicando cuándo aporta valor y cuándo no. También se trabajan streams, snapshots, proyecciones, upcasting, pruebas Given-When-Then y riesgos operativos.
No. Es una formación corporativa práctica para equipos .NET. Puede ayudar a reforzar criterio de arquitectura, pero no sustituye una preparación oficial específica de ninguna certificación.
Sí. Al tratarse de una formación corporativa en desarrollo .NET, arquitectura de software, calidad, DevOps, seguridad y competencias digitales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.
Analizar por qué muchas aplicaciones .NET empiezan limpias y terminan acopladas por decisiones pequeñas repetidas: servicios genéricos, lógica en controladores, modelos compartidos y dependencias cruzadas.
Diferenciar arquitectura n-capas, clean architecture, arquitectura hexagonal, arquitectura cebolla, DDD, CQRS y EDA para entender qué resuelve cada enfoque y dónde se solapan.
Reconocer señales de mala arquitectura: cambios simples que tocan demasiados archivos, tests frágiles, reglas duplicadas, APIs que filtran base de datos y servicios imposibles de aislar.
Valorar cuándo una arquitectura más elaborada aporta retorno y cuándo una solución simple, modular y bien probada resulta más adecuada.
Situar .NET 10, ASP.NET Core, EF Core, workers, APIs y mensajería dentro de una arquitectura empresarial moderna y mantenible.
Revisar atributos de calidad que deben guiar el diseño: mantenibilidad, testabilidad, seguridad, observabilidad, rendimiento, escalabilidad y facilidad de despliegue.
Traducir problemas de negocio a decisiones técnicas sin caer en abstracciones genéricas que nadie entiende ni mantiene.
Crear criterios de diseño para evitar acoplamiento accidental entre UI, aplicación, dominio, infraestructura, persistencia y mensajería.
Definir qué significa “arquitectura preparada para cambio” en un sistema .NET que evoluciona durante años.
Elaborar un diagnóstico inicial de una aplicación de ejemplo, identificando puntos de deuda, dependencias fuertes y oportunidades de mejora.
Analizar por qué muchas aplicaciones .NET empiezan limpias y terminan acopladas por decisiones pequeñas repetidas: servicios genéricos, lógica en controladores, modelos compartidos y dependencias cruzadas.
Diferenciar arquitectura n-capas, clean architecture, arquitectura hexagonal, arquitectura cebolla, DDD, CQRS y EDA para entender qué resuelve cada enfoque y dónde se solapan.
Reconocer señales de mala arquitectura: cambios simples que tocan demasiados archivos, tests frágiles, reglas duplicadas, APIs que filtran base de datos y servicios imposibles de aislar.
Valorar cuándo una arquitectura más elaborada aporta retorno y cuándo una solución simple, modular y bien probada resulta más adecuada.
Situar .NET 10, ASP.NET Core, EF Core, workers, APIs y mensajería dentro de una arquitectura empresarial moderna y mantenible.
Revisar atributos de calidad que deben guiar el diseño: mantenibilidad, testabilidad, seguridad, observabilidad, rendimiento, escalabilidad y facilidad de despliegue.
Traducir problemas de negocio a decisiones técnicas sin caer en abstracciones genéricas que nadie entiende ni mantiene.
Crear criterios de diseño para evitar acoplamiento accidental entre UI, aplicación, dominio, infraestructura, persistencia y mensajería.
Definir qué significa “arquitectura preparada para cambio” en un sistema .NET que evoluciona durante años.
Elaborar un diagnóstico inicial de una aplicación de ejemplo, identificando puntos de deuda, dependencias fuertes y oportunidades de mejora.
Tema 1: Fundamentos de arquitectura evolutiva en .NET
Analizar por qué muchas aplicaciones .NET empiezan limpias y terminan acopladas por decisiones pequeñas repetidas: servicios genéricos, lógica en controladores, modelos compartidos y dependencias cruzadas.
Diferenciar arquitectura n-capas, clean architecture, arquitectura hexagonal, arquitectura cebolla, DDD, CQRS y EDA para entender qué resuelve cada enfoque y dónde se solapan.
Reconocer señales de mala arquitectura: cambios simples que tocan demasiados archivos, tests frágiles, reglas duplicadas, APIs que filtran base de datos y servicios imposibles de aislar.
Valorar cuándo una arquitectura más elaborada aporta retorno y cuándo una solución simple, modular y bien probada resulta más adecuada.
Situar .NET 10, ASP.NET Core, EF Core, workers, APIs y mensajería dentro de una arquitectura empresarial moderna y mantenible.
Revisar atributos de calidad que deben guiar el diseño: mantenibilidad, testabilidad, seguridad, observabilidad, rendimiento, escalabilidad y facilidad de despliegue.
Traducir problemas de negocio a decisiones técnicas sin caer en abstracciones genéricas que nadie entiende ni mantiene.
Crear criterios de diseño para evitar acoplamiento accidental entre UI, aplicación, dominio, infraestructura, persistencia y mensajería.
Definir qué significa “arquitectura preparada para cambio” en un sistema .NET que evoluciona durante años.
Elaborar un diagnóstico inicial de una aplicación de ejemplo, identificando puntos de deuda, dependencias fuertes y oportunidades de mejora.
Tema 2: Arquitectura Hexagonal: puertos, adaptadores y límites claros
Comprender la arquitectura hexagonal como forma de proteger el núcleo de negocio frente a detalles externos como frameworks, bases de datos, colas, APIs o UI.
Diferenciar puertos de entrada, puertos de salida, adaptadores primarios y adaptadores secundarios con ejemplos reales en ASP.NET Core.
Diseñar el dominio y la aplicación como centro del sistema, evitando que Entity Framework, controladores o clientes HTTP dicten el modelo de negocio.
Crear adaptadores de entrada para APIs REST, gRPC, workers, colas, comandos CLI o pruebas automatizadas sin cambiar el caso de uso.
Crear adaptadores de salida para persistencia, mensajería, servicios externos, almacenamiento, notificaciones y APIs de terceros.
Evitar interfaces innecesarias creadas solo por dogma, distinguiendo abstracciones útiles de capas artificiales.
Aplicar inversión de dependencias para que el núcleo declare necesidades y la infraestructura proporcione implementaciones.
Diseñar ensamblados, proyectos y namespaces que refuercen el límite arquitectónico en lugar de dejarlo solo como intención.
Revisar errores habituales: puertos demasiado genéricos, adaptadores con lógica de negocio, dominio dependiente de EF Core y casos de uso anémicos.
Crear una plantilla base de arquitectura hexagonal .NET con proyectos, dependencias, tests y reglas de referencia.
Tema 3: Organización de soluciones .NET por capas, módulos y contexto
Diseñar una solución .NET con proyectos separados para dominio, aplicación, infraestructura, API, contracts, workers y pruebas.
Evaluar cuándo conviene organizar por capas técnicas, por módulos funcionales, por vertical slices o por bounded contexts.
Definir dependencias permitidas entre proyectos para impedir que infraestructura, API o persistencia contaminen el dominio.
Crear reglas de visibilidad interna usando namespaces, `internal`, convenciones, analyzers o pruebas de arquitectura cuando aporte valor.
Separar contratos públicos, DTOs internos, eventos, comandos, queries y modelos de dominio para evitar acoplamientos silenciosos.
Diseñar una estructura que soporte monolito modular y pueda evolucionar hacia microservicios si el dominio y el equipo lo justifican.
Evitar carpetas genéricas como “Services”, “Helpers” o “Managers” que terminan acumulando responsabilidades ambiguas.
Preparar convenciones de nombres para casos de uso, comandos, eventos, adaptadores, repositorios y proyecciones.
Documentar la arquitectura de solución para que nuevos desarrolladores entiendan dónde debe vivir cada responsabilidad.
Revisar una solución desordenada y proponer una reorganización incremental sin romper todo el sistema de golpe.
Tema 4: DDD estratégico: dominios, subdominios y bounded contexts
Identificar el dominio principal de la empresa y separar subdominios core, supporting y generic para decidir dónde merece la pena invertir más diseño.
Comprender bounded context como límite semántico donde un concepto tiene un significado concreto y no necesariamente igual al de otro contexto.
Detectar límites de contexto a partir de lenguaje, procesos, datos, equipos, reglas, integraciones, conflictos y cambios frecuentes.
Crear mapas de contexto con relaciones upstream, downstream, customer-supplier, conformist, shared kernel y anti-corruption layer.
Evitar que los bounded contexts se definan por tablas, pantallas o estructura organizativa sin analizar el lenguaje de negocio.
Traducir límites estratégicos a módulos, servicios, APIs, eventos, contratos, ownership y decisiones de despliegue.
Diseñar conversaciones con negocio para descubrir términos ambiguos, reglas escondidas y conceptos que cambian según departamento.
Analizar cuándo un concepto compartido debe duplicarse, traducirse, sincronizarse o mantenerse como shared kernel.
Documentar decisiones estratégicas mediante mapas, ADRs, glosarios y ejemplos de casos de uso.
Aplicar DDD estratégico a un caso empresarial, separando dominios, responsabilidades, relaciones y riesgos de acoplamiento.
Tema 5: Lenguaje ubicuo y modelado colaborativo
Construir lenguaje ubicuo entre negocio y desarrollo para que entidades, eventos, comandos, reglas y errores expresen conceptos reales.
Detectar términos conflictivos como “cliente”, “pedido”, “estado”, “cuenta” o “usuario” cuando significan cosas distintas en áreas diferentes.
Transformar conversaciones funcionales en modelos de dominio, ejemplos, invariantes, eventos y casos de uso verificables.
Usar técnicas como Event Storming, ejemplos concretos, escenarios y reglas de negocio para descubrir comportamiento antes de diseñar clases.
Evitar modelos generados desde la base de datos cuando la estructura de tablas no refleja correctamente el dominio.
Documentar glosarios vivos con términos, significado, contexto, ejemplos, reglas y equivalencias entre áreas.
Revisar nombres de clases, métodos, eventos y comandos para que el código sea legible por perfiles técnicos y funcionales.
Resolver ambigüedades antes de codificar, porque una palabra mal entendida puede contaminar APIs, eventos, datos y reporting.
Crear ejemplos de uso como pruebas de aceptación que sirvan de puente entre lenguaje de negocio y código.
Mantener el lenguaje ubicuo a medida que el producto evoluciona, evitando que la documentación quede separada del código real.
Tema 6: DDD táctico: entidades, value objects y agregados
Diseñar entidades con identidad, ciclo de vida, comportamiento y reglas, evitando modelos anémicos que solo contienen propiedades públicas.
Crear value objects inmutables para conceptos como dinero, email, rango de fechas, porcentaje, dirección o identificadores tipados.
Modelar agregados como fronteras de consistencia que protegen invariantes de negocio y controlan cambios internos.
Definir aggregate roots que actúan como punto de entrada para modificar un conjunto de entidades y value objects.
Evitar agregados gigantes que intentan cubrir todo el proceso de negocio y bloquean rendimiento, concurrencia y escalabilidad.
Diseñar invariantes que se aplican de forma síncrona dentro del agregado y reglas que pueden resolverse mediante procesos posteriores.
Usar constructores, métodos de fábrica y métodos de comportamiento para impedir estados inválidos desde el propio dominio.
Persistir value objects con EF Core mediante owned entity types cuando encaja con el modelo de datos. Microsoft documenta owned entity types como forma habitual de mapear value objects en EF Core.
Revisar diferencias entre pureza del modelo de dominio y necesidades pragmáticas de persistencia, serialización y rendimiento.
Implementar un agregado completo con entidades, value objects, invariantes, eventos de dominio y pruebas unitarias.
Tema 7: Servicios de dominio, políticas y reglas complejas
Diferenciar lógica de entidad, lógica de agregado, domain service, application service y policy para ubicar cada regla en el lugar correcto.
Crear servicios de dominio solo cuando una operación relevante no pertenece naturalmente a una entidad o value object concreto.
Modelar políticas de negocio como objetos explícitos cuando una decisión depende de varios factores, reglas, estados o configuraciones.
Evitar el anti-patrón de “DomainService” genérico donde acaba cualquier lógica que no se supo modelar.
Diseñar reglas complejas con nombres expresivos, pruebas unitarias y ejemplos de negocio que faciliten revisión y mantenimiento.
Separar reglas puras de dominio de llamadas a infraestructura, proveedores externos, bases de datos o APIs.
Utilizar especificaciones o predicados de negocio cuando aporten claridad, composición y reutilización real.
Gestionar reglas temporales, excepciones comerciales, condiciones por país, permisos y variaciones por cliente sin ensuciar el modelo.
Documentar decisiones de modelado cuando una regla se ubica fuera del agregado por rendimiento, consistencia o integración.
Refactorizar un caso de uso con lógica dispersa hacia entidades, value objects, políticas y servicios de dominio bien delimitados.
Tema 8: Casos de uso y capa de aplicación
Definir la capa de aplicación como orquestadora de casos de uso, coordinación de transacciones, puertos, autorizaciones, eventos y persistencia.
Diseñar comandos y queries como contratos de intención, no como simples copias de DTOs de API o formularios.
Implementar handlers que coordinan dominio e infraestructura sin contener reglas de negocio que deberían vivir en agregados o políticas.
Gestionar transacciones de unidad de trabajo en la capa adecuada, evitando transacciones distribuidas innecesarias.
Separar validación superficial de entrada, validación de caso de uso y validación de invariantes del dominio.
Incorporar autorización contextual antes de ejecutar operaciones que modifican estado o devuelven datos sensibles.
Diseñar resultados de caso de uso con errores controlados, mensajes de negocio y trazabilidad sin lanzar excepciones para flujos esperados.
Evitar application services gigantes que se convierten en nuevos monolitos dentro del monolito.
Crear pruebas de aplicación con mocks de puertos, repositorios fake o contenedores cuando sea necesario validar integración real.
Implementar un caso de uso completo desde entrada hasta dominio, persistencia, evento, respuesta y pruebas.
Tema 9: Puertos de salida, repositorios y persistencia desacoplada
Diseñar repositorios orientados a agregados, no a tablas, evitando `GenericRepository<T>` cuando oculta intenciones y empobrece el modelo.
Definir puertos de salida para persistencia, mensajería, servicios externos, calendario, email, archivos, pagos o sistemas internos.
Crear interfaces en el núcleo que expresan necesidades del caso de uso, no detalles técnicos de la infraestructura.
Implementar adaptadores con EF Core, Dapper, APIs externas o almacenamiento según necesidades de cada puerto.
Evitar que IQueryable, DbContext, entidades EF o expresiones de infraestructura se filtren hacia aplicación o dominio sin control.
Gestionar transacciones y unidad de trabajo con una frontera clara entre caso de uso, repositorio y persistencia.
Diseñar consultas complejas separadas del repositorio de agregado cuando pertenecen al modelo de lectura o reporting.
Controlar rendimiento de persistencia sin sacrificar el modelo de dominio por optimizaciones prematuras.
Crear dobles de prueba para puertos de salida que permitan validar casos de uso sin infraestructura real.
Refactorizar una persistencia acoplada a EF Core hacia puertos, adaptadores y repositorios orientados al dominio.
Tema 10: Entity Framework Core en arquitecturas DDD
Mapear entidades, value objects, agregados y relaciones en EF Core sin obligar al dominio a parecer una tabla.
Configurar Fluent API para separar detalles de persistencia del modelo de dominio y mantener un diseño más expresivo.
Usar backing fields, owned types, conversiones, índices, constraints y configuraciones por entidad cuando el modelo lo requiere.
Gestionar colecciones privadas y métodos de dominio para proteger invariantes sin exponer setters públicos innecesarios.
Diferenciar el modelo transaccional del dominio y modelos optimizados para lectura, reporting o búsquedas.
Controlar problemas de lazy loading, tracking, N+1, consultas pesadas y carga accidental de agregados grandes.
Diseñar migraciones seguras y revisables para cambios en agregados, value objects y relaciones.
Separar configuraciones EF Core en infraestructura, evitando dependencias desde dominio hacia paquetes de persistencia.
Preparar tests de persistencia para validar mappings, constraints, conversiones, queries y migraciones críticas.
Crear una guía de EF Core para DDD con decisiones permitidas, compromisos pragmáticos y anti-patrones habituales.
Tema 11: Arquitectura Hexagonal con ASP.NET Core APIs
Implementar adaptadores de entrada HTTP con ASP.NET Core sin colocar lógica de negocio dentro de controllers o minimal APIs.
Traducir requests HTTP a comandos o queries de aplicación, controlando validación, autenticación, autorización y errores.
Diseñar respuestas HTTP coherentes con casos de uso: éxito, errores de validación, conflictos, no encontrado, prohibido y fallo inesperado.
Usar DTOs de API separados de comandos internos cuando el contrato público necesita estabilidad o transformación.
Crear endpoints finos que delegan en la aplicación y se mantienen fáciles de leer, probar y modificar.
Integrar filtros, middleware, exception handling y ProblemDetails sin contaminar dominio ni handlers.
Diseñar APIs versionables que no rompen consumidores cuando evoluciona el modelo interno.
Añadir OpenAPI como contrato de entrada, documentación y base para pruebas de contrato.
Proteger endpoints con políticas de autorización, antiforgery cuando aplique, rate limiting y validación server-side.
Construir un adaptador HTTP completo sobre un caso de uso hexagonal, con errores, documentación y pruebas.
Tema 12: CQRS conceptual: separar intención, lectura y escritura
Comprender CQRS como separación entre operaciones que modifican estado y operaciones que consultan información.
Analizar el patrón CQRS desde la definición de Microsoft: separar operaciones de lectura y escritura en modelos diferentes permite optimizar cada uno de forma independiente.
Identificar escenarios donde CQRS aporta valor: reglas de escritura complejas, lecturas optimizadas, escalado separado, permisos distintos o modelos de consulta ricos.
Reconocer cuándo CQRS sería excesivo, especialmente en CRUD simple, aplicaciones pequeñas o dominios con poca complejidad.
Diseñar comandos que expresan intención de negocio, no operaciones técnicas como “UpdateEntity”.
Diseñar queries que devuelven modelos ajustados a la pantalla, informe, API o consumidor.
Separar validaciones, autorizaciones, transacciones, eventos y persistencia en flujos de comando y consulta.
Evitar que CQRS se convierta en duplicación innecesaria de todo el sistema sin beneficio claro.
Documentar decisiones sobre CQRS: alcance, modelo de consistencia, read models, sincronización y coste operativo.
Refactorizar un servicio CRUD hacia CQRS simplificado, mostrando qué mejora y qué complejidad añade.
Tema 13: Implementación de comandos y command handlers en .NET
Crear comandos como objetos de intención con datos mínimos, nombres de negocio y validación inicial clara.
Implementar command handlers que orquestan carga de agregado, ejecución de comportamiento, persistencia y publicación de eventos.
Separar validación sintáctica de reglas de dominio, evitando duplicar invariantes en capas externas.
Diseñar resultados de comando con identificadores, errores de negocio, conflictos, estado final o información mínima necesaria.
Gestionar transacciones locales alrededor del cambio de estado y la escritura de eventos Outbox cuando corresponda.
Incorporar idempotencia en comandos que pueden recibirse más de una vez por reintentos, integraciones o usuarios.
Añadir autorización por caso de uso antes de modificar el agregado o ejecutar acciones sensibles.
Evitar command handlers que consultan demasiados repositorios, aplican reglas de dominio dispersas o coordinan procesos largos sin patrón claro.
Crear pipelines de comportamiento para validación, logging, métricas, transacciones, idempotencia o auditoría cuando aportan consistencia.
Implementar un flujo de comando completo con pruebas unitarias, pruebas de aplicación, persistencia y publicación de evento.
Tema 14: Queries, read models y proyecciones optimizadas
Diseñar queries orientadas a consumo, pantalla, API, informe, dashboard o proceso, sin forzar el agregado transaccional como modelo de lectura.
Crear read models que contienen exactamente la información necesaria para responder una consulta de forma eficiente y estable.
Implementar query handlers con EF Core, Dapper, SQL optimizado, vistas, materialized views o servicios especializados según necesidad.
Separar seguridad de lectura, filtros, paginación, ordenación, búsqueda y permisos por campo o recurso.
Evitar reutilizar entidades de dominio como DTOs de lectura cuando eso rompe encapsulación y acopla UI a persistencia.
Diseñar proyecciones actualizadas por eventos cuando la lectura necesita independencia, rendimiento o estructura distinta.
Controlar consistencia eventual entre escritura y lectura, explicando al usuario qué puede estar temporalmente desactualizado.
Optimizar consultas con índices, paginación, filtros server-side y reducción de overfetching.
Crear pruebas sobre read models para validar shape, filtros, permisos, orden, paginación y datos derivados.
Implementar un modelo de lectura completo para una pantalla empresarial compleja, conectado a eventos o persistencia directa.
Tema 15: Mediator pattern, pipelines y coordinación interna
Evaluar cuándo usar un mediator interno para separar controladores de handlers, aplicar pipelines y ordenar flujos de comandos y queries.
Diferenciar el patrón mediator de librerías concretas, evitando dependencia excesiva de una herramienta si el diseño no lo requiere.
Crear pipelines para validación, logging, autorización, transacciones, métricas, idempotencia, retries internos o auditoría.
Evitar pipelines opacos donde el comportamiento real del caso de uso queda repartido en demasiadas piezas difíciles de depurar.
Diseñar convenciones de nombres, carpetas y handlers para que comandos, queries y eventos sean fáciles de localizar.
Controlar errores y excepciones dentro del pipeline, distinguiendo errores de negocio, validación, permisos y fallos inesperados.
Añadir trazabilidad y métricas por comando y query para saber qué operaciones son lentas, fallan o consumen más recursos.
Crear tests de pipeline para validar que los comportamientos transversales se aplican como se espera.
Evaluar alternativas más simples cuando el equipo no necesita mediator y puede usar servicios de aplicación explícitos.
Implementar un pipeline completo de comandos y queries con validación, transacción, logging y métricas.
Tema 16: Domain events: comportamiento interno del dominio
Comprender los domain events como hechos relevantes ocurridos dentro del dominio que permiten desacoplar efectos secundarios internos.
Aplicar eventos de dominio para comunicar cambios entre agregados o procesos dentro del mismo bounded context.
Diseñar eventos con nombres en pasado, datos suficientes y semántica de negocio clara.
Evitar eventos de dominio que se convierten en simples notificaciones técnicas sin significado para el negocio.
Registrar eventos dentro del agregado al ejecutar comportamiento, manteniendo la intención cerca de la regla que la produce.
Publicar eventos de dominio después de persistir cambios o dentro del flujo transaccional según la estrategia del equipo.
Usar handlers de eventos de dominio para actualizar otros agregados, lanzar políticas, crear tareas o preparar eventos de integración.
Controlar efectos secundarios para no ocultar procesos críticos en cadenas de handlers difíciles de seguir.
Probar que los agregados generan eventos correctos ante comportamientos relevantes y no ante simples cambios de datos.
Implementar un flujo con domain event, handler interno, persistencia y prueba de comportamiento del agregado.
Tema 17: Integration events: comunicación entre bounded contexts
Diferenciar domain events de integration events, entendiendo que los segundos cruzan límites de contexto, servicio o sistema.
Diseñar eventos de integración como contratos públicos con estabilidad, versionado, documentación y ownership.
Evitar publicar directamente entidades de dominio o modelos EF Core como payloads de evento.
Definir envelopes de evento con identificador, tipo, versión, timestamp, correlation ID, causation ID, source y metadata.
Diseñar payloads suficientes para consumidores sin exponer detalles internos innecesarios.
Gestionar versionado de eventos mediante compatibilidad hacia atrás, evolución aditiva y deprecación controlada.
Documentar eventos con ejemplos, campos, significado, productor, consumidores conocidos y garantías de entrega.
Proteger datos sensibles en eventos, evitando replicar información personal o confidencial sin finalidad clara.
Validar eventos mediante schemas, pruebas de contrato, consumidores simulados o validadores en CI/CD.
Crear un catálogo de eventos de integración para una arquitectura .NET orientada a eventos.
Tema 18: Event-Driven Architecture: diseño de flujos asíncronos
Diseñar EDA como arquitectura donde servicios reaccionan a hechos de negocio, no como simple sustitución de llamadas HTTP por colas.
Identificar procesos que se benefician de asincronía: notificaciones, sincronización, reporting, workflows largos, integración y procesamiento intensivo.
Decidir entre eventos, comandos asíncronos, mensajes de tarea, colas punto a punto y publicación-suscripción.
Modelar flujos de negocio mediante eventos, estados, consumidores, reintentos, compensaciones y observabilidad.
Evitar coreografías incontroladas donde muchos servicios reaccionan sin visión global del proceso.
Evaluar cuándo conviene orquestación explícita mediante process manager o saga frente a coreografía distribuida.
Diseñar consumidores idempotentes, tolerantes a duplicados, mensajes tardíos y cambios de versión.
Incorporar tracing distribuido para seguir un flujo que atraviesa APIs, colas, workers y bases de datos.
Medir salud de EDA mediante lag, throughput, errores, DLQ, latencia de procesamiento y frescura de proyecciones.
Diseñar un flujo EDA completo con evento de integración, broker, consumidor, proyección y manejo de errores.
Tema 19: Brokers de mensajería en .NET: RabbitMQ, Kafka y Azure Service Bus
Comparar RabbitMQ, Apache Kafka y Azure Service Bus desde el punto de vista de patrones, operación, orden, retención, escalado y modelo de consumo.
Elegir broker según necesidad: colas de trabajo, pub/sub, eventos durables, streaming, integración cloud, transacciones o consumo masivo.
Implementar productores y consumidores .NET con abstracciones propias que no contaminen dominio ni aplicación.
Gestionar serialización, schemas, headers, metadata, versiones y compatibilidad entre productores y consumidores.
Diseñar reintentos, delayed retries, dead letter queues, parking queues y estrategias de recuperación.
Controlar confirmaciones, acknowledgements, offsets, commits y garantías de entrega según el broker elegido.
Monitorizar errores, lag, mensajes pendientes, throughput, consumidores caídos y saturación del broker.
Proteger brokers con autenticación, autorización, TLS, nombres de cola controlados y aislamiento por entorno.
Probar mensajería en local con Docker, Testcontainers o entornos dedicados de integración.
Crear una estrategia corporativa para elegir y operar brokers en proyectos .NET con criterios técnicos y de negocio.
Tema 20: Outbox Pattern para publicación fiable de eventos
Comprender el problema de doble escritura entre base de datos y broker cuando se modifica estado y se publica un evento.
Implementar Outbox para guardar eventos en la misma transacción que el cambio del agregado.
Diseñar una tabla Outbox con identificador, tipo, payload, metadata, estado, reintentos, errores y fecha de publicación.
Crear un background worker que lee eventos pendientes, publica al broker y actualiza estado de forma segura.
Gestionar reintentos, errores permanentes, bloqueo concurrente y publicación duplicada.
Asegurar que los consumidores son idempotentes, porque Outbox puede ofrecer publicación al menos una vez.
Separar eventos de dominio internos de eventos de integración publicados externamente.
Medir salud de Outbox con pendientes, edad máxima, errores, reintentos y throughput.
Crear runbooks para Outbox bloqueado, broker caído, payload inválido o acumulación excesiva.
Implementar un Outbox completo en .NET con EF Core, worker, broker y pruebas de integración.
Tema 21: Inbox Pattern, deduplicación e idempotencia de consumidores
Implementar Inbox para registrar mensajes procesados y evitar efectos secundarios duplicados ante reentregas.
Diseñar claves de idempotencia basadas en event ID, message ID, aggregate ID, versión o clave de negocio.
Controlar procesamiento concurrente de mensajes que afectan al mismo recurso, evitando condiciones de carrera.
Separar errores transitorios, errores de negocio y mensajes inválidos para decidir reintento, rechazo o DLQ.
Diseñar consumidores que puedan reejecutarse sin romper datos, enviar notificaciones duplicadas o modificar estado dos veces.
Guardar estado de procesamiento con timestamps, resultado, errores y trazabilidad para auditoría.
Aplicar deduplicación temporal cuando el volumen no permite retener indefinidamente todos los mensajes.
Probar consumidores con mensajes duplicados, desordenados, antiguos, futuros y de versiones diferentes.
Monitorizar duplicados, errores de idempotencia, conflictos de concurrencia y reintentos excesivos.
Implementar Inbox en un consumidor .NET conectado a un evento de integración realista.
Tema 22: Sagas, process managers y workflows distribuidos
Diferenciar saga, process manager, workflow, orquestación, coreografía y transacción distribuida.
Modelar procesos largos con varios pasos, estados intermedios, eventos, comandos, timeouts y compensaciones.
Diseñar sagas coreografiadas cuando los servicios pueden reaccionar a eventos sin coordinador central excesivo.
Diseñar process managers cuando se necesita visibilidad, estado de proceso, decisiones, timeouts o control explícito.
Evitar sagas invisibles repartidas en muchos handlers sin una representación clara del proceso.
Crear compensaciones de negocio cuando un paso posterior falla y no se puede hacer rollback técnico.
Gestionar timeouts, expiraciones, mensajes perdidos, reintentos, cancelaciones y reconciliación manual.
Persistir estado de saga de forma segura y observable, con correlación entre mensajes y proceso.
Probar sagas con escenarios de fallo en cada paso, duplicados, dependencia caída y recuperación posterior.
Implementar un proceso distribuido completo con saga, eventos, comandos, compensaciones y documentación de estados.
Tema 23: Event sourcing: cuándo aporta valor y cuándo no
Comprender event sourcing como almacenamiento del historial de cambios del agregado mediante eventos, no solo del estado actual.
Evaluar escenarios donde event sourcing aporta valor: auditoría completa, reconstrucción histórica, dominios ricos, trazabilidad y temporalidad.
Identificar escenarios donde event sourcing complica innecesariamente persistencia, queries, soporte y onboarding.
Diseñar eventos de agregado con intención de negocio, versionado, evolución de schema y compatibilidad.
Reconstruir estado de agregados a partir de streams de eventos, snapshots y reglas de aplicación.
Separar event sourcing de EDA, porque almacenar eventos como fuente de verdad no equivale automáticamente a publicar eventos de integración.
Crear proyecciones de lectura a partir de streams, controlando consistencia, reintentos, rebuild y errores.
Gestionar migración de eventos, upcasting, deprecación de campos y cambios de semántica.
Probar agregados event sourced con Given-When-Then para validar comportamiento a partir de eventos pasados.
Diseñar una prueba de concepto de event sourcing en .NET y decidir si compensa frente a persistencia tradicional.
Tema 24: Proyecciones, read models y consistencia eventual
Crear proyecciones que transforman eventos en modelos de lectura optimizados para consultas, informes o pantallas.
Diseñar read models independientes del modelo de escritura, ajustados a rendimiento, permisos y experiencia del consumidor.
Controlar retraso entre comando y lectura, explicando al usuario cuándo puede ver datos temporalmente desactualizados.
Implementar rebuild de proyecciones cuando cambia el modelo de lectura o se corrige un error de cálculo.
Gestionar errores de proyección mediante reintentos, checkpoints, DLQ, logs y posibilidad de reprocesado.
Versionar proyecciones y mantener compatibilidad durante cambios de schema o eventos.
Medir lag, edad máxima de proyección, errores, throughput y consistencia percibida.
Evitar que proyecciones contengan lógica de negocio crítica que debería protegerse en el modelo de escritura.
Crear pruebas de proyección con secuencias de eventos, duplicados, cambios de versión y casos límite.
Implementar una proyección completa para una pantalla de consulta CQRS, con actualización por eventos y recuperación ante fallo.
Tema 25: Anti-corruption layers e integración con legacy
Diseñar anti-corruption layers para proteger el nuevo modelo de dominio frente a sistemas legacy, APIs antiguas o bases compartidas.
Traducir modelos, estados, errores, identificadores y reglas entre contextos sin contaminar el dominio moderno.
Crear adaptadores específicos para legacy que encapsulan protocolos, formatos, inconsistencias y reglas heredadas.
Evitar que el modelo nuevo adopte nombres, estructuras y limitaciones del sistema antiguo por comodidad.
Diseñar sincronización gradual entre legacy y nuevos módulos mediante APIs, eventos, jobs, vistas o replicación controlada.
Gestionar datos inconsistentes, estados históricos y campos ambiguos que no encajan en el nuevo dominio.
Probar la capa anticorrupción con ejemplos reales, casos límite y errores típicos del sistema externo.
Documentar compromisos temporales para que no se conviertan en arquitectura permanente por accidente.
Usar anti-corruption layer como parte de migraciones Strangler Fig y modernización incremental.
Implementar una integración legacy protegida mediante puerto, adaptador, mapper, pruebas y documentación de decisiones.
Tema 26: Monolito modular con Hexagonal, DDD, EDA y CQRS
Diseñar un monolito modular como alternativa pragmática a microservicios cuando el equipo necesita modularidad sin complejidad distribuida.
Separar módulos por bounded context, con contratos internos claros, dependencias controladas y ownership funcional.
Aplicar arquitectura hexagonal dentro de cada módulo para proteger dominio, aplicación e infraestructura.
Usar eventos internos para comunicar módulos sin llamadas directas excesivas ni dependencias circulares.
Implementar CQRS dentro de módulos donde existen lecturas complejas o reglas de escritura diferenciadas.
Diseñar reglas de dependencia entre módulos mediante proyectos, namespaces, interfaces, analyzers o pruebas de arquitectura.
Evitar bases de datos lógicamente compartidas sin ownership, aunque físicamente vivan en la misma instancia.
Preparar el monolito modular para una posible extracción futura sin diseñar de antemano una arquitectura distribuida innecesaria.
Crear CI/CD y pruebas que validen módulos, contratos internos, eventos y dependencias permitidas.
Refactorizar un monolito desordenado hacia módulos con límites, eventos internos y contratos explícitos.
Tema 27: Microservicios con DDD, eventos y CQRS
Diseñar microservicios a partir de bounded contexts reales, no desde tablas, pantallas o capas técnicas.
Aplicar DDD táctico dentro de cada microservicio con agregados, value objects, eventos de dominio y casos de uso.
Usar eventos de integración para comunicar cambios relevantes entre servicios, evitando bases de datos compartidas.
Aplicar CQRS cuando un servicio necesita separar modelo transaccional, modelo de lectura y proyecciones.
Gestionar consistencia eventual entre servicios con Outbox, Inbox, Sagas, procesos de reconciliación y observabilidad.
Diseñar APIs y eventos como contratos públicos del servicio, con versionado, compatibilidad y documentación.
Evitar microservicios demasiado pequeños que no tienen autonomía real y aumentan coste operativo.
Definir ownership completo: código, datos, SLOs, despliegue, incidentes, documentación y evolución del servicio.
Probar microservicios con unitarias, integración, contrato, componente y flujos distribuidos.
Diseñar una arquitectura distribuida .NET con varios servicios, brokers, bases propias, eventos y read models.
Tema 28: Testing del dominio y reglas de negocio
Crear pruebas unitarias de entidades, value objects, agregados, políticas y servicios de dominio sin infraestructura externa.
Usar ejemplos de negocio como base para pruebas legibles que documenten comportamiento y no solo líneas de código.
Validar invariantes de agregado ante comandos válidos, comandos inválidos, estados extremos y reglas temporales.
Probar value objects con igualdad, inmutabilidad, validación, normalización y operaciones propias.
Verificar eventos de dominio generados por agregados cuando ocurre un hecho relevante.
Evitar mocks innecesarios en dominio puro, manteniendo pruebas rápidas, deterministas y expresivas.
Crear nombres de pruebas que expliquen comportamiento, condición y resultado esperado.
Incorporar casos límite descubiertos en producción o sesiones con negocio para aumentar valor de la suite.
Medir calidad de pruebas por capacidad de detectar regresiones en reglas críticas, no por cobertura superficial.
Construir una batería de pruebas de dominio para un agregado complejo con invariantes, eventos y errores de negocio.
Tema 29: Testing de aplicación, contratos y eventos
Probar command handlers y query handlers validando orquestación, autorización, transacciones, puertos y resultados.
Crear tests de aplicación con repositorios fake, infraestructura simulada o contenedores según nivel de confianza necesario.
Validar contratos HTTP con pruebas que aseguran códigos de estado, payloads, errores, versionado y permisos.
Crear pruebas de contrato para eventos de integración, verificando schema, campos obligatorios, metadata y compatibilidad.
Probar consumidores con mensajes duplicados, tardíos, inválidos, de versión antigua y con dependencias caídas.
Usar Testcontainers para bases, brokers y dependencias de integración cuando se requiere comportamiento realista.
Evitar tests end-to-end excesivos que mezclan demasiados servicios y fallan por causas difíciles de diagnosticar.
Crear pruebas de proyecciones y read models a partir de secuencias de eventos.
Integrar tests en CI/CD con ejecución diferenciada por rapidez, profundidad y criticidad.
Diseñar una estrategia completa de testing para arquitectura hexagonal, DDD, EDA y CQRS.
Tema 30: Seguridad, autorización y reglas de acceso en arquitecturas ricas
Separar autenticación, autorización técnica, permisos de negocio y reglas de dominio para evitar controles dispersos.
Evaluar dónde debe comprobarse cada permiso: API, capa de aplicación, política de dominio, servicio externo o base de datos.
Diseñar autorización por recurso, tenant, rol, claim, ownership, estado del agregado y acción solicitada.
Evitar ocultar botones en UI como sustituto de controles server-side en comandos, queries o APIs.
Propagar identidad y contexto de usuario en eventos solo cuando existe finalidad clara y datos permitidos.
Proteger eventos, logs, trazas y read models para que no expongan datos sensibles por conveniencia técnica.
Auditar operaciones críticas: cambios de permisos, aprobaciones, pagos, borrados, exportaciones y acciones administrativas.
Crear pruebas de autorización para comandos, queries, APIs, consumidores y casos límite.
Aplicar threat modeling ligero sobre bounded contexts, eventos, APIs y procesos distribuidos.
Documentar matriz de permisos y decisiones de seguridad para que negocio, desarrollo y AppSec compartan criterio.
Tema 31: Observabilidad de comandos, eventos y flujos distribuidos
Instrumentar comandos, queries, eventos, consumidores, proyecciones y adaptadores para entender cómo se comporta el sistema.
Añadir correlation ID y causation ID desde la entrada HTTP hasta eventos, workers, proyecciones y read models.
Crear trazas distribuidas que conectan API, command handler, agregado, Outbox, broker, consumidor y proyección.
Medir latencia de comandos, duración de handlers, tiempo de publicación, lag de consumidores y frescura de proyecciones.
Diseñar logs estructurados con nombres de caso de uso, agregado, evento, tenant, operación y resultado.
Evitar incluir payloads completos, datos personales o secretos en logs y trazas.
Crear dashboards para procesos EDA y CQRS: comandos fallidos, eventos pendientes, Outbox, Inbox, DLQ, lag y read models.
Diseñar alertas accionables sobre proyecciones bloqueadas, eventos acumulados, errores de consumidor y comandos críticos fallidos.
Preparar runbooks para fallos de evento, Outbox atascado, proyección corrupta o inconsistencia detectada.
Integrar observabilidad como requisito de arquitectura, no como añadido final del despliegue.
Tema 32: CI/CD, quality gates y reglas de arquitectura
Crear pipelines que compilan, prueban, analizan, empaquetan y validan soluciones con múltiples módulos, servicios y adaptadores.
Añadir quality gates para pruebas de dominio, aplicación, contratos, eventos, seguridad, cobertura crítica y migraciones.
Ejecutar pruebas de arquitectura para validar dependencias permitidas entre dominio, aplicación, infraestructura y API.
Revisar cambios de eventos y contratos en CI/CD para evitar breaking changes no intencionados.
Generar artefactos versionados: paquetes, imágenes, contratos OpenAPI, schemas de eventos y documentación.
Integrar análisis estático, dependency scanning, secret scanning y comprobaciones de licencias cuando el entorno lo requiere.
Separar pipelines rápidos de PR y pipelines profundos de release, manteniendo feedback útil para desarrolladores.
Usar entornos efímeros o contenedores para validar integración con bases, brokers y servicios auxiliares.
Documentar pipelines con owners, variables, secretos, permisos, validaciones y procedimiento ante fallo.
Crear un pipeline de referencia para un sistema .NET con Hexagonal, DDD, EDA y CQRS.
Tema 33: Refactorización desde arquitectura n-capas hacia hexagonal
Analizar una aplicación n-capas típica con controladores, servicios, repositorios, DTOs compartidos y lógica dispersa.
Identificar qué reglas pertenecen al dominio, qué coordinación pertenece a aplicación y qué detalles deben moverse a infraestructura.
Crear pruebas de caracterización antes de mover lógica crítica para asegurar que el comportamiento actual se conserva.
Extraer value objects, entidades y agregados desde modelos anémicos o entidades EF demasiado expuestas.
Sustituir servicios genéricos por casos de uso explícitos con comandos, queries y handlers.
Introducir puertos y adaptadores progresivamente, evitando reestructuraciones masivas sin retorno inmediato.
Separar DTOs de API, modelos de dominio y entidades de persistencia donde el acoplamiento genera fricción.
Crear eventos de dominio para desacoplar efectos secundarios internos antes de pasar a eventos de integración.
Medir progreso por reducción de acoplamiento, aumento de pruebas útiles, claridad de dependencias y facilidad de cambio.
Diseñar un plan de refactorización incremental con fases, riesgos, PRs pequeños y criterios de éxito.
Tema 34: Migración hacia CQRS y EDA sin reescrituras masivas
Seleccionar casos de uso donde CQRS o EDA aportan valor claro, evitando aplicar ambos patrones a todo el sistema de forma indiscriminada.
Introducir comandos y queries en zonas de alta complejidad, manteniendo CRUD simple donde no hay beneficio.
Crear read models para pantallas críticas, informes o consultas pesadas sin reemplazar toda la capa de datos de golpe.
Publicar eventos de integración desde un Outbox sin cambiar inmediatamente todos los consumidores existentes.
Introducir consumidores asíncronos para efectos secundarios que antes bloqueaban el flujo principal.
Diseñar convivencia entre módulos síncronos y flujos event-driven durante la transición.
Controlar consistencia eventual y expectativas de usuario antes de separar escritura y lectura.
Crear pruebas y dashboards para validar que la migración no rompe comportamiento ni degrada experiencia.
Documentar decisiones temporales, compromisos y criterios para retirar código antiguo.
Construir una hoja de ruta de migración hacia CQRS y EDA por capacidad de negocio, riesgo y valor.
Tema 35: Decisiones arquitectónicas, ADRs y documentación viva
Crear ADRs para decisiones sobre arquitectura hexagonal, bounded contexts, CQRS, eventos, brokers, persistencia y migraciones.
Documentar contexto, problema, alternativas, decisión, consecuencias, riesgos y fecha de revisión.
Generar diagramas C4, diagramas de secuencia, mapas de contexto y flujos de eventos para explicar la arquitectura.
Mantener documentación cercana al repositorio y vinculada a código, contratos, eventos y pruebas.
Diferenciar documentación vigente, histórica, exploratoria y obsoleta para evitar confusión en equipos nuevos.
Crear glosarios de lenguaje ubicuo por bounded context, con ejemplos y términos prohibidos o ambiguos.
Documentar eventos con productor, consumidores, payload, versión, compatibilidad, metadata y garantía de entrega.
Incluir decisiones de seguridad, consistencia, persistencia, testing y observabilidad en la documentación arquitectónica.
Automatizar validaciones de documentación mínima cuando cambian APIs, eventos o decisiones relevantes.
Construir un repositorio de arquitectura vivo para un sistema .NET empresarial basado en DDD, EDA y CQRS.
Tema 36: Gobierno técnico, estándares y adopción por equipos
Definir estándares mínimos para nuevos módulos o servicios: dominio, casos de uso, puertos, adaptadores, pruebas, eventos y observabilidad.
Crear plantillas de servicio, módulo o caso de uso que reduzcan variabilidad sin imponer burocracia excesiva.
Establecer criterios de revisión en pull requests para arquitectura hexagonal, DDD, CQRS, eventos y persistencia.
Diseñar formación interna para que perfiles junior, senior, tech leads, QA y DevOps compartan lenguaje y expectativas.
Crear comunidades de práctica para revisar patrones, errores, decisiones, eventos, modelos y problemas de producción.
Evitar que el equipo use términos como agregado, evento, saga o puerto de forma superficial y contradictoria.
Medir adopción por calidad de cambios, reducción de deuda, consistencia de módulos, pruebas útiles y menor tiempo de onboarding.
Definir excepciones aceptables cuando el coste de aplicar un patrón completo supera el beneficio.
Revisar periódicamente estándares para adaptarlos a cambios de producto, equipo, tecnología y operación.
Crear una guía corporativa de arquitectura .NET con ejemplos reales, anti-patrones y checklist de calidad.
Tema 37: Rendimiento y escalabilidad en DDD, CQRS y EDA
Analizar impacto de agregados grandes, transacciones largas, consultas complejas, eventos masivos y proyecciones pesadas.
Diseñar agregados pequeños y consistentes que reducen bloqueos, conflictos de concurrencia y carga innecesaria.
Optimizar read models para consultas frecuentes sin comprometer reglas de escritura del dominio.
Usar proyecciones, materialized views, caches y modelos denormalizados cuando la lectura necesita escala o baja latencia.
Controlar backpressure en consumidores cuando la entrada de eventos supera la capacidad de procesamiento.
Medir lag, throughput, latencia de comando, tiempo de consulta, errores de consumidor y coste de proyección.
Evitar que CQRS se use para ocultar queries mal diseñadas, índices ausentes o modelos de datos sin ownership.
Evaluar escalado independiente de comandos, queries, consumidores, proyecciones y brokers.
Diseñar estrategias de particionado, snapshots, batching y reprocesado para flujos con alto volumen.
Crear pruebas de rendimiento específicas para comandos críticos, queries pesadas y pipelines de eventos.
Tema 38: Errores frecuentes y anti-patrones
Detectar modelos anémicos donde las entidades solo contienen datos y toda la lógica vive en servicios procedurales.
Evitar repositorios genéricos que empobrecen el dominio y convierten persistencia en una API CRUD universal.
Reconocer CQRS accidental cuando se duplican modelos sin una razón clara de rendimiento, complejidad o escalado.
Identificar eventos pobres como `EntityUpdated` que no expresan significado de negocio ni ayudan a consumidores.
Evitar sagas ocultas formadas por handlers sueltos, sin estado, sin compensaciones y sin trazabilidad.
Detectar abstracciones hexagonales innecesarias que solo añaden interfaces, mappers y carpetas sin reducir acoplamiento.
Corregir dominios contaminados por EF Core, frameworks, DTOs, atributos de serialización o clientes externos.
Evitar microservicios que comparten base de datos, librerías de dominio o modelos internos y no tienen autonomía real.
Reconocer documentación arquitectónica que describe intención pero no coincide con dependencias, código, eventos o despliegues.
Crear una checklist de anti-patrones para revisar proyectos .NET antes de escalar la arquitectura.
Tema 39: Proyecto final integrador: sistema .NET con Hexagonal, DDD, EDA y CQRS
Definir un dominio empresarial realista con reglas complejas, varios bounded contexts, operaciones críticas, consultas exigentes y procesos asíncronos.
Diseñar arquitectura hexagonal con dominio, aplicación, puertos, adaptadores, API, infraestructura, persistencia, mensajería y pruebas.
Modelar agregados, entidades, value objects, servicios de dominio, políticas e invariantes con lenguaje ubicuo y pruebas unitarias.
Implementar comandos, command handlers, queries, query handlers, read models y proyecciones aplicando CQRS donde aporta valor.
Crear domain events e integration events con contratos, metadata, versionado, documentación y pruebas de compatibilidad.
Implementar Outbox, Inbox, consumidores idempotentes, manejo de errores, DLQ y observabilidad de flujos event-driven.
Diseñar una saga o process manager para un proceso distribuido con estados, timeouts, compensaciones y recuperación.
Integrar persistencia con EF Core, adaptadores de infraestructura, repositorios orientados a agregados y migraciones controladas.
Preparar CI/CD con pruebas de dominio, aplicación, integración, contratos, eventos, reglas de arquitectura y análisis de seguridad.
Presentar el proyecto con ADRs, diagramas C4, mapa de contexto, flujos de eventos, decisiones, trade-offs, riesgos y roadmap de evolución.
Forma a tu equipo sin coste para tu empresa. Este curso de Arquitectura de Hexagonal, DDD, EDA y CQRS para .Net es hasta 100% bonificable a través de FUNDAE.
Potencia las competencias clave de tus profesionales.
Accede a una formación práctica, actualizada y orientada a resultados.
Prepara a tu equipo para los retos del entorno laboral actual.
Nos ocupamos de la gestión con FUNDAE si tu empresa lo necesita.
A medida
Formación en Arquitectura de Hexagonal, DDD, EDA y CQRS para .Net a medida
Descubre el mejor curso de Arquitectura de Hexagonal, DDD, EDA y CQRS para .Net para empresas con nuestra Aula Virtual Personalizada:
Sesiones en vivo por videoconferencia.
Temario totalmente personalizado.
Fechas y horarios adaptados a tu empresa.
Acceso a grabaciones.
Aprende practicando
Totalmente Práctico y Aplicable
Formación diseñada para que apliques cada concepto en situaciones reales de tu trabajo, con enfoque práctico y útil desde el primer momento.
Aprendizaje 100% práctico, enfocado en lo que realmente necesitas.
Casos reales y ejercicios adaptados a tu entorno profesional.
Aplica cada conocimiento directamente en tus tareas diarias.
Mejora tu rendimiento y el de tu equipo desde el primer día.
¿Por qué un curso en Arquitectura de Hexagonal, DDD, EDA y CQRS para .Net?
Una plataforma practica, con IA integrada y pensada para que mejores desarrollando. Se adapta a tu ritmo, te corrige al instante y te muestra tu progreso real.
Correccion magica
Feedback inteligente
Aprende de cada acierto y fallo con explicaciones claras
Analizar por qué muchas aplicaciones .NET empiezan limpias y terminan acopladas por decisiones pequeñas repetidas: servicios genéricos, lógica en controladores, modelos compartidos y dependencias cruzadas.
Diferenciar arquitectura n-capas, clean architecture, arquitectura hexagonal, arquitectura cebolla, DDD, CQRS y EDA para entender qué resuelve cada enfoque y dónde se solapan.
Reconocer señales de mala arquitectura: cambios simples que tocan demasiados archivos, tests frágiles, reglas duplicadas, APIs que filtran base de datos y servicios imposibles de aislar.
Valorar cuándo una arquitectura más elaborada aporta retorno y cuándo una solución simple, modular y bien probada resulta más adecuada.
Situar .NET 10, ASP.NET Core, EF Core, workers, APIs y mensajería dentro de una arquitectura empresarial moderna y mantenible.
Revisar atributos de calidad que deben guiar el diseño: mantenibilidad, testabilidad, seguridad, observabilidad, rendimiento, escalabilidad y facilidad de despliegue.
Traducir problemas de negocio a decisiones técnicas sin caer en abstracciones genéricas que nadie entiende ni mantiene.
Crear criterios de diseño para evitar acoplamiento accidental entre UI, aplicación, dominio, infraestructura, persistencia y mensajería.
Definir qué significa “arquitectura preparada para cambio” en un sistema .NET que evoluciona durante años.
Elaborar un diagnóstico inicial de una aplicación de ejemplo, identificando puntos de deuda, dependencias fuertes y oportunidades de mejora.
Analizar por qué muchas aplicaciones .NET empiezan limpias y terminan acopladas por decisiones pequeñas repetidas: servicios genéricos, lógica en controladores, modelos compartidos y dependencias cruzadas.
Diferenciar arquitectura n-capas, clean architecture, arquitectura hexagonal, arquitectura cebolla, DDD, CQRS y EDA para entender qué resuelve cada enfoque y dónde se solapan.
Reconocer señales de mala arquitectura: cambios simples que tocan demasiados archivos, tests frágiles, reglas duplicadas, APIs que filtran base de datos y servicios imposibles de aislar.
Valorar cuándo una arquitectura más elaborada aporta retorno y cuándo una solución simple, modular y bien probada resulta más adecuada.
Situar .NET 10, ASP.NET Core, EF Core, workers, APIs y mensajería dentro de una arquitectura empresarial moderna y mantenible.
Revisar atributos de calidad que deben guiar el diseño: mantenibilidad, testabilidad, seguridad, observabilidad, rendimiento, escalabilidad y facilidad de despliegue.
Traducir problemas de negocio a decisiones técnicas sin caer en abstracciones genéricas que nadie entiende ni mantiene.
Crear criterios de diseño para evitar acoplamiento accidental entre UI, aplicación, dominio, infraestructura, persistencia y mensajería.
Definir qué significa “arquitectura preparada para cambio” en un sistema .NET que evoluciona durante años.
Elaborar un diagnóstico inicial de una aplicación de ejemplo, identificando puntos de deuda, dependencias fuertes y oportunidades de mejora.
Tema 1: Fundamentos de arquitectura evolutiva en .NET
Analizar por qué muchas aplicaciones .NET empiezan limpias y terminan acopladas por decisiones pequeñas repetidas: servicios genéricos, lógica en controladores, modelos compartidos y dependencias cruzadas.
Diferenciar arquitectura n-capas, clean architecture, arquitectura hexagonal, arquitectura cebolla, DDD, CQRS y EDA para entender qué resuelve cada enfoque y dónde se solapan.
Reconocer señales de mala arquitectura: cambios simples que tocan demasiados archivos, tests frágiles, reglas duplicadas, APIs que filtran base de datos y servicios imposibles de aislar.
Valorar cuándo una arquitectura más elaborada aporta retorno y cuándo una solución simple, modular y bien probada resulta más adecuada.
Situar .NET 10, ASP.NET Core, EF Core, workers, APIs y mensajería dentro de una arquitectura empresarial moderna y mantenible.
Revisar atributos de calidad que deben guiar el diseño: mantenibilidad, testabilidad, seguridad, observabilidad, rendimiento, escalabilidad y facilidad de despliegue.
Traducir problemas de negocio a decisiones técnicas sin caer en abstracciones genéricas que nadie entiende ni mantiene.
Crear criterios de diseño para evitar acoplamiento accidental entre UI, aplicación, dominio, infraestructura, persistencia y mensajería.
Definir qué significa “arquitectura preparada para cambio” en un sistema .NET que evoluciona durante años.
Elaborar un diagnóstico inicial de una aplicación de ejemplo, identificando puntos de deuda, dependencias fuertes y oportunidades de mejora.
Tema 2: Arquitectura Hexagonal: puertos, adaptadores y límites claros
Comprender la arquitectura hexagonal como forma de proteger el núcleo de negocio frente a detalles externos como frameworks, bases de datos, colas, APIs o UI.
Diferenciar puertos de entrada, puertos de salida, adaptadores primarios y adaptadores secundarios con ejemplos reales en ASP.NET Core.
Diseñar el dominio y la aplicación como centro del sistema, evitando que Entity Framework, controladores o clientes HTTP dicten el modelo de negocio.
Crear adaptadores de entrada para APIs REST, gRPC, workers, colas, comandos CLI o pruebas automatizadas sin cambiar el caso de uso.
Crear adaptadores de salida para persistencia, mensajería, servicios externos, almacenamiento, notificaciones y APIs de terceros.
Evitar interfaces innecesarias creadas solo por dogma, distinguiendo abstracciones útiles de capas artificiales.
Aplicar inversión de dependencias para que el núcleo declare necesidades y la infraestructura proporcione implementaciones.
Diseñar ensamblados, proyectos y namespaces que refuercen el límite arquitectónico en lugar de dejarlo solo como intención.
Revisar errores habituales: puertos demasiado genéricos, adaptadores con lógica de negocio, dominio dependiente de EF Core y casos de uso anémicos.
Crear una plantilla base de arquitectura hexagonal .NET con proyectos, dependencias, tests y reglas de referencia.
Tema 3: Organización de soluciones .NET por capas, módulos y contexto
Diseñar una solución .NET con proyectos separados para dominio, aplicación, infraestructura, API, contracts, workers y pruebas.
Evaluar cuándo conviene organizar por capas técnicas, por módulos funcionales, por vertical slices o por bounded contexts.
Definir dependencias permitidas entre proyectos para impedir que infraestructura, API o persistencia contaminen el dominio.
Crear reglas de visibilidad interna usando namespaces, `internal`, convenciones, analyzers o pruebas de arquitectura cuando aporte valor.
Separar contratos públicos, DTOs internos, eventos, comandos, queries y modelos de dominio para evitar acoplamientos silenciosos.
Diseñar una estructura que soporte monolito modular y pueda evolucionar hacia microservicios si el dominio y el equipo lo justifican.
Evitar carpetas genéricas como “Services”, “Helpers” o “Managers” que terminan acumulando responsabilidades ambiguas.
Preparar convenciones de nombres para casos de uso, comandos, eventos, adaptadores, repositorios y proyecciones.
Documentar la arquitectura de solución para que nuevos desarrolladores entiendan dónde debe vivir cada responsabilidad.
Revisar una solución desordenada y proponer una reorganización incremental sin romper todo el sistema de golpe.
Tema 4: DDD estratégico: dominios, subdominios y bounded contexts
Identificar el dominio principal de la empresa y separar subdominios core, supporting y generic para decidir dónde merece la pena invertir más diseño.
Comprender bounded context como límite semántico donde un concepto tiene un significado concreto y no necesariamente igual al de otro contexto.
Detectar límites de contexto a partir de lenguaje, procesos, datos, equipos, reglas, integraciones, conflictos y cambios frecuentes.
Crear mapas de contexto con relaciones upstream, downstream, customer-supplier, conformist, shared kernel y anti-corruption layer.
Evitar que los bounded contexts se definan por tablas, pantallas o estructura organizativa sin analizar el lenguaje de negocio.
Traducir límites estratégicos a módulos, servicios, APIs, eventos, contratos, ownership y decisiones de despliegue.
Diseñar conversaciones con negocio para descubrir términos ambiguos, reglas escondidas y conceptos que cambian según departamento.
Analizar cuándo un concepto compartido debe duplicarse, traducirse, sincronizarse o mantenerse como shared kernel.
Documentar decisiones estratégicas mediante mapas, ADRs, glosarios y ejemplos de casos de uso.
Aplicar DDD estratégico a un caso empresarial, separando dominios, responsabilidades, relaciones y riesgos de acoplamiento.
Tema 5: Lenguaje ubicuo y modelado colaborativo
Construir lenguaje ubicuo entre negocio y desarrollo para que entidades, eventos, comandos, reglas y errores expresen conceptos reales.
Detectar términos conflictivos como “cliente”, “pedido”, “estado”, “cuenta” o “usuario” cuando significan cosas distintas en áreas diferentes.
Transformar conversaciones funcionales en modelos de dominio, ejemplos, invariantes, eventos y casos de uso verificables.
Usar técnicas como Event Storming, ejemplos concretos, escenarios y reglas de negocio para descubrir comportamiento antes de diseñar clases.
Evitar modelos generados desde la base de datos cuando la estructura de tablas no refleja correctamente el dominio.
Documentar glosarios vivos con términos, significado, contexto, ejemplos, reglas y equivalencias entre áreas.
Revisar nombres de clases, métodos, eventos y comandos para que el código sea legible por perfiles técnicos y funcionales.
Resolver ambigüedades antes de codificar, porque una palabra mal entendida puede contaminar APIs, eventos, datos y reporting.
Crear ejemplos de uso como pruebas de aceptación que sirvan de puente entre lenguaje de negocio y código.
Mantener el lenguaje ubicuo a medida que el producto evoluciona, evitando que la documentación quede separada del código real.
Tema 6: DDD táctico: entidades, value objects y agregados
Diseñar entidades con identidad, ciclo de vida, comportamiento y reglas, evitando modelos anémicos que solo contienen propiedades públicas.
Crear value objects inmutables para conceptos como dinero, email, rango de fechas, porcentaje, dirección o identificadores tipados.
Modelar agregados como fronteras de consistencia que protegen invariantes de negocio y controlan cambios internos.
Definir aggregate roots que actúan como punto de entrada para modificar un conjunto de entidades y value objects.
Evitar agregados gigantes que intentan cubrir todo el proceso de negocio y bloquean rendimiento, concurrencia y escalabilidad.
Diseñar invariantes que se aplican de forma síncrona dentro del agregado y reglas que pueden resolverse mediante procesos posteriores.
Usar constructores, métodos de fábrica y métodos de comportamiento para impedir estados inválidos desde el propio dominio.
Persistir value objects con EF Core mediante owned entity types cuando encaja con el modelo de datos. Microsoft documenta owned entity types como forma habitual de mapear value objects en EF Core.
Revisar diferencias entre pureza del modelo de dominio y necesidades pragmáticas de persistencia, serialización y rendimiento.
Implementar un agregado completo con entidades, value objects, invariantes, eventos de dominio y pruebas unitarias.
Tema 7: Servicios de dominio, políticas y reglas complejas
Diferenciar lógica de entidad, lógica de agregado, domain service, application service y policy para ubicar cada regla en el lugar correcto.
Crear servicios de dominio solo cuando una operación relevante no pertenece naturalmente a una entidad o value object concreto.
Modelar políticas de negocio como objetos explícitos cuando una decisión depende de varios factores, reglas, estados o configuraciones.
Evitar el anti-patrón de “DomainService” genérico donde acaba cualquier lógica que no se supo modelar.
Diseñar reglas complejas con nombres expresivos, pruebas unitarias y ejemplos de negocio que faciliten revisión y mantenimiento.
Separar reglas puras de dominio de llamadas a infraestructura, proveedores externos, bases de datos o APIs.
Utilizar especificaciones o predicados de negocio cuando aporten claridad, composición y reutilización real.
Gestionar reglas temporales, excepciones comerciales, condiciones por país, permisos y variaciones por cliente sin ensuciar el modelo.
Documentar decisiones de modelado cuando una regla se ubica fuera del agregado por rendimiento, consistencia o integración.
Refactorizar un caso de uso con lógica dispersa hacia entidades, value objects, políticas y servicios de dominio bien delimitados.
Tema 8: Casos de uso y capa de aplicación
Definir la capa de aplicación como orquestadora de casos de uso, coordinación de transacciones, puertos, autorizaciones, eventos y persistencia.
Diseñar comandos y queries como contratos de intención, no como simples copias de DTOs de API o formularios.
Implementar handlers que coordinan dominio e infraestructura sin contener reglas de negocio que deberían vivir en agregados o políticas.
Gestionar transacciones de unidad de trabajo en la capa adecuada, evitando transacciones distribuidas innecesarias.
Separar validación superficial de entrada, validación de caso de uso y validación de invariantes del dominio.
Incorporar autorización contextual antes de ejecutar operaciones que modifican estado o devuelven datos sensibles.
Diseñar resultados de caso de uso con errores controlados, mensajes de negocio y trazabilidad sin lanzar excepciones para flujos esperados.
Evitar application services gigantes que se convierten en nuevos monolitos dentro del monolito.
Crear pruebas de aplicación con mocks de puertos, repositorios fake o contenedores cuando sea necesario validar integración real.
Implementar un caso de uso completo desde entrada hasta dominio, persistencia, evento, respuesta y pruebas.
Tema 9: Puertos de salida, repositorios y persistencia desacoplada
Diseñar repositorios orientados a agregados, no a tablas, evitando `GenericRepository<T>` cuando oculta intenciones y empobrece el modelo.
Definir puertos de salida para persistencia, mensajería, servicios externos, calendario, email, archivos, pagos o sistemas internos.
Crear interfaces en el núcleo que expresan necesidades del caso de uso, no detalles técnicos de la infraestructura.
Implementar adaptadores con EF Core, Dapper, APIs externas o almacenamiento según necesidades de cada puerto.
Evitar que IQueryable, DbContext, entidades EF o expresiones de infraestructura se filtren hacia aplicación o dominio sin control.
Gestionar transacciones y unidad de trabajo con una frontera clara entre caso de uso, repositorio y persistencia.
Diseñar consultas complejas separadas del repositorio de agregado cuando pertenecen al modelo de lectura o reporting.
Controlar rendimiento de persistencia sin sacrificar el modelo de dominio por optimizaciones prematuras.
Crear dobles de prueba para puertos de salida que permitan validar casos de uso sin infraestructura real.
Refactorizar una persistencia acoplada a EF Core hacia puertos, adaptadores y repositorios orientados al dominio.
Tema 10: Entity Framework Core en arquitecturas DDD
Mapear entidades, value objects, agregados y relaciones en EF Core sin obligar al dominio a parecer una tabla.
Configurar Fluent API para separar detalles de persistencia del modelo de dominio y mantener un diseño más expresivo.
Usar backing fields, owned types, conversiones, índices, constraints y configuraciones por entidad cuando el modelo lo requiere.
Gestionar colecciones privadas y métodos de dominio para proteger invariantes sin exponer setters públicos innecesarios.
Diferenciar el modelo transaccional del dominio y modelos optimizados para lectura, reporting o búsquedas.
Controlar problemas de lazy loading, tracking, N+1, consultas pesadas y carga accidental de agregados grandes.
Diseñar migraciones seguras y revisables para cambios en agregados, value objects y relaciones.
Separar configuraciones EF Core en infraestructura, evitando dependencias desde dominio hacia paquetes de persistencia.
Preparar tests de persistencia para validar mappings, constraints, conversiones, queries y migraciones críticas.
Crear una guía de EF Core para DDD con decisiones permitidas, compromisos pragmáticos y anti-patrones habituales.
Tema 11: Arquitectura Hexagonal con ASP.NET Core APIs
Implementar adaptadores de entrada HTTP con ASP.NET Core sin colocar lógica de negocio dentro de controllers o minimal APIs.
Traducir requests HTTP a comandos o queries de aplicación, controlando validación, autenticación, autorización y errores.
Diseñar respuestas HTTP coherentes con casos de uso: éxito, errores de validación, conflictos, no encontrado, prohibido y fallo inesperado.
Usar DTOs de API separados de comandos internos cuando el contrato público necesita estabilidad o transformación.
Crear endpoints finos que delegan en la aplicación y se mantienen fáciles de leer, probar y modificar.
Integrar filtros, middleware, exception handling y ProblemDetails sin contaminar dominio ni handlers.
Diseñar APIs versionables que no rompen consumidores cuando evoluciona el modelo interno.
Añadir OpenAPI como contrato de entrada, documentación y base para pruebas de contrato.
Proteger endpoints con políticas de autorización, antiforgery cuando aplique, rate limiting y validación server-side.
Construir un adaptador HTTP completo sobre un caso de uso hexagonal, con errores, documentación y pruebas.
Tema 12: CQRS conceptual: separar intención, lectura y escritura
Comprender CQRS como separación entre operaciones que modifican estado y operaciones que consultan información.
Analizar el patrón CQRS desde la definición de Microsoft: separar operaciones de lectura y escritura en modelos diferentes permite optimizar cada uno de forma independiente.
Identificar escenarios donde CQRS aporta valor: reglas de escritura complejas, lecturas optimizadas, escalado separado, permisos distintos o modelos de consulta ricos.
Reconocer cuándo CQRS sería excesivo, especialmente en CRUD simple, aplicaciones pequeñas o dominios con poca complejidad.
Diseñar comandos que expresan intención de negocio, no operaciones técnicas como “UpdateEntity”.
Diseñar queries que devuelven modelos ajustados a la pantalla, informe, API o consumidor.
Separar validaciones, autorizaciones, transacciones, eventos y persistencia en flujos de comando y consulta.
Evitar que CQRS se convierta en duplicación innecesaria de todo el sistema sin beneficio claro.
Documentar decisiones sobre CQRS: alcance, modelo de consistencia, read models, sincronización y coste operativo.
Refactorizar un servicio CRUD hacia CQRS simplificado, mostrando qué mejora y qué complejidad añade.
Tema 13: Implementación de comandos y command handlers en .NET
Crear comandos como objetos de intención con datos mínimos, nombres de negocio y validación inicial clara.
Implementar command handlers que orquestan carga de agregado, ejecución de comportamiento, persistencia y publicación de eventos.
Separar validación sintáctica de reglas de dominio, evitando duplicar invariantes en capas externas.
Diseñar resultados de comando con identificadores, errores de negocio, conflictos, estado final o información mínima necesaria.
Gestionar transacciones locales alrededor del cambio de estado y la escritura de eventos Outbox cuando corresponda.
Incorporar idempotencia en comandos que pueden recibirse más de una vez por reintentos, integraciones o usuarios.
Añadir autorización por caso de uso antes de modificar el agregado o ejecutar acciones sensibles.
Evitar command handlers que consultan demasiados repositorios, aplican reglas de dominio dispersas o coordinan procesos largos sin patrón claro.
Crear pipelines de comportamiento para validación, logging, métricas, transacciones, idempotencia o auditoría cuando aportan consistencia.
Implementar un flujo de comando completo con pruebas unitarias, pruebas de aplicación, persistencia y publicación de evento.
Tema 14: Queries, read models y proyecciones optimizadas
Diseñar queries orientadas a consumo, pantalla, API, informe, dashboard o proceso, sin forzar el agregado transaccional como modelo de lectura.
Crear read models que contienen exactamente la información necesaria para responder una consulta de forma eficiente y estable.
Implementar query handlers con EF Core, Dapper, SQL optimizado, vistas, materialized views o servicios especializados según necesidad.
Separar seguridad de lectura, filtros, paginación, ordenación, búsqueda y permisos por campo o recurso.
Evitar reutilizar entidades de dominio como DTOs de lectura cuando eso rompe encapsulación y acopla UI a persistencia.
Diseñar proyecciones actualizadas por eventos cuando la lectura necesita independencia, rendimiento o estructura distinta.
Controlar consistencia eventual entre escritura y lectura, explicando al usuario qué puede estar temporalmente desactualizado.
Optimizar consultas con índices, paginación, filtros server-side y reducción de overfetching.
Crear pruebas sobre read models para validar shape, filtros, permisos, orden, paginación y datos derivados.
Implementar un modelo de lectura completo para una pantalla empresarial compleja, conectado a eventos o persistencia directa.
Tema 15: Mediator pattern, pipelines y coordinación interna
Evaluar cuándo usar un mediator interno para separar controladores de handlers, aplicar pipelines y ordenar flujos de comandos y queries.
Diferenciar el patrón mediator de librerías concretas, evitando dependencia excesiva de una herramienta si el diseño no lo requiere.
Crear pipelines para validación, logging, autorización, transacciones, métricas, idempotencia, retries internos o auditoría.
Evitar pipelines opacos donde el comportamiento real del caso de uso queda repartido en demasiadas piezas difíciles de depurar.
Diseñar convenciones de nombres, carpetas y handlers para que comandos, queries y eventos sean fáciles de localizar.
Controlar errores y excepciones dentro del pipeline, distinguiendo errores de negocio, validación, permisos y fallos inesperados.
Añadir trazabilidad y métricas por comando y query para saber qué operaciones son lentas, fallan o consumen más recursos.
Crear tests de pipeline para validar que los comportamientos transversales se aplican como se espera.
Evaluar alternativas más simples cuando el equipo no necesita mediator y puede usar servicios de aplicación explícitos.
Implementar un pipeline completo de comandos y queries con validación, transacción, logging y métricas.
Tema 16: Domain events: comportamiento interno del dominio
Comprender los domain events como hechos relevantes ocurridos dentro del dominio que permiten desacoplar efectos secundarios internos.
Aplicar eventos de dominio para comunicar cambios entre agregados o procesos dentro del mismo bounded context.
Diseñar eventos con nombres en pasado, datos suficientes y semántica de negocio clara.
Evitar eventos de dominio que se convierten en simples notificaciones técnicas sin significado para el negocio.
Registrar eventos dentro del agregado al ejecutar comportamiento, manteniendo la intención cerca de la regla que la produce.
Publicar eventos de dominio después de persistir cambios o dentro del flujo transaccional según la estrategia del equipo.
Usar handlers de eventos de dominio para actualizar otros agregados, lanzar políticas, crear tareas o preparar eventos de integración.
Controlar efectos secundarios para no ocultar procesos críticos en cadenas de handlers difíciles de seguir.
Probar que los agregados generan eventos correctos ante comportamientos relevantes y no ante simples cambios de datos.
Implementar un flujo con domain event, handler interno, persistencia y prueba de comportamiento del agregado.
Tema 17: Integration events: comunicación entre bounded contexts
Diferenciar domain events de integration events, entendiendo que los segundos cruzan límites de contexto, servicio o sistema.
Diseñar eventos de integración como contratos públicos con estabilidad, versionado, documentación y ownership.
Evitar publicar directamente entidades de dominio o modelos EF Core como payloads de evento.
Definir envelopes de evento con identificador, tipo, versión, timestamp, correlation ID, causation ID, source y metadata.
Diseñar payloads suficientes para consumidores sin exponer detalles internos innecesarios.
Gestionar versionado de eventos mediante compatibilidad hacia atrás, evolución aditiva y deprecación controlada.
Documentar eventos con ejemplos, campos, significado, productor, consumidores conocidos y garantías de entrega.
Proteger datos sensibles en eventos, evitando replicar información personal o confidencial sin finalidad clara.
Validar eventos mediante schemas, pruebas de contrato, consumidores simulados o validadores en CI/CD.
Crear un catálogo de eventos de integración para una arquitectura .NET orientada a eventos.
Tema 18: Event-Driven Architecture: diseño de flujos asíncronos
Diseñar EDA como arquitectura donde servicios reaccionan a hechos de negocio, no como simple sustitución de llamadas HTTP por colas.
Identificar procesos que se benefician de asincronía: notificaciones, sincronización, reporting, workflows largos, integración y procesamiento intensivo.
Decidir entre eventos, comandos asíncronos, mensajes de tarea, colas punto a punto y publicación-suscripción.
Modelar flujos de negocio mediante eventos, estados, consumidores, reintentos, compensaciones y observabilidad.
Evitar coreografías incontroladas donde muchos servicios reaccionan sin visión global del proceso.
Evaluar cuándo conviene orquestación explícita mediante process manager o saga frente a coreografía distribuida.
Diseñar consumidores idempotentes, tolerantes a duplicados, mensajes tardíos y cambios de versión.
Incorporar tracing distribuido para seguir un flujo que atraviesa APIs, colas, workers y bases de datos.
Medir salud de EDA mediante lag, throughput, errores, DLQ, latencia de procesamiento y frescura de proyecciones.
Diseñar un flujo EDA completo con evento de integración, broker, consumidor, proyección y manejo de errores.
Tema 19: Brokers de mensajería en .NET: RabbitMQ, Kafka y Azure Service Bus
Comparar RabbitMQ, Apache Kafka y Azure Service Bus desde el punto de vista de patrones, operación, orden, retención, escalado y modelo de consumo.
Elegir broker según necesidad: colas de trabajo, pub/sub, eventos durables, streaming, integración cloud, transacciones o consumo masivo.
Implementar productores y consumidores .NET con abstracciones propias que no contaminen dominio ni aplicación.
Gestionar serialización, schemas, headers, metadata, versiones y compatibilidad entre productores y consumidores.
Diseñar reintentos, delayed retries, dead letter queues, parking queues y estrategias de recuperación.
Controlar confirmaciones, acknowledgements, offsets, commits y garantías de entrega según el broker elegido.
Monitorizar errores, lag, mensajes pendientes, throughput, consumidores caídos y saturación del broker.
Proteger brokers con autenticación, autorización, TLS, nombres de cola controlados y aislamiento por entorno.
Probar mensajería en local con Docker, Testcontainers o entornos dedicados de integración.
Crear una estrategia corporativa para elegir y operar brokers en proyectos .NET con criterios técnicos y de negocio.
Tema 20: Outbox Pattern para publicación fiable de eventos
Comprender el problema de doble escritura entre base de datos y broker cuando se modifica estado y se publica un evento.
Implementar Outbox para guardar eventos en la misma transacción que el cambio del agregado.
Diseñar una tabla Outbox con identificador, tipo, payload, metadata, estado, reintentos, errores y fecha de publicación.
Crear un background worker que lee eventos pendientes, publica al broker y actualiza estado de forma segura.
Gestionar reintentos, errores permanentes, bloqueo concurrente y publicación duplicada.
Asegurar que los consumidores son idempotentes, porque Outbox puede ofrecer publicación al menos una vez.
Separar eventos de dominio internos de eventos de integración publicados externamente.
Medir salud de Outbox con pendientes, edad máxima, errores, reintentos y throughput.
Crear runbooks para Outbox bloqueado, broker caído, payload inválido o acumulación excesiva.
Implementar un Outbox completo en .NET con EF Core, worker, broker y pruebas de integración.
Tema 21: Inbox Pattern, deduplicación e idempotencia de consumidores
Implementar Inbox para registrar mensajes procesados y evitar efectos secundarios duplicados ante reentregas.
Diseñar claves de idempotencia basadas en event ID, message ID, aggregate ID, versión o clave de negocio.
Controlar procesamiento concurrente de mensajes que afectan al mismo recurso, evitando condiciones de carrera.
Separar errores transitorios, errores de negocio y mensajes inválidos para decidir reintento, rechazo o DLQ.
Diseñar consumidores que puedan reejecutarse sin romper datos, enviar notificaciones duplicadas o modificar estado dos veces.
Guardar estado de procesamiento con timestamps, resultado, errores y trazabilidad para auditoría.
Aplicar deduplicación temporal cuando el volumen no permite retener indefinidamente todos los mensajes.
Probar consumidores con mensajes duplicados, desordenados, antiguos, futuros y de versiones diferentes.
Monitorizar duplicados, errores de idempotencia, conflictos de concurrencia y reintentos excesivos.
Implementar Inbox en un consumidor .NET conectado a un evento de integración realista.
Tema 22: Sagas, process managers y workflows distribuidos
Diferenciar saga, process manager, workflow, orquestación, coreografía y transacción distribuida.
Modelar procesos largos con varios pasos, estados intermedios, eventos, comandos, timeouts y compensaciones.
Diseñar sagas coreografiadas cuando los servicios pueden reaccionar a eventos sin coordinador central excesivo.
Diseñar process managers cuando se necesita visibilidad, estado de proceso, decisiones, timeouts o control explícito.
Evitar sagas invisibles repartidas en muchos handlers sin una representación clara del proceso.
Crear compensaciones de negocio cuando un paso posterior falla y no se puede hacer rollback técnico.
Gestionar timeouts, expiraciones, mensajes perdidos, reintentos, cancelaciones y reconciliación manual.
Persistir estado de saga de forma segura y observable, con correlación entre mensajes y proceso.
Probar sagas con escenarios de fallo en cada paso, duplicados, dependencia caída y recuperación posterior.
Implementar un proceso distribuido completo con saga, eventos, comandos, compensaciones y documentación de estados.
Tema 23: Event sourcing: cuándo aporta valor y cuándo no
Comprender event sourcing como almacenamiento del historial de cambios del agregado mediante eventos, no solo del estado actual.
Evaluar escenarios donde event sourcing aporta valor: auditoría completa, reconstrucción histórica, dominios ricos, trazabilidad y temporalidad.
Identificar escenarios donde event sourcing complica innecesariamente persistencia, queries, soporte y onboarding.
Diseñar eventos de agregado con intención de negocio, versionado, evolución de schema y compatibilidad.
Reconstruir estado de agregados a partir de streams de eventos, snapshots y reglas de aplicación.
Separar event sourcing de EDA, porque almacenar eventos como fuente de verdad no equivale automáticamente a publicar eventos de integración.
Crear proyecciones de lectura a partir de streams, controlando consistencia, reintentos, rebuild y errores.
Gestionar migración de eventos, upcasting, deprecación de campos y cambios de semántica.
Probar agregados event sourced con Given-When-Then para validar comportamiento a partir de eventos pasados.
Diseñar una prueba de concepto de event sourcing en .NET y decidir si compensa frente a persistencia tradicional.
Tema 24: Proyecciones, read models y consistencia eventual
Crear proyecciones que transforman eventos en modelos de lectura optimizados para consultas, informes o pantallas.
Diseñar read models independientes del modelo de escritura, ajustados a rendimiento, permisos y experiencia del consumidor.
Controlar retraso entre comando y lectura, explicando al usuario cuándo puede ver datos temporalmente desactualizados.
Implementar rebuild de proyecciones cuando cambia el modelo de lectura o se corrige un error de cálculo.
Gestionar errores de proyección mediante reintentos, checkpoints, DLQ, logs y posibilidad de reprocesado.
Versionar proyecciones y mantener compatibilidad durante cambios de schema o eventos.
Medir lag, edad máxima de proyección, errores, throughput y consistencia percibida.
Evitar que proyecciones contengan lógica de negocio crítica que debería protegerse en el modelo de escritura.
Crear pruebas de proyección con secuencias de eventos, duplicados, cambios de versión y casos límite.
Implementar una proyección completa para una pantalla de consulta CQRS, con actualización por eventos y recuperación ante fallo.
Tema 25: Anti-corruption layers e integración con legacy
Diseñar anti-corruption layers para proteger el nuevo modelo de dominio frente a sistemas legacy, APIs antiguas o bases compartidas.
Traducir modelos, estados, errores, identificadores y reglas entre contextos sin contaminar el dominio moderno.
Crear adaptadores específicos para legacy que encapsulan protocolos, formatos, inconsistencias y reglas heredadas.
Evitar que el modelo nuevo adopte nombres, estructuras y limitaciones del sistema antiguo por comodidad.
Diseñar sincronización gradual entre legacy y nuevos módulos mediante APIs, eventos, jobs, vistas o replicación controlada.
Gestionar datos inconsistentes, estados históricos y campos ambiguos que no encajan en el nuevo dominio.
Probar la capa anticorrupción con ejemplos reales, casos límite y errores típicos del sistema externo.
Documentar compromisos temporales para que no se conviertan en arquitectura permanente por accidente.
Usar anti-corruption layer como parte de migraciones Strangler Fig y modernización incremental.
Implementar una integración legacy protegida mediante puerto, adaptador, mapper, pruebas y documentación de decisiones.
Tema 26: Monolito modular con Hexagonal, DDD, EDA y CQRS
Diseñar un monolito modular como alternativa pragmática a microservicios cuando el equipo necesita modularidad sin complejidad distribuida.
Separar módulos por bounded context, con contratos internos claros, dependencias controladas y ownership funcional.
Aplicar arquitectura hexagonal dentro de cada módulo para proteger dominio, aplicación e infraestructura.
Usar eventos internos para comunicar módulos sin llamadas directas excesivas ni dependencias circulares.
Implementar CQRS dentro de módulos donde existen lecturas complejas o reglas de escritura diferenciadas.
Diseñar reglas de dependencia entre módulos mediante proyectos, namespaces, interfaces, analyzers o pruebas de arquitectura.
Evitar bases de datos lógicamente compartidas sin ownership, aunque físicamente vivan en la misma instancia.
Preparar el monolito modular para una posible extracción futura sin diseñar de antemano una arquitectura distribuida innecesaria.
Crear CI/CD y pruebas que validen módulos, contratos internos, eventos y dependencias permitidas.
Refactorizar un monolito desordenado hacia módulos con límites, eventos internos y contratos explícitos.
Tema 27: Microservicios con DDD, eventos y CQRS
Diseñar microservicios a partir de bounded contexts reales, no desde tablas, pantallas o capas técnicas.
Aplicar DDD táctico dentro de cada microservicio con agregados, value objects, eventos de dominio y casos de uso.
Usar eventos de integración para comunicar cambios relevantes entre servicios, evitando bases de datos compartidas.
Aplicar CQRS cuando un servicio necesita separar modelo transaccional, modelo de lectura y proyecciones.
Gestionar consistencia eventual entre servicios con Outbox, Inbox, Sagas, procesos de reconciliación y observabilidad.
Diseñar APIs y eventos como contratos públicos del servicio, con versionado, compatibilidad y documentación.
Evitar microservicios demasiado pequeños que no tienen autonomía real y aumentan coste operativo.
Definir ownership completo: código, datos, SLOs, despliegue, incidentes, documentación y evolución del servicio.
Probar microservicios con unitarias, integración, contrato, componente y flujos distribuidos.
Diseñar una arquitectura distribuida .NET con varios servicios, brokers, bases propias, eventos y read models.
Tema 28: Testing del dominio y reglas de negocio
Crear pruebas unitarias de entidades, value objects, agregados, políticas y servicios de dominio sin infraestructura externa.
Usar ejemplos de negocio como base para pruebas legibles que documenten comportamiento y no solo líneas de código.
Validar invariantes de agregado ante comandos válidos, comandos inválidos, estados extremos y reglas temporales.
Probar value objects con igualdad, inmutabilidad, validación, normalización y operaciones propias.
Verificar eventos de dominio generados por agregados cuando ocurre un hecho relevante.
Evitar mocks innecesarios en dominio puro, manteniendo pruebas rápidas, deterministas y expresivas.
Crear nombres de pruebas que expliquen comportamiento, condición y resultado esperado.
Incorporar casos límite descubiertos en producción o sesiones con negocio para aumentar valor de la suite.
Medir calidad de pruebas por capacidad de detectar regresiones en reglas críticas, no por cobertura superficial.
Construir una batería de pruebas de dominio para un agregado complejo con invariantes, eventos y errores de negocio.
Tema 29: Testing de aplicación, contratos y eventos
Probar command handlers y query handlers validando orquestación, autorización, transacciones, puertos y resultados.
Crear tests de aplicación con repositorios fake, infraestructura simulada o contenedores según nivel de confianza necesario.
Validar contratos HTTP con pruebas que aseguran códigos de estado, payloads, errores, versionado y permisos.
Crear pruebas de contrato para eventos de integración, verificando schema, campos obligatorios, metadata y compatibilidad.
Probar consumidores con mensajes duplicados, tardíos, inválidos, de versión antigua y con dependencias caídas.
Usar Testcontainers para bases, brokers y dependencias de integración cuando se requiere comportamiento realista.
Evitar tests end-to-end excesivos que mezclan demasiados servicios y fallan por causas difíciles de diagnosticar.
Crear pruebas de proyecciones y read models a partir de secuencias de eventos.
Integrar tests en CI/CD con ejecución diferenciada por rapidez, profundidad y criticidad.
Diseñar una estrategia completa de testing para arquitectura hexagonal, DDD, EDA y CQRS.
Tema 30: Seguridad, autorización y reglas de acceso en arquitecturas ricas
Separar autenticación, autorización técnica, permisos de negocio y reglas de dominio para evitar controles dispersos.
Evaluar dónde debe comprobarse cada permiso: API, capa de aplicación, política de dominio, servicio externo o base de datos.
Diseñar autorización por recurso, tenant, rol, claim, ownership, estado del agregado y acción solicitada.
Evitar ocultar botones en UI como sustituto de controles server-side en comandos, queries o APIs.
Propagar identidad y contexto de usuario en eventos solo cuando existe finalidad clara y datos permitidos.
Proteger eventos, logs, trazas y read models para que no expongan datos sensibles por conveniencia técnica.
Auditar operaciones críticas: cambios de permisos, aprobaciones, pagos, borrados, exportaciones y acciones administrativas.
Crear pruebas de autorización para comandos, queries, APIs, consumidores y casos límite.
Aplicar threat modeling ligero sobre bounded contexts, eventos, APIs y procesos distribuidos.
Documentar matriz de permisos y decisiones de seguridad para que negocio, desarrollo y AppSec compartan criterio.
Tema 31: Observabilidad de comandos, eventos y flujos distribuidos
Instrumentar comandos, queries, eventos, consumidores, proyecciones y adaptadores para entender cómo se comporta el sistema.
Añadir correlation ID y causation ID desde la entrada HTTP hasta eventos, workers, proyecciones y read models.
Crear trazas distribuidas que conectan API, command handler, agregado, Outbox, broker, consumidor y proyección.
Medir latencia de comandos, duración de handlers, tiempo de publicación, lag de consumidores y frescura de proyecciones.
Diseñar logs estructurados con nombres de caso de uso, agregado, evento, tenant, operación y resultado.
Evitar incluir payloads completos, datos personales o secretos en logs y trazas.
Crear dashboards para procesos EDA y CQRS: comandos fallidos, eventos pendientes, Outbox, Inbox, DLQ, lag y read models.
Diseñar alertas accionables sobre proyecciones bloqueadas, eventos acumulados, errores de consumidor y comandos críticos fallidos.
Preparar runbooks para fallos de evento, Outbox atascado, proyección corrupta o inconsistencia detectada.
Integrar observabilidad como requisito de arquitectura, no como añadido final del despliegue.
Tema 32: CI/CD, quality gates y reglas de arquitectura
Crear pipelines que compilan, prueban, analizan, empaquetan y validan soluciones con múltiples módulos, servicios y adaptadores.
Añadir quality gates para pruebas de dominio, aplicación, contratos, eventos, seguridad, cobertura crítica y migraciones.
Ejecutar pruebas de arquitectura para validar dependencias permitidas entre dominio, aplicación, infraestructura y API.
Revisar cambios de eventos y contratos en CI/CD para evitar breaking changes no intencionados.
Generar artefactos versionados: paquetes, imágenes, contratos OpenAPI, schemas de eventos y documentación.
Integrar análisis estático, dependency scanning, secret scanning y comprobaciones de licencias cuando el entorno lo requiere.
Separar pipelines rápidos de PR y pipelines profundos de release, manteniendo feedback útil para desarrolladores.
Usar entornos efímeros o contenedores para validar integración con bases, brokers y servicios auxiliares.
Documentar pipelines con owners, variables, secretos, permisos, validaciones y procedimiento ante fallo.
Crear un pipeline de referencia para un sistema .NET con Hexagonal, DDD, EDA y CQRS.
Tema 33: Refactorización desde arquitectura n-capas hacia hexagonal
Analizar una aplicación n-capas típica con controladores, servicios, repositorios, DTOs compartidos y lógica dispersa.
Identificar qué reglas pertenecen al dominio, qué coordinación pertenece a aplicación y qué detalles deben moverse a infraestructura.
Crear pruebas de caracterización antes de mover lógica crítica para asegurar que el comportamiento actual se conserva.
Extraer value objects, entidades y agregados desde modelos anémicos o entidades EF demasiado expuestas.
Sustituir servicios genéricos por casos de uso explícitos con comandos, queries y handlers.
Introducir puertos y adaptadores progresivamente, evitando reestructuraciones masivas sin retorno inmediato.
Separar DTOs de API, modelos de dominio y entidades de persistencia donde el acoplamiento genera fricción.
Crear eventos de dominio para desacoplar efectos secundarios internos antes de pasar a eventos de integración.
Medir progreso por reducción de acoplamiento, aumento de pruebas útiles, claridad de dependencias y facilidad de cambio.
Diseñar un plan de refactorización incremental con fases, riesgos, PRs pequeños y criterios de éxito.
Tema 34: Migración hacia CQRS y EDA sin reescrituras masivas
Seleccionar casos de uso donde CQRS o EDA aportan valor claro, evitando aplicar ambos patrones a todo el sistema de forma indiscriminada.
Introducir comandos y queries en zonas de alta complejidad, manteniendo CRUD simple donde no hay beneficio.
Crear read models para pantallas críticas, informes o consultas pesadas sin reemplazar toda la capa de datos de golpe.
Publicar eventos de integración desde un Outbox sin cambiar inmediatamente todos los consumidores existentes.
Introducir consumidores asíncronos para efectos secundarios que antes bloqueaban el flujo principal.
Diseñar convivencia entre módulos síncronos y flujos event-driven durante la transición.
Controlar consistencia eventual y expectativas de usuario antes de separar escritura y lectura.
Crear pruebas y dashboards para validar que la migración no rompe comportamiento ni degrada experiencia.
Documentar decisiones temporales, compromisos y criterios para retirar código antiguo.
Construir una hoja de ruta de migración hacia CQRS y EDA por capacidad de negocio, riesgo y valor.
Tema 35: Decisiones arquitectónicas, ADRs y documentación viva
Crear ADRs para decisiones sobre arquitectura hexagonal, bounded contexts, CQRS, eventos, brokers, persistencia y migraciones.
Documentar contexto, problema, alternativas, decisión, consecuencias, riesgos y fecha de revisión.
Generar diagramas C4, diagramas de secuencia, mapas de contexto y flujos de eventos para explicar la arquitectura.
Mantener documentación cercana al repositorio y vinculada a código, contratos, eventos y pruebas.
Diferenciar documentación vigente, histórica, exploratoria y obsoleta para evitar confusión en equipos nuevos.
Crear glosarios de lenguaje ubicuo por bounded context, con ejemplos y términos prohibidos o ambiguos.
Documentar eventos con productor, consumidores, payload, versión, compatibilidad, metadata y garantía de entrega.
Incluir decisiones de seguridad, consistencia, persistencia, testing y observabilidad en la documentación arquitectónica.
Automatizar validaciones de documentación mínima cuando cambian APIs, eventos o decisiones relevantes.
Construir un repositorio de arquitectura vivo para un sistema .NET empresarial basado en DDD, EDA y CQRS.
Tema 36: Gobierno técnico, estándares y adopción por equipos
Definir estándares mínimos para nuevos módulos o servicios: dominio, casos de uso, puertos, adaptadores, pruebas, eventos y observabilidad.
Crear plantillas de servicio, módulo o caso de uso que reduzcan variabilidad sin imponer burocracia excesiva.
Establecer criterios de revisión en pull requests para arquitectura hexagonal, DDD, CQRS, eventos y persistencia.
Diseñar formación interna para que perfiles junior, senior, tech leads, QA y DevOps compartan lenguaje y expectativas.
Crear comunidades de práctica para revisar patrones, errores, decisiones, eventos, modelos y problemas de producción.
Evitar que el equipo use términos como agregado, evento, saga o puerto de forma superficial y contradictoria.
Medir adopción por calidad de cambios, reducción de deuda, consistencia de módulos, pruebas útiles y menor tiempo de onboarding.
Definir excepciones aceptables cuando el coste de aplicar un patrón completo supera el beneficio.
Revisar periódicamente estándares para adaptarlos a cambios de producto, equipo, tecnología y operación.
Crear una guía corporativa de arquitectura .NET con ejemplos reales, anti-patrones y checklist de calidad.
Tema 37: Rendimiento y escalabilidad en DDD, CQRS y EDA
Analizar impacto de agregados grandes, transacciones largas, consultas complejas, eventos masivos y proyecciones pesadas.
Diseñar agregados pequeños y consistentes que reducen bloqueos, conflictos de concurrencia y carga innecesaria.
Optimizar read models para consultas frecuentes sin comprometer reglas de escritura del dominio.
Usar proyecciones, materialized views, caches y modelos denormalizados cuando la lectura necesita escala o baja latencia.
Controlar backpressure en consumidores cuando la entrada de eventos supera la capacidad de procesamiento.
Medir lag, throughput, latencia de comando, tiempo de consulta, errores de consumidor y coste de proyección.
Evitar que CQRS se use para ocultar queries mal diseñadas, índices ausentes o modelos de datos sin ownership.
Evaluar escalado independiente de comandos, queries, consumidores, proyecciones y brokers.
Diseñar estrategias de particionado, snapshots, batching y reprocesado para flujos con alto volumen.
Crear pruebas de rendimiento específicas para comandos críticos, queries pesadas y pipelines de eventos.
Tema 38: Errores frecuentes y anti-patrones
Detectar modelos anémicos donde las entidades solo contienen datos y toda la lógica vive en servicios procedurales.
Evitar repositorios genéricos que empobrecen el dominio y convierten persistencia en una API CRUD universal.
Reconocer CQRS accidental cuando se duplican modelos sin una razón clara de rendimiento, complejidad o escalado.
Identificar eventos pobres como `EntityUpdated` que no expresan significado de negocio ni ayudan a consumidores.
Evitar sagas ocultas formadas por handlers sueltos, sin estado, sin compensaciones y sin trazabilidad.
Detectar abstracciones hexagonales innecesarias que solo añaden interfaces, mappers y carpetas sin reducir acoplamiento.
Corregir dominios contaminados por EF Core, frameworks, DTOs, atributos de serialización o clientes externos.
Evitar microservicios que comparten base de datos, librerías de dominio o modelos internos y no tienen autonomía real.
Reconocer documentación arquitectónica que describe intención pero no coincide con dependencias, código, eventos o despliegues.
Crear una checklist de anti-patrones para revisar proyectos .NET antes de escalar la arquitectura.
Tema 39: Proyecto final integrador: sistema .NET con Hexagonal, DDD, EDA y CQRS
Definir un dominio empresarial realista con reglas complejas, varios bounded contexts, operaciones críticas, consultas exigentes y procesos asíncronos.
Diseñar arquitectura hexagonal con dominio, aplicación, puertos, adaptadores, API, infraestructura, persistencia, mensajería y pruebas.
Modelar agregados, entidades, value objects, servicios de dominio, políticas e invariantes con lenguaje ubicuo y pruebas unitarias.
Implementar comandos, command handlers, queries, query handlers, read models y proyecciones aplicando CQRS donde aporta valor.
Crear domain events e integration events con contratos, metadata, versionado, documentación y pruebas de compatibilidad.
Implementar Outbox, Inbox, consumidores idempotentes, manejo de errores, DLQ y observabilidad de flujos event-driven.
Diseñar una saga o process manager para un proceso distribuido con estados, timeouts, compensaciones y recuperación.
Integrar persistencia con EF Core, adaptadores de infraestructura, repositorios orientados a agregados y migraciones controladas.
Preparar CI/CD con pruebas de dominio, aplicación, integración, contratos, eventos, reglas de arquitectura y análisis de seguridad.
Presentar el proyecto con ADRs, diagramas C4, mapa de contexto, flujos de eventos, decisiones, trade-offs, riesgos y roadmap de evolución.
Aulas Virtuales Personalizadas
¿Te imaginas tener un Temario 100% Personalizado para tu Empresa?
¿A quién va dirigida esta formación en Arquitectura de Hexagonal, DDD, EDA y CQRS para .Net?
Pensado para quienes deben dominar Arquitectura de Hexagonal, DDD, EDA y CQRS para .Net en su día a día
Desarrolladores backend .NET
Este curso encaja con desarrolladores que ya trabajan con C#, ASP.NET Core, APIs, Entity Framework Core, servicios backend o aplicaciones empresariales y quieren dar un salto de calidad arquitectónica. Aprenderán a separar dominio, aplicación e infraestructura, modelar reglas de negocio, diseñar comandos y consultas, trabajar con eventos y evitar que la lógica crítica quede repartida entre controladores, servicios anémicos y repositorios genéricos.
Desarrolladores senior y tech leads
Los perfiles con responsabilidad técnica podrán utilizar el curso para definir estándares de arquitectura, revisar pull requests, orientar refactorizaciones, reducir deuda y guiar a equipos que necesitan mantener sistemas complejos. La formación les aporta criterio para decidir cuándo usar DDD, CQRS, eventos, arquitectura hexagonal o una solución más simple.
Equipos que mantienen aplicaciones legacy .NET
Los equipos que trabajan con monolitos, aplicaciones n-capas, servicios acoplados, bases de datos compartidas o lógica de negocio dispersa podrán aprender estrategias de evolución gradual. El curso trabaja refactorización hacia arquitectura hexagonal, extracción de dominio, pruebas de caracterización, eventos y separación de responsabilidades sin reescrituras arriesgadas.
Arquitectos de software
Los perfiles de arquitectura podrán profundizar en decisiones de diseño, boundaries, bounded contexts, integración, consistencia eventual, contratos, eventos, read models, anti-corruption layers y gobernanza técnica. El curso ofrece una visión aplicable para diseñar sistemas .NET sostenibles y alineados con negocio.
Equipos de microservicios y plataformas distribuidas
Los equipos que trabajan con microservicios, APIs, colas, eventos, workers y plataformas cloud podrán aplicar DDD, EDA y CQRS con más control. La formación ayuda a evitar servicios mal delimitados, eventos ambiguos, dependencias circulares, transacciones distribuidas frágiles y modelos de datos compartidos sin ownership claro.
QA técnico, DevOps y perfiles de calidad
Los perfiles de calidad y plataforma podrán entender cómo probar, desplegar y observar sistemas diseñados con hexagonal, DDD, EDA y CQRS. El curso conecta arquitectura con pruebas de dominio, contrato, integración, consumidores de eventos, CI/CD, trazas, métricas, resiliencia y soporte real en producción.
Proveedor con 16 años de experiencia en formación empresarial
Sobre
En Imagina Formación llevamos más de 16 años ayudando a profesionales y empresas a mejorar sus habilidades con formación práctica y totalmente adaptada a sus necesidades. Durante este tiempo, hemos formado a más de 480.000 personas y colaborado con más de 3.500 empresas, convirtiéndonos en un referente en el sector.
16
Años de liderazgo
+480.000
Alumnos formados en Imagina
¿Tienes dudas?
Resolvemos todas tus dudas sobre nuestra formación en Arquitectura de Hexagonal, DDD, EDA y CQRS para .Net
Explora las respuestas a las preguntas que guian a nuestra comunidad. Aqui encontraras claridad sobre como funciona todo, desde el acceso hasta los detalles de los cursos. Si buscas respuestas, este es el lugar para comenzar.
Es un curso de arquitectura aplicada con implementación en .NET. Se trabajan conceptos de diseño, pero siempre bajados a C#, ASP.NET Core, EF Core, eventos, comandos, queries, pruebas, CI/CD y casos reales.
No es imprescindible, pero sí se recomienda tener experiencia backend con .NET. El curso explica DDD desde fundamentos estratégicos y tácticos, avanzando después hacia agregados, eventos, CQRS, EDA y migraciones.
Sí. El curso se plantea sobre .NET 10 como referencia actual LTS para proyectos empresariales .NET. Microsoft documenta que .NET 10 es una versión de soporte a largo plazo con tres años de soporte.
Sí. Se trabaja CQRS desde el enfoque conceptual hasta implementación con comandos, queries, handlers, modelos de lectura, proyecciones, consistencia eventual y criterios para decidir cuándo aplicarlo.
Sí. El curso cubre EDA con domain events, integration events, brokers, consumidores, Outbox, Inbox, Sagas, process managers, idempotencia, DLQ, versionado, observabilidad y pruebas de contrato.
Sí. Se diseñan puertos, adaptadores, casos de uso, infraestructura, APIs, persistencia y mensajería. El objetivo es proteger el dominio de frameworks y tecnologías externas sin añadir abstracciones inútiles.
Sí. Se trabaja EF Core desde una perspectiva DDD: agregados, value objects, owned types, Fluent API, repositorios orientados a dominio, migraciones, consultas y separación entre escritura y lectura.
Sí. El curso sirve tanto para monolitos modulares como para microservicios. De hecho, se insiste en no saltar a microservicios sin boundaries, ownership, eventos, datos y operación bien diseñados.
Sí. Hay bloques específicos sobre refactorización desde n-capas, anti-corruption layers, pruebas de caracterización, migración gradual a CQRS/EDA y evolución hacia monolito modular o servicios desacoplados.
Sí. Se cubre como patrón avanzado, explicando cuándo aporta valor y cuándo no. También se trabajan streams, snapshots, proyecciones, upcasting, pruebas Given-When-Then y riesgos operativos.
No. Es una formación corporativa práctica para equipos .NET. Puede ayudar a reforzar criterio de arquitectura, pero no sustituye una preparación oficial específica de ninguna certificación.
Sí. Al tratarse de una formación corporativa en desarrollo .NET, arquitectura de software, calidad, DevOps, seguridad y competencias digitales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.
Es un curso de arquitectura aplicada con implementación en .NET. Se trabajan conceptos de diseño, pero siempre bajados a C#, ASP.NET Core, EF Core, eventos, comandos, queries, pruebas, CI/CD y casos reales.
No es imprescindible, pero sí se recomienda tener experiencia backend con .NET. El curso explica DDD desde fundamentos estratégicos y tácticos, avanzando después hacia agregados, eventos, CQRS, EDA y migraciones.
Sí. El curso se plantea sobre .NET 10 como referencia actual LTS para proyectos empresariales .NET. Microsoft documenta que .NET 10 es una versión de soporte a largo plazo con tres años de soporte.
Sí. Se trabaja CQRS desde el enfoque conceptual hasta implementación con comandos, queries, handlers, modelos de lectura, proyecciones, consistencia eventual y criterios para decidir cuándo aplicarlo.
Sí. El curso cubre EDA con domain events, integration events, brokers, consumidores, Outbox, Inbox, Sagas, process managers, idempotencia, DLQ, versionado, observabilidad y pruebas de contrato.
Sí. Se diseñan puertos, adaptadores, casos de uso, infraestructura, APIs, persistencia y mensajería. El objetivo es proteger el dominio de frameworks y tecnologías externas sin añadir abstracciones inútiles.
Sí. Se trabaja EF Core desde una perspectiva DDD: agregados, value objects, owned types, Fluent API, repositorios orientados a dominio, migraciones, consultas y separación entre escritura y lectura.
Sí. El curso sirve tanto para monolitos modulares como para microservicios. De hecho, se insiste en no saltar a microservicios sin boundaries, ownership, eventos, datos y operación bien diseñados.
Sí. Hay bloques específicos sobre refactorización desde n-capas, anti-corruption layers, pruebas de caracterización, migración gradual a CQRS/EDA y evolución hacia monolito modular o servicios desacoplados.
Sí. Se cubre como patrón avanzado, explicando cuándo aporta valor y cuándo no. También se trabajan streams, snapshots, proyecciones, upcasting, pruebas Given-When-Then y riesgos operativos.
No. Es una formación corporativa práctica para equipos .NET. Puede ayudar a reforzar criterio de arquitectura, pero no sustituye una preparación oficial específica de ninguna certificación.
Sí. Al tratarse de una formación corporativa en desarrollo .NET, arquitectura de software, calidad, DevOps, seguridad y competencias digitales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.