Curso de MDD (Model Driven Development) para tu equipo técnico

Distinguir MDD de documentación tradicional, diseño previo pesado, UML clásico y generación automática sin criterio.

Entender el modelo como representación formal o semiforme de un aspecto del sistema que puede guiar análisis, construcción o validación.

Separar modelo conceptual, modelo de dominio, modelo lógico, modelo técnico, modelo de despliegue y modelo ejecutable.

Reconocer los niveles de abstracción y decidir qué nivel necesita cada audiencia.

Identificar cuándo un modelo debe ser comunicativo, cuándo debe ser verificable y cuándo debe ser generativo.

Relacionar MDD con productividad, consistencia, reutilización, trazabilidad y reducción de ambigüedad.

Detectar cuándo MDD no compensa por tamaño del proyecto, volatilidad, falta de madurez o coste de mantenimiento.

Diferenciar modelado ligero, modelado formal, DSL, MDA, low-code, code generation y architecture as code.

Analizar ejemplos de modelos útiles en proyectos reales: APIs, procesos, datos, estados, reglas, arquitectura y pruebas.

Establecer una definición de MDD aplicable al contexto de la empresa y no dependiente de una herramienta concreta.

Revisar el enfoque MDA desde una perspectiva práctica: separar negocio, plataforma y tecnología.

Interpretar CIM como modelo independiente de computación para representar negocio, proceso, contexto y objetivos.

Construir PIM como modelo independiente de plataforma donde aparecen dominio, reglas, servicios, interacciones y estructura lógica.

Derivar PSM como modelo específico de tecnología, framework, arquitectura, infraestructura o plataforma concreta.

Aplicar la separación CIM/PIM/PSM a una funcionalidad empresarial sencilla.

Identificar qué se pierde cuando se salta directamente de requisitos a código sin modelo intermedio.

Evitar duplicar información entre niveles cuando no aporta trazabilidad ni automatización.

Decidir qué partes de MDA tienen sentido en proyectos ágiles y cuáles pueden simplificarse.

Usar transformaciones entre niveles para generar entregables parciales, no necesariamente sistemas completos.

Crear una guía práctica para aplicar MDA de forma ligera en equipos modernos.

Seleccionar modelos según problema: dominio, procesos, estados, decisiones, datos, arquitectura, integración, seguridad o despliegue.

Evitar el uso indiscriminado de diagramas por costumbre o por exigencia documental.

Crear modelos de contexto para alinear stakeholders, sistemas externos, usuarios y límites del producto.

Usar modelos de dominio para consolidar lenguaje ubicuo, entidades, relaciones y reglas relevantes.

Aplicar modelos de estado para objetos con ciclo de vida complejo.

Usar modelos de proceso cuando hay flujos operativos, aprobaciones, excepciones o responsabilidades distribuidas.

Incorporar modelos de integración para APIs, eventos, colas, dependencias y contratos.

Añadir modelos de seguridad cuando permisos, roles, datos sensibles o auditoría condicionan el diseño.

Construir modelos de despliegue para entender entornos, nodos, redes, servicios e infraestructura.

Definir una matriz que conecte tipo de decisión con tipo de modelo recomendado.

Recuperar UML como lenguaje útil cuando se usa con propósito, concisión y audiencia clara.

Usar diagramas de clases para dominio, estructura, relaciones, agregados y conceptos técnicos.

Emplear diagramas de secuencia para conversaciones entre servicios, eventos, errores y transacciones.

Aplicar diagramas de actividad para flujos, decisiones, ramas, aprobaciones y procesos.

Usar diagramas de estados para entidades con ciclos de vida relevantes.

Incorporar diagramas de componentes para límites, módulos, dependencias e interfaces.

Evitar diagramas demasiado detallados que intentan replicar todo el código.

Definir convenciones visuales para que el equipo interprete los diagramas de la misma forma.

Conectar UML con generación parcial de documentación, pruebas o esqueletos técnicos cuando proceda.

Establecer qué diagramas se mantienen vivos y cuáles son solo artefactos de análisis puntual.

Usar C4 Model para explicar sistemas desde contexto, contenedores, componentes y código.

Preparar diagramas de contexto que ayuden a negocio a entender límites, actores y sistemas externos.

Crear diagramas de contenedores para mostrar aplicaciones, bases de datos, servicios, colas, frontales y APIs.

Usar diagramas de componentes para explicar módulos internos, adapters, casos de uso, capas y responsabilidades.

Relacionar C4 con MDD como modelo de arquitectura que guía decisiones y documentación.

Evitar mezclar demasiados niveles de detalle en un único diagrama.

Mantener diagramas C4 como documentación viva usando herramientas textuales como Structurizr, PlantUML o Mermaid.

Conectar C4 con repositorios, ADRs, pipelines y documentación técnica.

Añadir convenciones de color, tecnología, criticidad, ownership y dependencias.

Crear un estándar interno para representar arquitectura de forma consistente.

Utilizar DDD como base para modelos de dominio expresivos y conectados con negocio.

Identificar bounded contexts, subdominios, entidades, value objects, agregados, servicios de dominio y eventos.

Conectar lenguaje ubicuo con modelos, código, documentación y contratos API.

Evitar que un modelo de dominio se convierta en simple reflejo de tablas de base de datos.

Diseñar agregados que puedan guiar generación de estructuras, validaciones o endpoints.

Representar invariantes de negocio como reglas explícitas en el modelo.

Modelar eventos de dominio para integraciones, auditoría y procesos asíncronos.

Comparar modelos anémicos frente a modelos ricos desde una perspectiva MDD.

Traducir conceptos DDD a plantillas de código, documentación y pruebas.

Crear un flujo donde el modelo de dominio sea la referencia compartida entre análisis, arquitectura y desarrollo.

Entender qué es un metamodelo y por qué define los conceptos, relaciones y restricciones que pueden existir en un modelo.

Diferenciar modelo, metamodelo, metametamodelo, instancia y lenguaje de modelado.

Analizar ejemplos de metamodelos para APIs, procesos, entidades, reglas, formularios o integraciones.

Diseñar un metamodelo sencillo para representar un dominio empresarial concreto.

Definir tipos de elemento, atributos, relaciones, cardinalidades y restricciones.

Evitar metamodelos excesivamente genéricos que no ayudan a automatizar ni validar.

Incorporar reglas de consistencia para evitar modelos incompletos o contradictorios.

Relacionar metamodelos con generación de código, validación, documentación y herramientas de edición.

Evaluar cuándo basta con UML/BPMN/OpenAPI y cuándo merece la pena crear un metamodelo propio.

Documentar un metamodelo para que sea entendido por analistas, desarrolladores y responsables de plataforma.

Definir qué es una DSL y cuándo ayuda más que un lenguaje general o un diagrama estándar.

Diferenciar DSL textual, DSL gráfica, DSL interna y DSL externa.

Diseñar una DSL sencilla para describir reglas, formularios, procesos, APIs, entidades o flujos de integración.

Decidir el grado de formalidad necesario: lenguaje cercano a negocio, YAML/JSON estructurado, sintaxis textual o editor visual.

Crear ejemplos de DSL que puedan generar artefactos técnicos.

Establecer validaciones para que la DSL no acepte combinaciones inválidas.

Evitar DSLs demasiado ambiciosas que acaban siendo un lenguaje de programación peor.

Preparar documentación, ejemplos y mensajes de error comprensibles para usuarios de la DSL.

Versionar la DSL y gestionar cambios sin romper modelos existentes.

Evaluar costes reales: editor, parser, validación, generación, formación, soporte y evolución.

Usar modelos textuales para mantener diagramas versionados junto al código.

Crear diagramas PlantUML para clases, componentes, secuencias, estados y despliegue.

Usar Mermaid en documentación Markdown, wikis, repositorios y portales técnicos.

Aplicar Structurizr DSL para arquitectura C4 como código.

Comparar modelos textuales frente a herramientas gráficas en colaboración, revisión, versionado y automatización.

Integrar generación de diagramas en pipelines de documentación.

Definir convenciones de carpetas, nombres, módulos y ownership para modelos textuales.

Revisar pull requests de modelos igual que se revisa código.

Evitar diagramas textuales ilegibles por exceso de detalle o mala estructura.

Crear una documentación viva donde el modelo evoluciona junto al producto.

Evaluar herramientas como Enterprise Architect, Visual Paradigm, Eclipse Modeling, MagicDraw/Cameo, ArchiMate tools o soluciones equivalentes.

Comparar repositorios centralizados, archivos locales, modelos versionados y herramientas colaborativas web.

Definir criterios de selección: trazabilidad, metamodelado, generación, APIs, control de versiones, integración, coste y curva de aprendizaje.

Organizar paquetes, vistas, perfiles, convenciones y permisos dentro de una herramienta de modelado.

Evitar que una herramienta se convierta en repositorio opaco que solo sabe usar una persona.

Conectar modelos gráficos con documentación, Jira, Git, Confluence, Azure DevOps o pipelines.

Preparar exportaciones controladas a HTML, PDF, XMI, imágenes o documentación técnica.

Gestionar conflictos de edición, ramas, versiones y revisiones en modelos compartidos.

Definir ownership de modelos por dominio, sistema, equipo o producto.

Crear un criterio corporativo para decidir qué se modela en herramienta gráfica y qué se modela como texto.

Entender la transformación como paso formal o semiautomático entre modelos de distinto nivel o propósito.

Diferenciar transformación model-to-model y model-to-text.

Transformar un modelo de dominio en modelo de persistencia, modelo API, modelo de validaciones o modelo de documentación.

Crear reglas de transformación sencillas y explícitas para evitar generación impredecible.

Identificar información que debe heredarse del modelo origen y datos que debe aportar el modelo destino.

Gestionar excepciones, overrides y personalizaciones sin romper la trazabilidad.

Evitar transformaciones mágicas que nadie puede depurar.

Documentar reglas de transformación para que el equipo entienda por qué se genera cada artefacto.

Probar transformaciones con modelos pequeños antes de aplicarlas a modelos grandes.

Medir utilidad real de una transformación por ahorro, consistencia y reducción de errores.

Determinar qué partes del código conviene generar: DTOs, entidades, interfaces, controllers, clients, validators, tests, documentación o configuración.

Evitar generar lógica de negocio compleja si el equipo no puede mantenerla con claridad.

Diseñar plantillas de generación legibles y revisables.

Separar código generado, código manual y puntos de extensión.

Usar marcas, convenciones o carpetas para evitar sobrescribir cambios manuales.

Crear generadores incrementales que puedan ejecutarse varias veces sin destruir trabajo humano.

Incorporar formatos comunes: Java, C#, TypeScript, Python, SQL, OpenAPI, JSON Schema, YAML, Markdown o Terraform.

Revisar código generado con criterios de calidad, seguridad, rendimiento y estilo.

Añadir pruebas para asegurar que la generación produce artefactos válidos.

Definir un flujo de aprobación antes de introducir código generado en productos reales.

Modelar APIs como contratos versionados y generativos.

Usar OpenAPI para describir recursos, operaciones, parámetros, respuestas, errores, seguridad y ejemplos.

Generar clientes, servidores base, documentación, validadores o tests a partir del contrato.

Conectar modelos de dominio con esquemas OpenAPI sin duplicar definiciones de datos.

Diseñar contratos API-first como parte de un enfoque MDD práctico.

Gestionar compatibilidad hacia atrás, versionado, deprecaciones y cambios breaking.

Relacionar OpenAPI con documentación viva, mocks, gateways y pruebas de contrato.

Evitar que el contrato OpenAPI se genere tarde desde código sin revisión de diseño.

Añadir reglas de linting para naming, errores, seguridad y consistencia.

Crear un flujo donde el contrato API sea modelo, documentación y base de automatización.

Representar entidades, relaciones, cardinalidades, restricciones, claves, atributos y reglas de integridad.

Diferenciar modelo conceptual, modelo lógico y modelo físico de datos.

Generar esquemas SQL, migraciones, documentación de tablas o modelos ORM a partir de definiciones controladas.

Comparar persistencia relacional, documental, eventos, grafos y almacenamiento especializado desde perspectiva de modelado.

Evitar que el modelo de datos gobierne todo el dominio cuando la lógica de negocio requiere otro enfoque.

Documentar ownership de datos, sensibilidad, retención, auditoría y calidad.

Conectar modelos de datos con APIs, eventos, reporting y procesos.

Gestionar evolución del modelo sin romper datos existentes ni consumidores.

Crear validaciones sobre modelos de datos antes de generar migraciones.

Preparar un catálogo de datos mínimo derivado de modelos técnicos y funcionales.

Usar BPMN para modelar procesos de negocio con actividades, eventos, gateways, roles y excepciones.

Separar procesos descriptivos de procesos ejecutables.

Incorporar DMN para reglas de decisión, tablas de decisión y lógica de negocio explícita.

Conectar procesos con servicios, eventos, formularios, tareas humanas y sistemas externos.

Evaluar cuándo conviene ejecutar procesos en un motor BPM y cuándo solo documentarlos.

Generar documentación, tareas, contratos o tests desde modelos de proceso.

Detectar procesos demasiado complejos, excepciones no representadas o responsabilidades ambiguas.

Relacionar BPMN/DMN con requisitos, arquitectura y pruebas de aceptación.

Versionar procesos y reglas junto a releases de producto.

Crear una disciplina de modelado de procesos que aporte claridad sin burocracia.

Representar casos de uso, puertos, adaptadores, entidades, servicios, controladores y repositorios desde un modelo arquitectónico.

Generar estructuras base de proyecto respetando separación de responsabilidades.

Conectar modelos de dominio con interfaces de entrada, interfaces de salida, DTOs y adapters.

Evitar que la generación imponga una arquitectura rígida imposible de adaptar.

Crear plantillas para microservicios, APIs, módulos, librerías o aplicaciones internas.

Definir convenciones de naming, paquetes, dependencias y límites arquitectónicos.

Usar modelos para verificar que un módulo no rompe reglas de dependencia.

Relacionar architecture as code con diagramas, documentación y validaciones automáticas.

Incorporar tests arquitectónicos para validar decisiones modeladas.

Construir un acelerador de proyectos que mantenga consistencia sin bloquear innovación.

Modelar servicios, bounded contexts, APIs, eventos, colas, topics, contratos y dependencias.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.