Curso de MDD (Model Driven Development) hasta 100% Bonificable a través de FUNDAE
Tu bonificación paso a paso
Forma a tu equipo sin costes mediante la bonificación estatal. Este programa de MDD (Model Driven Development)para empresas es subvencionable hasta el 100%.
Potencia las habilidades de edición y automatización de tus profesionales.
Accede a una formación avanzada en MDD (Model Driven Development) práctica y orientada a resultados.
Prepara a tu equipo para los retos documentales del entorno laboral actual.
Gestionamos gratis tu bonificación de este curso corporativo de MDD (Model Driven Development) ante FUNDAE.
Capacita a tu equipo en MDD (Model Driven Development) con formación A Medida, tutorizada y bonificable por FUNDAE para empresas. Diseñamos el plan formativo.
Encaja con arquitectura moderna MDD se trabaja junto a DDD, APIs, microservicios, eventos, arquitectura hexagonal, DevOps, CI/CD, OpenAPI, BPMN y documentación como código.
1
Reduce ambigüedad entre negocio y desarrollo Los modelos de dominio, procesos, estados, reglas y contratos permiten que analistas, arquitectos y desarrolladores compartan una visión común.
Personaliza el temario al 100% para tu equipo
Diseñamos una formación a medida utilizando los documentos y flujos de trabajo reales de tu empresa.
Nueva Plataforma de E-learningFormación en directo con plataforma de apoyo para reforzar el aprendizaje
Acceso a las grabaciones
Los alumnos podrán revisar las sesiones grabadas para repasar conceptos clave, recuperar explicaciones concretas o reforzar aquellos contenidos que necesiten después de la clase en directo.
Recursos formativos
Materiales, sesiones grabadas y documentación de apoyo quedan centralizados en la plataforma para que el equipo pueda consultarlos durante y después de la formación.
Confirmación de asistencia
La plataforma permite registrar y confirmar la asistencia de los participantes, facilitando el seguimiento de la formación y la gestión documental necesaria para la bonificación FUNDAE.
Programa formativo
Temario del curso
Encuentra todo el temario del curso aquí.
Temario
Partir de una necesidad funcional sencilla para ver cómo nace un modelo útil y no un diagrama decorativo.
Identificar actores, casos de uso, datos principales, reglas de negocio y eventos relevantes antes de elegir ninguna herramienta.
Crear un modelo de dominio inicial con entidades, atributos, relaciones, invariantes y vocabulario común.
Transformar el modelo de dominio en una primera estructura técnica: módulos, servicios, contratos, validaciones y persistencia.
Definir un contrato API sencillo a partir del modelo, conectando recursos, operaciones, errores y datos intercambiados.
Generar un primer artefacto técnico desde el modelo: clases, DTOs, esquema JSON, documentación, pruebas o scaffolding.
Revisar qué parte del resultado generado es aceptable, qué parte debe ajustarse y qué parte no debería generarse nunca.
Cambiar una regla del modelo y observar qué entregables deberían actualizarse para mantener consistencia.
Detectar desde el primer ejemplo los riesgos de MDD: exceso de detalle, falsa automatización, modelos obsoletos y dependencia de herramienta.
Cerrar el recorrido con una idea clara: MDD no consiste en dibujar más, sino en convertir modelos en activos técnicos gobernados.
Partir de una necesidad funcional sencilla para ver cómo nace un modelo útil y no un diagrama decorativo.
Identificar actores, casos de uso, datos principales, reglas de negocio y eventos relevantes antes de elegir ninguna herramienta.
Crear un modelo de dominio inicial con entidades, atributos, relaciones, invariantes y vocabulario común.
Transformar el modelo de dominio en una primera estructura técnica: módulos, servicios, contratos, validaciones y persistencia.
Definir un contrato API sencillo a partir del modelo, conectando recursos, operaciones, errores y datos intercambiados.
Generar un primer artefacto técnico desde el modelo: clases, DTOs, esquema JSON, documentación, pruebas o scaffolding.
Revisar qué parte del resultado generado es aceptable, qué parte debe ajustarse y qué parte no debería generarse nunca.
Cambiar una regla del modelo y observar qué entregables deberían actualizarse para mantener consistencia.
Detectar desde el primer ejemplo los riesgos de MDD: exceso de detalle, falsa automatización, modelos obsoletos y dependencia de herramienta.
Cerrar el recorrido con una idea clara: MDD no consiste en dibujar más, sino en convertir modelos en activos técnicos gobernados.
Representar flujos síncronos y asíncronos con secuencias, eventos y modelos de integración.
Generar contratos de eventos, esquemas Avro/JSON Schema, documentación o clientes.
Gestionar ownership de eventos, versionado y compatibilidad.
Detectar acoplamientos no deseados entre microservicios a través del modelo.
Modelar sagas, procesos distribuidos, compensaciones y consistencia eventual.
Conectar modelos con catálogos de APIs, service catalogs y plataformas internas.
Evitar que cada equipo modele sus servicios con convenciones incompatibles.
Crear reglas de arquitectura verificables para servicios, dependencias y contratos.
Preparar modelos que ayuden a operar y evolucionar ecosistemas distribuidos.
Tema 19: MDD en frontend, formularios y experiencia de usuario
Modelar formularios, validaciones, flujos de pantalla, permisos, estados y componentes reutilizables.
Generar estructuras de frontend, esquemas de formularios, validadores, documentación o pruebas visuales.
Diferenciar generación útil de UI frente a interfaces genéricas poco adaptadas al usuario.
Conectar modelos de dominio con formularios sin exponer complejidad innecesaria.
Modelar navegación, acciones, estados vacíos, errores, permisos y feedback de usuario.
Usar DSLs o JSON/YAML para definir formularios configurables.
Controlar estilos, componentes, accesibilidad y diseño responsive desde plantillas.
Evitar que el modelo de UI se convierta en una copia rígida del HTML final.
Preparar modelos que faciliten mantenimiento de aplicaciones internas.
Integrar diseño de UX con generación parcial y revisión humana.
Tema 20: Validación de modelos y reglas de consistencia
Definir reglas que impidan modelos incompletos, contradictorios o no generables.
Validar nombres, relaciones, cardinalidades, tipos, estados, permisos, contratos y dependencias.
Crear validaciones semánticas más allá de la sintaxis del modelo.
Generar mensajes de error comprensibles para analistas y desarrolladores.
Incorporar validaciones en la herramienta de modelado, el repositorio o el pipeline.
Bloquear generación cuando el modelo incumple reglas críticas.
Diferenciar warnings, errores y recomendaciones.
Crear reglas de calidad para diagramas, DSLs, OpenAPI, BPMN, datos y arquitectura.
Medir calidad de modelos con criterios objetivos.
Mantener un catálogo vivo de reglas de consistencia del equipo.
Tema 21: Testing basado en modelos
Generar casos de prueba desde modelos de estados, procesos, reglas o APIs.
Derivar pruebas de aceptación a partir de escenarios modelados.
Usar modelos de estados para crear pruebas de transición válidas e inválidas.
Crear tests de contrato desde OpenAPI, AsyncAPI o esquemas de eventos.
Generar datos de prueba coherentes con el modelo de dominio.
Relacionar requisitos, modelos, pruebas y evidencias.
Detectar huecos de cobertura cuando existen reglas no probadas.
Evitar pruebas generadas masivamente que nadie entiende ni mantiene.
Integrar testing basado en modelos en pipelines CI/CD.
Usar resultados de pruebas para validar que el sistema sigue cumpliendo el modelo.
Tema 22: Trazabilidad de requisitos, modelos, código y pruebas
Conectar requisitos con modelos, decisiones de arquitectura, tickets, código, pruebas y documentación.
Definir identificadores estables para elementos de modelo relevantes.
Mapear cambios de modelo con impacto en APIs, datos, procesos, pantallas o servicios.
Evitar trazabilidad manual excesiva que nadie actualiza.
Automatizar enlaces cuando los artefactos están versionados y nombrados con criterio.
Preparar matrices de trazabilidad para entornos regulados o proyectos complejos.
Relacionar trazabilidad con auditoría, calidad, mantenimiento y análisis de impacto.
Detectar requisitos sin implementación, modelos sin pruebas o código sin referencia funcional.
Crear reportes de trazabilidad útiles para responsables técnicos y de negocio.
Diseñar un nivel de trazabilidad proporcional al riesgo del proyecto.
Tema 23: Versionado de modelos y colaboración con Git
Tratar modelos como activos versionables, revisables y comparables.
Organizar modelos textuales, gráficos, exports y documentación dentro de repositorios Git.
Definir estrategia de ramas para cambios de arquitectura, API, dominio o procesos.
Revisar cambios de modelo en pull requests con checklist específico.
Gestionar conflictos en modelos gráficos mediante exportaciones, fragmentación o repositorios especializados.
Etiquetar versiones de modelos asociadas a releases de producto.
Mantener changelog de cambios relevantes en modelos.
Evitar artefactos binarios opacos cuando el equipo necesita revisión colaborativa.
Integrar diagramas generados en documentación publicada automáticamente.
Crear una disciplina de “model as code” cuando aporta valor real.
Tema 24: CI/CD para modelos, documentación y generación
Incluir validación de modelos en pipelines de integración continua.
Ejecutar linters sobre OpenAPI, AsyncAPI, PlantUML, Mermaid, DSLs o reglas internas.
Generar documentación automáticamente a partir de modelos versionados.
Generar código, esquemas, clientes o pruebas como parte controlada del pipeline.
Detectar drift entre modelo, código y documentación.
Publicar portales técnicos actualizados con diagramas, contratos y decisiones.
Bloquear merges cuando un modelo rompe reglas de arquitectura o contrato.
Separar generación experimental de generación productiva.
Mantener artefactos generados con trazabilidad de versión y origen.
Crear una cadena CI/CD donde modelar tenga impacto real y visible.
Tema 25: MDD, low-code y plataformas empresariales
Comparar MDD con low-code, no-code, BPM, RPA y plataformas de desarrollo visual.
Identificar qué plataformas usan modelos internamente aunque no lo llamen MDD.
Evaluar cuándo una plataforma low-code resuelve un problema mejor que un framework propio.
Detectar riesgos de lock-in, modelos cerrados, poca exportabilidad y lógica difícil de versionar.
Conectar modelos de negocio con plataformas como Power Platform, Mendix, OutSystems, ServiceNow o herramientas internas.
Separar modelos de proceso, modelos de datos, formularios, reglas y automatizaciones.
Diseñar gobierno para evitar proliferación de aplicaciones sin arquitectura común.
Valorar generación de aplicaciones internas desde modelos controlados.
Preparar criterios de selección entre MDD propio, low-code comercial y desarrollo tradicional.
Construir una estrategia donde los modelos sigan siendo activos reutilizables y no configuraciones aisladas.
Tema 26: MDD en modernización de legacy
Usar modelos para entender sistemas existentes antes de reescribir o migrar.
Extraer modelos de dominio, datos, procesos, reglas e integraciones desde código o documentación legacy.
Representar dependencias entre módulos, bases, jobs, pantallas, APIs y procesos batch.
Detectar zonas candidatas a extracción, refactorización, encapsulado o sustitución.
Generar documentación viva de sistemas que ya no tienen documentación fiable.
Conectar modelos legacy con modelos objetivo de nueva arquitectura.
Crear mapas de impacto para migraciones progresivas.
Evitar que MDD se use para redibujar el legacy sin estrategia de transformación.
Apoyar decisiones de strangler pattern, APIs, eventos y coexistencia.
Diseñar una hoja de ruta de modernización basada en modelos útiles y trazables.
Tema 27: MDD y seguridad desde el modelo
Modelar roles, permisos, políticas, recursos protegidos, datos sensibles y flujos de autorización.
Conectar modelos de seguridad con APIs, pantallas, servicios, base de datos y auditoría.
Generar matrices de permisos o reglas de autorización desde modelos.
Identificar amenazas derivadas de relaciones, exposición de datos, procesos y fronteras del sistema.
Incorporar privacidad, clasificación de datos, retención y trazabilidad desde fases tempranas.
Usar modelos para revisar superficies de ataque, trust boundaries y dependencias externas.
Evitar que seguridad aparezca tarde como checklist ajeno al diseño.
Crear validaciones sobre modelos para detectar recursos sin propietario, endpoints sin seguridad o datos sensibles sin protección.
Documentar decisiones de seguridad como parte del modelo arquitectónico.
Integrar modelos de seguridad con QA, compliance y revisión de arquitectura.
Tema 28: IA generativa como apoyo al modelado
Usar asistentes de IA para proponer modelos iniciales a partir de requisitos, documentación o conversaciones.
Revisar críticamente diagramas, DSLs, OpenAPI, BPMN o clases generadas por IA.
Convertir modelos textuales en documentación, ejemplos, pruebas o explicaciones para stakeholders.
Generar borradores de DSL, reglas de validación o plantillas de código con revisión humana.
Evitar que la IA invente conceptos de dominio no validados por negocio.
Usar IA para detectar inconsistencias, duplicidades o huecos en modelos existentes.
Preparar prompts con contexto, restricciones, metamodelo y ejemplos para mejorar resultados.
Proteger información sensible al usar herramientas de IA externas o empresariales.
Integrar IA como acelerador de análisis y documentación, no como autoridad técnica.
Crear una política de uso responsable de IA en procesos de modelado.
Tema 29: Gobierno MDD y adopción en equipos reales
Definir roles: model owner, domain expert, architect, generator owner, reviewer, developer y QA.
Establecer qué modelos son obligatorios, recomendados, opcionales o experimentales.
Crear criterios para actualizar modelos durante sprints, releases, cambios de arquitectura o incidencias.
Evitar que el modelado dependa de una sola persona experta.
Formar al equipo en convenciones, herramientas, ejemplos y errores frecuentes.
Medir adopción por uso real, generación, trazabilidad, reducción de errores y satisfacción del equipo.
Revisar periódicamente qué modelos siguen aportando valor y cuáles deben retirarse.
Definir un backlog de mejoras de metamodelos, plantillas, generadores y documentación.
Incorporar MDD en definición de listo, definición de hecho o revisión arquitectónica cuando proceda.
Convertir MDD en práctica sostenible, no en iniciativa puntual de arquitectura.
Tema 30: Antipatrones y errores frecuentes en MDD
Detectar modelos que intentan representar todo el sistema con detalle imposible de mantener.
Evitar diagramas que solo se actualizan antes de una auditoría o entrega formal.
Reconocer generadores que producen código rígido, ilegible o difícil de depurar.
Identificar DSLs que acaban siendo lenguajes complejos sin tooling suficiente.
Corregir metamodelos diseñados por arquitectos sin participación de quienes usan el sistema.
Evitar herramientas impuestas que ralentizan al equipo y no conectan con el flujo de desarrollo.
Detectar duplicidad entre modelo, documentación, código y configuración.
Resolver conflictos entre agilidad y modelado mediante modelos ligeros y útiles.
Retirar modelos obsoletos que crean más confusión que ayuda.
Crear una lista de señales tempranas de que la iniciativa MDD se está desviando.
Tema 31: Estrategia de implantación MDD en una organización
Elegir un primer caso de uso con valor claro: APIs, datos, formularios, arquitectura, procesos o generación de proyectos.
Limitar el alcance inicial para demostrar valor sin intentar transformar todo el ciclo de desarrollo.
Definir herramientas mínimas, convenciones, repositorio, plantillas y responsables.
Crear un piloto con métricas de éxito: ahorro, consistencia, errores evitados, documentación y aceptación del equipo.
Recoger feedback de analistas, desarrolladores, QA, arquitectura y negocio.
Ajustar metamodelo, DSL, generadores o documentación antes de escalar.
Preparar plan de adopción por fases y equipos.
Integrar MDD con prácticas existentes: Scrum, DevOps, revisión de arquitectura, QA y gestión de producto.
Definir soporte, formación interna y mantenimiento de herramientas.
Crear una hoja de ruta para pasar de modelos útiles a una plataforma interna de desarrollo basada en modelos.
Tema 32: Proyecto final integrador de MDD
Seleccionar un dominio empresarial de ejemplo con procesos, datos, reglas, usuarios, APIs y decisiones técnicas.
Crear un modelo de contexto para ubicar actores, sistemas externos, límites y dependencias principales.
Diseñar un modelo de dominio con entidades, relaciones, invariantes, eventos y lenguaje común.
Definir un modelo de procesos o estados para representar el ciclo de vida principal del negocio.
Construir un contrato API o modelo de integración derivado del dominio.
Crear una pequeña DSL, metamodelo o estructura YAML/JSON que represente parte del sistema de forma generativa.
Generar al menos un artefacto útil: documentación, esquema, DTO, OpenAPI, prueba, plantilla de servicio o diagrama.
Añadir reglas de validación para detectar errores o incoherencias en el modelo.
Preparar trazabilidad mínima entre requisitos, modelos, artefactos generados y pruebas.
Presentar la metodología resultante, decisiones tomadas, límites, riesgos, beneficios y plan de evolución para una adopción real.
Perfiles profesionales
Pensado para quienes deben dominar MDD (Model Driven Development) en su día a día
Arquitectos de software y solución
Perfiles que necesitan traducir visión, dominios, integraciones, decisiones técnicas y restricciones de plataforma en modelos claros, trazables y conectados con código, APIs, servicios, documentación y evolución del sistema.
Analistas funcionales y de negocio
Profesionales que recogen requisitos, procesos, reglas, flujos, actores y datos, y quieren modelarlos de forma estructurada para reducir ambigüedad, mejorar comunicación con desarrollo y mantener trazabilidad durante todo el ciclo de vida.
Desarrolladores backend, frontend y full stack
Preguntas frecuentes
Resolvemos todas tus dudas sobre nuestra formación en MDD (Model Driven Development)
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.
MDD, Model Driven Development, es un enfoque de desarrollo donde los modelos se usan como activos centrales para analizar, diseñar, validar, documentar y generar partes del software.
No. UML puede ser una herramienta dentro de MDD, pero MDD es más amplio: incluye metamodelos, DSLs, transformaciones, generación de código, validación, trazabilidad y gobierno.
No. La formación trabaja ejemplos aplicados: modelos de dominio, APIs, procesos, contratos, generación de artefactos, validación, documentación, pruebas y CI/CD.
No necesariamente. El curso puede adaptarse a herramientas gráficas, textuales o mixtas: Enterprise Architect, Visual Paradigm, Eclipse Modeling, PlantUML, Mermaid, Structurizr, OpenAPI, BPMN o DSLs propias.
Sí, siempre que se use con ligereza y propósito. El curso evita el modelado pesado y plantea modelos vivos, revisables y conectados con entregables reales.
Sí, pero con criterio. Se trabaja qué conviene generar, cómo separar código generado y manual, cómo evitar sobrescrituras y cómo validar artefactos generados.
Sí. Hay bloques específicos sobre DSLs textuales, gráficas, internas y externas, así como diseño de metamodelos, validación y generación.
Sí. El curso incluye OpenAPI, modelos de integración, eventos, contratos, bounded contexts, arquitectura hexagonal y generación de estructuras base.
Evita ambigüedad, documentación obsoleta, generación sin control, duplicidad entre modelos y código, DSLs innecesarias, modelos demasiado detallados y herramientas aisladas del flujo real.
Sí. Al tratarse de formación corporativa orientada a empresa, puede bonificarse hasta el 100% mediante FUNDAE según el crédito disponible y las condiciones aplicables de la organización.
MDD, Model Driven Development, es un enfoque de desarrollo donde los modelos se usan como activos centrales para analizar, diseñar, validar, documentar y generar partes del software.
No. UML puede ser una herramienta dentro de MDD, pero MDD es más amplio: incluye metamodelos, DSLs, transformaciones, generación de código, validación, trazabilidad y gobierno.
No. La formación trabaja ejemplos aplicados: modelos de dominio, APIs, procesos, contratos, generación de artefactos, validación, documentación, pruebas y CI/CD.
No necesariamente. El curso puede adaptarse a herramientas gráficas, textuales o mixtas: Enterprise Architect, Visual Paradigm, Eclipse Modeling, PlantUML, Mermaid, Structurizr, OpenAPI, BPMN o DSLs propias.
Sí, siempre que se use con ligereza y propósito. El curso evita el modelado pesado y plantea modelos vivos, revisables y conectados con entregables reales.
Sí, pero con criterio. Se trabaja qué conviene generar, cómo separar código generado y manual, cómo evitar sobrescrituras y cómo validar artefactos generados.
Sí. Hay bloques específicos sobre DSLs textuales, gráficas, internas y externas, así como diseño de metamodelos, validación y generación.
Sí. El curso incluye OpenAPI, modelos de integración, eventos, contratos, bounded contexts, arquitectura hexagonal y generación de estructuras base.
Evita ambigüedad, documentación obsoleta, generación sin control, duplicidad entre modelos y código, DSLs innecesarias, modelos demasiado detallados y herramientas aisladas del flujo real.
Sí. Al tratarse de formación corporativa orientada a empresa, puede bonificarse hasta el 100% mediante FUNDAE según el crédito disponible y las condiciones aplicables de la organización.
Diseñemos hoy el curso que tu empresa necesita
Cuéntanos tus objetivos de negocio y prepararemos una propuesta formativa bonificable totalmente ad hoc
Evita sobreingeniería La formación insiste en modelar solo lo necesario, con el nivel de detalle adecuado y con objetivos claros de comunicación, validación o generación.
3
Mejora trazabilidad y calidad Permite conectar requisitos, modelos, código, pruebas, documentación y releases, algo especialmente valioso en proyectos complejos o regulados.
4
Prepara una adopción realista Incluye gobierno, roles, herramientas, versionado, antipatrones, pilotos, métricas y hoja de ruta para implantar MDD sin imponer burocracia al equipo.
Después de la formación en directo, los alumnos podrán acceder a ejercicios prácticos para aplicar lo trabajado en clase y consolidar el aprendizaje con actividades guiadas.
Acceso a las grabaciones
Los alumnos podrán revisar las sesiones grabadas para repasar conceptos clave, recuperar explicaciones concretas o reforzar aquellos contenidos que necesiten después de la clase en directo.
Recursos formativos
Materiales, sesiones grabadas y documentación de apoyo quedan centralizados en la plataforma para que el equipo pueda consultarlos durante y después de la formación.
Confirmación de asistencia
La plataforma permite registrar y confirmar la asistencia de los participantes, facilitando el seguimiento de la formación y la gestión documental necesaria para la bonificación FUNDAE.
Ejercicios prácticos
Después de la formación en directo, los alumnos podrán acceder a ejercicios prácticos para aplicar lo trabajado en clase y consolidar el aprendizaje con actividades guiadas.
Practica y mejora con nuestra plataforma
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
Equipos que quieren usar modelos para generar código base, contratos, DTOs, validaciones, documentación, estructuras de proyecto, pruebas o configuraciones, sin perder control técnico sobre el resultado final.
Equipos de ingeniería de plataformas
Perfiles responsables de crear aceleradores internos, plantillas, DSLs, generadores, scaffolding, normas de arquitectura, pipelines y herramientas que permitan a otros equipos construir software con más consistencia.
Responsables de calidad, QA y compliance
Profesionales que necesitan asegurar trazabilidad entre requisitos, modelos, reglas, pruebas, documentación, releases y evidencias, especialmente en entornos regulados o con alta exigencia de auditoría.
Product owners técnicos y responsables de producto
Perfiles que quieren alinear mejor necesidades de negocio, dominios funcionales, roadmap, arquitectura, dependencias y entregables técnicos mediante modelos que sirvan para decidir, priorizar y comunicar.
