- 1

Transición de programador empírico a arquitecto de software
02:46 - 2

Análisis de licitaciones con inteligencia artificial
08:48 - 3

Monorepositorios como herramienta de gestión de código fuente
13:00 - 4

Reglas de control de versiones en monorepositorio con trunk-based
05:58 - 5

Behavior Driven Development para alinear equipos técnicos y de negocio
09:25 - 6

Notación estándar C4 para diagramas de arquitectura
08:00 - 7

Generadores de sitios estáticos para documentación de proyectos
04:58 - 8

Uso de herramientas de IA para mejorar arquitectura de software
05:05 quiz de Creando Entornos de Software Saludables
Migraciones automáticas de bases de datos con Flyway
Clase 15 de 29 • Curso de Arquitectura de Software Aplicada
Contenido del curso
- 9

Estructura del archivo Architecture.md para proyectos de software
12:00 - 10

Domain-driven design para sistemas de comercio exterior
06:50 - 11

Técnicas pre-mortem y cinco why para prevenir fallos en sistemas
03:58 - 12

Técnicas de conversación e intervención directa en arquitectura
02:49 quiz de Siguiendo una Arquitectura Limpia
- 19

Diferencias entre mensajes y eventos en arquitectura de servicios
03:36 - 20

Patrón productor consumidor vs fan-in y fan-out en microservicios
03:11 - 21

Manejo de excepciones en el patrón productor-consumidor
02:48 - 22

Patrón comparing consumers para procesamiento en tiempo real
02:28 - 23

Patrón Process Manager para integrar actividades humanas y sistemas
02:33 quiz de Patrones de integración
- 24

Patrones de persistencia: durable state vs event sourcing
08:15 - 25

Máquinas de estado finito en la capa de presentación de software
04:52 - 26

Técnicas SAST, DAST y pen testing para seguridad en software
01:36 - 27

Funciones fitness para evaluar arquitecturas de software
04:20 - 28

Observabilidad en sistemas con OpenTelemetry e ingeniería del caos
04:45
La gestión eficaz de la evolución de modelos de datos es esencial en proyectos robustos donde la arquitectura del software va mucho más allá del código. En ambientes como el del Banco Interamericano de Desarrollo, los datos son el elemento vital, y mantener su integridad mientras el sistema crece resulta determinante para el éxito y la escalabilidad.
¿Por qué controlar la evolución de un modelo de datos relacional?
La evolución del modelo de datos garantiza seguridad y coherencia cuando cambian los requisitos del sistema. Un modelo de datos bien gestionado ayuda a anticipar y evitar cuellos de botella en el rendimiento y facilita el desarrollo en equipo porque todos parten de la misma base y entienden el historial de cambios.
- El control hace posible mantener una arquitectura flexible y ordenada.
- El historial permite rastrear el origen y las versiones del esquema actual.
- Reduce riesgos de inconsistencias entre el modelo de dominio y la estructura física de los datos.
¿Cómo se gestionan las migraciones automáticas con herramientas open source?
El uso de herramientas como Flyway agiliza la automatización de cambios y la gestión del esquema de base de datos. Es común utilizar migraciones como parte del pipeline de construcción, logrando así una implementación segura y trazable.
- Flyway permite definir versiones de esquemas y aplicar cambios mediante archivos SQL.
- Se registra un historial en una tabla de control interna.
- Al aplicar varias migraciones, la historia del esquema y los datos se vuelve lineal y ordenada.
- Esta automatización asegura que ambientes de desarrollo, prueba y producción sean consistentes y seguros.
¿Qué diferencias existen entre modelo de dominio y modelo de datos persistido?
El modelo de dominio representa la lógica del negocio, pero no siempre coincide con el modelo físico en la base de datos. Es importante reconocer que cada uno puede evolucionar a velocidades diferentes.
- Una mala sincronización afecta la escalabilidad y el rendimiento de la aplicación.
- Separar bien la lógica de negocio del modelo de persistencia evita caos y mejora la mantenibilidad.
¿Qué alternativas existen para controlar los cambios en bases de datos?
No existe una única estrategia universal. Se puede optar por:
- Migraciones manuales.
- Migraciones integradas en frameworks.
- Control de cambios directamente en el pipeline de CI/CD.
Toma en cuenta que las bases relacionales no son la única opción; también existen bases orientadas a documentos y sin esquema. Cada alternativa supone diferentes desafíos para el control y la evolución del dato.
¿Cómo abordar la diferencia entre cargas OLTP y OLAP en la arquitectura de datos?
Separar correctamente transacciones operativas (OLTP) y procesos analíticos (OLAP) evita sobrecargas e inconsistencias.
- Para escenarios complejos, utiliza patrones como extract-transform-load (ETL) o extract-load-transform (ELT).
- Considera nuevas técnicas como data mesh o data fabric dependiendo del contexto y tamaño del proyecto.
Los datos son comparables a la sangre de un sistema, fluyendo y alimentando cada proceso. Un enfoque disciplinado tanto en el registro como en la evolución del esquema proporciona la base para arquitecturas escalables, especialmente cuando se aspira a modelos distribuidos como los microservicios. Si tienes dudas o sugerencias sobre cómo gestionar migraciones, anima a compartir tus experiencias o preguntas en los comentarios.