Software Architecture — Cheat Sheet

1. Introducción

La arquitectura de software es el puente entre los objetivos de negocio y el sistema.

• Objetivos de negocio: metas medibles que una organización busca alcanzar y que motivan el desarrollo de un sistema.
• Proceso de negocio: secuencia de actividades, hechas por personas y/o sistemas, que se inicia con un evento y produce un resultado de valor para un cliente.
• Requisitos: lo que el sistema debe cumplir para soportar la parte automatizada de los procesos de negocio.
• Funcionales: comportamientos, lo que el sistema hace.
• Atributos de calidad: qué tan bien lo hace (seguridad, rendimiento, usabilidad, mantenibilidad, etc.), expresados como escenarios medibles. Los atributos de calidad se derivan de lo que se conoce como objetivos de negocio.
• Restricciones: Decisiones ya tomadas que limitan el diseño y no se negocian. Por ejemplo: 
• Administrativas (costo y tiempo)
• Técnicas
• Usar productos de software de terceros.
• Métodos de diseño o implementación.
• Lenguajes de programación
• Plataforma o infraestructura.
• Drivers arquitectónicos: subconjunto de requisitos que tienen un impacto significativo en la estructura del sistema y guían las decisiones de arquitectura. Se priorizan por importancia para el negocio y dificultad técnica.
• Drivers funcionales
• Drivers de atributos de calidad
• Drivers de restricciones

2. Diseño de la Arquitectura

En esta sección se describe la manera en que se realiza el diseño de la arquitectura del sistema cuyos drivers fueron listados previamente. El diseño se lleva a cabo de acuerdo al método ADD y por ello se presenta el diseño por medio de varias iteraciones.

2.1. Primera iteración: Estructuración general del sistema

• Elemento a descomponer: El sistema (iteración inicial)
• Drivers elegidos para la iteración: Dado que es la iteración inicial, el objetivo es proponer una estructuración general del sistema. Para hacerlo, se toma en cuenta el conjunto de historias de usuario primarios y escenarios de atributos de calidad, así como las restricciones.
• Conceptos de diseño: 
• Arquitectura Hexagonal: Se propone adoptar una arquitectura hexagonal (también conocida como arquitectura de puertos y adaptadores) para desacoplar la lógica de negocio del sistema de las dependencias externas, como bases de datos o servicios externos. Esto permite una mayor flexibilidad y facilidad para realizar pruebas unitarias.
• Walking Skeleton: Walking Skeleton es una versión mínima pero funcional del sistema que recorre toda la arquitectura de punta a punta. Su objetivo es establecer las bases técnicas y arquitectónicas del proyecto desde el inicio. Se debe comenzar con un walking skeleton que permita validar la estructura general de la aplicación, desde la interfaz hasta la base de datos o servicios externos. Este walking skeleton debe estar cubierto por una prueba de aceptación end-to-end, asegurando que todo el flujo básico funcione correctamente. Además, debe incluir desde el inicio el proceso completo de versionado, build, test y deploy hacia un entorno similar a producción, siguiendo un esquema de integración continua (CI). En resumen, el walking skeleton permite tener una primera versión del sistema que “camina” de extremo a extremo, demostrando que la arquitectura, el pipeline y la automatización están correctamente configurados.