Tácticas para confinar modificaciones
Clase 33 de 43 • Curso Profesional de Arquitectura de Software
Contenido del curso
Atributos de calidad
- 2

Qué son los atributos de calidad en software
01:49 min - 3

Cómo medir idoneidad funcional en software
02:52 min - 4

Qué es eficiencia de ejecución en software
04:14 min - 5

Cómo medir interoperabilidad y coexistencia
03:49 min - 6

Qué es la usabilidad y sus 6 dimensiones
08:14 min - 7

Cómo medir confiabilidad en software
05:38 min - 8

Los 5 pilares de seguridad en software
04:01 min - 9

Cómo garantizar mantenibilidad con tests
06:27 min - 10

Adaptabilidad vs capacidad de instalación vs reemplazo
02:48 min - 11

Tensiones entre atributos de calidad de software
04:04 min - 12

Atributos de calidad según fase de empresa
07:00 min
Patrones de arquitectura
- 13

Qué es un patrón de arquitectura
02:50 min - 14

Modelo vista controlador: cómo separar responsabilidades
05:37 min - 15

Arquitectura en capas: controller, servicio y repositorio
03:14 min - 16

Event sourcing vs bases relacionales
06:17 min - 17

Qué es la arquitectura microkernel
01:52 min - 18

Arquitectura Comparte Nada con Map Reduce
02:29 min - 19

Patrón de microservicios: cuándo y cómo
03:57 min - 20

Qué es CQRS y cómo separa lectura de escritura
03:24 min - 21

Arquitectura hexagonal: puertos y adaptadores
04:10 min - 22

Qué son los contextos delimitados en DDD
05:34 min - 23

Cómo combinar patrones de arquitectura
09:22 min - 24

Evolución de patrones desde monolito a microservicios
07:58 min
Diseño de una arquitectura
- 25

Cómo traducir requerimientos en decisiones arquitectónicas
02:18 min - 26

Conectores en arquitectura: tipos y cuándo usarlos
06:18 min - 27

Llamadas asíncronas vs síncronas vs cliente-servidor
03:05 min - 28

Conector enrutador vs difusión: Twitter
01:55 min - 29

Conectores cola, repositorio y pub/sub
03:52 min - 30

Framework de diseño orientado a atributos
01:55 min - 31

Cómo detectar fallas y reparar sistemas
05:59 min - 32

Cómo recuperar y prevenir fallas en sistemas
04:09 min - 33

Tácticas para confinar modificaciones
Viendo ahora - 34

Cómo prevenir efectos dominó en software
12:17 min - 35

Tácticas para controlar eficiencia de ejecución
09:14 min - 36

Cómo detectar, resistir y recuperarse de ataques
09:02 min - 37

Cómo probar que el software funciona correctamente
05:14 min - 38

Cómo controlar la usabilidad con tácticas
08:20 min - 39

Cómo validar arquitectura con ATAM y métricas
06:34 min - 40

Evolución de arquitectura: startup a gran escala
10:30 min
Modelado y documentación de arquitectura
La mantenibilidad es clave para sostener la evolución de un sistema sin fricción. Aquí se explica, con enfoque práctico, cómo responder a un pedido de cambio: hacerlo, probarlo y desplegarlo con mínimo impacto. Verás tácticas para confinar modificaciones, prevenir efectos dominó en dependencias y diferir enlace para evitar redeploys completos.
¿Qué define la mantenibilidad y cuál es el estímulo de cambio?
La mantenibilidad se activa ante un pedido de cambio: llega un nuevo requerimiento y el sistema debe adaptarse. La meta es que el cambio esté acotado, se pruebe con confianza y se despliegue sin afectar otras partes.
- Confinar modificaciones: cambios localizados en un módulo.
- Prevenir efectos dominó: gestionar dependencias para detectar impactos cruzados.
- Diferir enlace: aplicar cambios sin redeploy de toda la aplicación; más simple en lenguajes interpretados que en compilados.
¿Cómo confinar modificaciones con coherencia semántica y servicios comunes?
Confinar implica que cada cambio afecte lo mínimo posible. Para lograrlo, hay que alinear responsabilidades, dependencias y puntos de extensión.
¿Qué es la coherencia semántica y por qué mejoran la cohesión y el acoplamiento?
La coherencia semántica relaciona responsabilidades dentro de un módulo. Cuando un módulo es cohesivo, cambia por una sola razón y es más mantenible. Si no es cohesivo, cambia por motivos diversos y se vuelve frágil. Reducir acoplamiento y elevar cohesión hace que los cambios no se propaguen.
- Un módulo cohesivo concentra responsabilidades afines.
- Menos acoplamiento implica dependencias más ligeras.
- Cambios localizados reducen riesgos y esfuerzo.
¿Cómo abstraer servicios comunes como logging, autenticación y API?
La táctica de abstraer servicios comunes mueve funcionalidades transversales a un módulo dedicado: logging, autenticación y autorización, integraciones compartidas. Las partes de negocio (ventas, compras) dependen de ese servicio externo, que puede ser un módulo separado sin ser un componente aislado.
- Modificar el módulo de ventas no obliga a cambiar el de login.
- Mejorar el logging (por ejemplo, registrar fecha o tiempos) no impacta a los módulos que lo usan.
- Se mantiene el cambio confinado y las dependencias controladas.
¿Cómo generalizar, limitar opciones y anticiparse a cambios con patrón de estrategia?
Estas tácticas estabilizan la base y preparan el sistema para nuevas variantes sin reescrituras amplias.
¿Por qué generalizar separa lo genérico de lo específico?
Generalizar crea una capa estable con lo genérico (interfaces, clases abstractas, conceptos globales) y aísla lo específico (implementaciones, recursos variables como sistema de archivos o API). Así, las variaciones se incorporan sin tocar la estructura estable.
- Lo genérico cambia menos y ofrece contratos claros.
- Lo específico evoluciona sin romper a los clientes.
- Aumenta la estabilidad y la mantenibilidad.
¿Cómo limitar opciones en integraciones como plataformas de pago?
Limitar las opciones disponibles evita cambios radicales. Si se sustituye una plataforma de pagos, conviene mantener una interfaz similar: seguir usando API, conservar el flujo de estados (por ejemplo, pendiente, apagado o cancelado), y alinear interacciones externas.
- Se reducen desvíos funcionales.
- Se minimizan ajustes internos.
- El esfuerzo de prueba y despliegue baja.
¿Cómo anticiparse a cambios con patrón de estrategia?
Anticiparse a los cambios prepara el terreno: no se implementa de antemano, pero sí se deja una estrategia lista para incorporar la novedad. Cuando los algoritmos de un proceso cambian o se necesita una familia de algoritmos, el uso de un patrón como estrategia permite cambiar la variante en ejecución y agregar nuevas sin tocar el flujo.
- El proceso ya espera nuevas estrategias.
- Se elige el algoritmo adecuado en tiempo de ejecución.
- Se facilita la incorporación de cambios futuros.
¿Tienes dudas o un caso real donde aplicar estas tácticas? Comparte tu contexto en los comentarios y conversemos cómo confinar tu próximo cambio con el menor impacto posible.