Definición de Arquitectura de Software

1. Primera definicion tomada de Software Architecture in Practice, 3rd edition

La arquitectura de software de un Sistema es el conjunto de estructuras necesarias para razonar

acerca del sistema.

Estructura: cómo organizar las partes del sistema y cómo conectarlas. Para esto utilizamos
patrones de arquitectura ya sea eventos, capas, micro servicios nos va a decir que componentes
necesitamos y como se interconectan.

Razonar: la idea es que la arquitectura de software sirva para que el equipo de desarrollo y en
general el equipo técnico pueda tener discusiones acerca del sistema a un alto nivel, este alto nivel
lo da la arquitectura y facilita las discusiones.

2. Segunda definición tomada de Design it! From Programmer to Software Architecture

La arquitectura de software es el conjunto de decisiones de diseño importantes para organizar el

software y promover los atributos de calidad deseados.

Decisiones de diseño: tenemos que definir para nuestra arquitectura cuales son las decisiones de
diseño que van a guiar el trabajo del equipo.

Ejm:

Patrón de arquitectura: Micro servicios

Decisión de diseño: Los micro servicios van a trabajar todos contra una misma base de datos y
no que cada micro servicio tenga una base de datos individual.

Estas decisiones de diseño se tienen que documentar para comunicar al equipo.

Atributos de calidad: Son muy importantes para el arquitecto pues le permiten definir qué es lo
que va más allá de lo funcional que va a garantizar que el sistema funcione bien.

Ejm:

Tenemos varios Atributos de calidad, lo ideal es elegir los más importantes para la aplicación

 Facilidad de mantenimiento
 Desplegabilidad
 Escalabilidad
 Elasticidad
 Entre otros muchos

3. Tercera definición tomada de Ralph Johnson

La arquitectura es acerca de las cosas importantes. Sean las que sean.

Lo que quiere decir básicamente Ralph Johnson es que dependiendo de la persona o empresa, la
arquitectura puede tener distintos elementos, por ejemplo:
Si la arquitectura la está revisando el Product Ouner o el dueño del producto pues para él
seguramente van a ser muy importantes las características y como están reflejadas en la
arquitectura del producto.

Si la revisa un desarrollador probablemente para este debe ser muy importante el lenguaje de
programación o el framework que se va a utilizar.

Para el soporte técnico lo más importante puede ser la infraestructura, donde van a estar
desplegadas las maquinas, en qué lugar se encuentran las bd.

De eso entonces se trata esta definición, de entender que dependiendo del equipo hay distintos
elementos fundamentales para la arquitectura.

¿Para qué sirven los patrones de

arquitectura?
¿Cómo funciona esto en la práctica?... comenzamos un nuevo proyecto, el usuario nos da todas
las cosas que necesita que hagamos que se convierten en requerimientos llámese historias de
usuario, llámese casos de uso, etc. A partir de esto se hace un estimado, se definen tiempos, se
forma un equipo y luego surge la pregunta…

¿Cómo empiezo a desarrollar la aplicación?

Si nos encontramos con un equipo que no tiene mucha experiencia de diseño comienzan las
dudas, agregando funcionalidad por funcionalidad y nunca pensamos en cómo vamos a estructurar
el código, como organizar las vistas, los controladores y nos dejamos llevar por el Frameworks,
dejamos que el Framework dicte la arquitectura y este es un problema muy grande pues vamos a
amarrar la aplicación a lo que el framework diga entonces cualquier cambio que haya en el
framework va a afectar la aplicación.

Si estamos comenzando desde cero sin ningún Framework, entonces vienen muchas dudas sobre
¿qué estructura de carpetas hacer?, ¿organizar por capas o por dominio?, ¿Cómo empiezo a
estructurar todo esto? Etc. Muchas preguntas se vienen y frenan todo por muchísimo tiempo, es
aquí entonces donde vienen los patrones de arquitectura

Los patrones de arquitectura son soluciones o estructuras que ayudan a definir la aplicación desde
el nivel más grande. No es como el patrón de diseño que está muy enfocado a un problema en
particular, por ejemplo, si necesitamos implementar un Ctrl + z en la aplicación para esto existe el
patrón de memento y sin ningún problema ese es la situación que enfrento y así es como la
resuelvo.

Con un Patrón de arquitectura nos enfocamos a gran nivel, como estructuro la aplicación para
luego comenzar a poner los distintos componentes en cada una, es aquí donde vienen los
patrones de arquitectura por capas, orientadas a eventos y muchos otros.

Entonces la gran utilidad de los patrones de arquitectura

es dar ese lineamiento para poder comenzar a definir la
aplicación.
Ahora! no caigas en el error habitual de pensar que todo se resuelve con una arquitectura por
capas y que para todo hay que utilizar MVC, pues existen muchos patrones de arquitectura a parte
de estos que nos van a ayudar a estructurar muy bien la aplicación dependiendo de cada uno de
los casos.

¿Qué es un Framework?
Un Framework es un marco de trabajo, es un conjunto de:

 Convenciones, estándares o paradigmas y buenas practicas

 Funcionalidades costosas ya desarrolladas

Es decir, con un Framework lo que hacemos es ahorrarnos al final trabajo, esto mejora mucho
nuestro código, nos obliga a hacer buenas prácticas y seguir los estándares, además si entramos a
un proyecto que otra persona lo ha programado y está escrito con framewoks es más fácil
adaptarse al proyecto y se pueda programas sobre él.

Una de las grandes ventajas es que ya tenemos muchas cosas hechas, funcionalidades ya
desarrolladas.

Los objetivos de un Framework:

 Servir como base para los programas o proyectos web.

 No reinventar la rueda, es decir, no estar programando una y otra vez las funcionalidades
como hacer una paginación o un Login.
 Evitar tareas repetitivas, conexiones bd o Login.
 Aumentar la productividad, pues al tener ya las cosas hechas nos centramos en el
problema que tenemos que resolver.
 Favorece el trabajo en equipo, ya que si todo el mundo trabaja con los mismos estándares,
paradigmas o la misma metodología al final el trabajo es más rápido y con mucha más
calidad.
 Infundir buenas practicas ya que nos enseña a como se hacen las cosas.

Construye tu aplicación, no tus herramientas.