Curso de Arquitectura de Hexagonal, DDD, EDA y CQRS para .Net

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.