Tech-Notes

Blog de notas sobre Software, Ingeniería y Tecnología

Project maintained by matiaspakua Hosted on GitHub Pages — Theme by mattgraham

Evolutionary Architecture: the art of making decisions

Autor

José Enrique Calderón Sanz Lead Software Engineer @ J.P Morgan & Chase

Linkedin: https://www.linkedin.com/in/josecalderonsanz

Introducción

“Sagrada familia”. la originalidad consiste en regresar a los orígenes. Gaudi Quote.

Que aprender de la arquitectura clásica? Tenemos más de 11.000 años de historia construyendo estructuras físicas.

Analogía con el juego de Legos => sirven para crear representaciones físicas de “ideas”, el software es similar a los legos pero sin el aspecto físico.

Arquitectura evolutiva

El negocio siempre quiere cambios y los quiere ahora y baratos. => “decisiones”.

Las grandes preguntas de la ingeniería de software:

  1. Como hacer planes a mediano/largo plazo, cuando las cosas cambian en el transcurso del tiempo.
  2. Como puedo prevenir que el producto se degrade, con el transcurso del tiempo.

Como responder a éstas preguntas?

Framework para toma de decisiones

Del Libro: The software architecture elevator. Gregor Hohpe.

–> Poner foco en decisiones pertinentes

  1. Decisiones no triviales.

Estas son decisiones que no tienen una respuesta obvia o estándar. Implican un análisis cuidadoso y una comprensión profunda del problema, ya que afectan significativamente el diseño y el comportamiento del sistema. Estas decisiones suelen requerir la evaluación de múltiples alternativas y sus respectivas consecuencias.

Ejemplo: Decidir entre una arquitectura de microservicios y una monolítica para una nueva aplicación empresarial.

  1. Deben tener un downside

Se refiere a que las decisiones de arquitectura de software suelen tener desventajas o "costos" asociados. No existe una solución perfecta; por lo tanto, es crucial identificar y considerar los posibles inconvenientes o compromisos que una decisión puede acarrear. Reconocer estos “downsides” ayuda a mitigar riesgos y a preparar estrategias de contingencia.

Ejemplo: Elegir utilizar una base de datos NoSQL en lugar de una base de datos relacional tradicional.

Aspecto Base de Datos Relacional Base de Datos NoSQL
Escalabilidad Limitada horizontal Complejidad horizontal
Modelo de Datos Esquemas rígidos Esquemas flexibles
Transacciones ACID garantizado Consistencia eventual
Consultas Complejas Soporte robusto Limitaciones
Mantenimiento Mayor mantenimiento Menor mantenimiento
Consistencia Consistencia fuerte Consistencia eventual
Rendimiento Potencialmente lento Alto rendimiento
Costo Costoso Económico, pero variable
  1. Decisiones significativas: Meaningful.

Estas decisiones tienen un impacto considerable en el sistema y su desarrollo. No se centran en detalles menores o decisiones que pueden ser revertidas fácilmente, sino en aquellas que afectan aspectos críticos del sistema, como su escalabilidad, rendimiento, seguridad o mantenibilidad. Las decisiones significativas tienen un efecto duradero y son difíciles de cambiar una vez implementadas, por lo que deben tomarse con cuidado y reflexión.

Ejemplo: Adoptar un marco de autenticación y autorización (como OAuth) para la gestión de acceso en una aplicación de alto riesgo.

Alternativa Características Impacto en el Sistema
OAuth 2.0 Protocolos estándar, amplia adopción Seguridad robusta, implementación compleja
SAML (Security Assertion Markup Language) Federado, basado en XML Integración con empresas, alto overhead
JWT (JSON Web Tokens) Simple, ligero, sin estado Fácil de usar, menos seguro sin SSL

–> SIMPLICIDAD como el verdadero NORTE. –> Hacer cosas complejas no siempre es la mejor opción. –> Necesito ver la solución claramente. Entendiendo las restricciones del contexto. –> Incertidumbre genera perdida de confianza, como eliminarla: EXPERIMENTANDO.

Experimentar para eliminar la Complejidad

Ejemplo: Experimento de Gaudi con los pesos dados vueltas para modelar la física y pesos de la iglesia. Proof-of-concepts de las estatuas.

–> Necesitamos validar algo, y si falla, que falle rápidamente. Usar modelos, referencias, ejemplos. –> POC hacerlo fuera de tu dominio de negocio. –> Evitar creatividad innecesaria, usar los elementos más básicos disponibles. –> como hacer cosas complejas => DOCUMENTACIÓN. –> Como documentar: DIAGRAMAS.

Cómo Documentar? Diagramas

–> C4 model.

web -> The C4 model for visualising software architecture

C1 - System Context

C2 - Contenedor

C3 - Componente

C4 - Código

Cómo Documentar? ADR’s

–> ADR or SAD -> lo más sencillo son ADR.

web: adr.github.io

Example: monorepo-vs-multirepo

Decisiones Anti-Patrones

AI para acceder a la documentación