Getting the Basics - Software Architecture Introduction (part 1) - YouTube

La arquitectura es el proceso y el producto de la planificación, el diseño y la construcción de edificios

u otras estructuras. Un buen diseño puede hacer que una estructura sobreviva y sea admirada durante años

o incluso que no se mantenga en pie. El trabajo del arquitecto es unir el arte y la ciencia

para asegurarse de que todas las piezas de un edificio se unan en una buena solución.

Al igual que los arquitectos, como Ingeniero de Software, también necesitas mezclar arte y ciencia

para ofrecer soluciones de manera satisfactoria, pero en lugar de ladrillos, las resolverás con código.

Hola, soy Christian y estás viendo A Dev' Story. Hoy comenzaré una nueva

serie de videos que cubren la arquitectura de software de una manera práctica. En esta serie de videos,

cubriré muchos conceptos y fundamentos de la arquitectura de software. Al final de la serie espero que

te sientas más preparado para abordar los desafíos del diseño de software, tener mejores discusiones

e incluso estar más preparado para una entrevista técnica. Así que, sin más preámbulos, comencemos.

La arquitectura de software tiene muchas definiciones, una de las más famosas es de Ralph Johnson,

donde dice: "la arquitectura se trata de lo importante, sea lo que sea"

pero ... ¿qué es lo importante? En la arquitectura de software, nos centramos más en la

estructura que en los detalles de implementación. La arquitectura del software también se trata de tomar

decisiones costosas que son difíciles de cambiar una vez implementadas. También se trata de hacer

explícitas las decisiones centrales que permitirán que el software tenga una alta calidad. Los conceptos

se comprenden mejor en la práctica, así que creemos un sitio de comercio electrónico y veamos cómo se ve.

Por ejemplo, en nuestro sitio de comercio electrónico debemos permitir que nuestros usuarios hagan ciertas cosas como buscar en

el inventario, revisar reseñas, comprar un producto, revise pedidos anteriores y tal vez también otras características.

Estos son los requisitos funcionales de la aplicación. Además de lo que debería hacer el sistema,

también debemos centrarnos en cómo debería comportarse el sistema. Estos también se denominan

requisitos no funcionales. A veces se definen como las "-ilidades" que puede tener el sistema,

como: funcionalidad, confiabilidad, usabilidad, eficiencia, este tipo de cosas. Por ejemplo,

en nuestro sitio de comercio electrónico, digamos que querríamos que se pudiera mantener durante varios años y este es

un requisito de mantenimiento; también queremos poder servir a millones de usuarios: en este caso es la

escalabilidad; queremos que esté disponible las 24 horas del día, los 7 días de la semana: lo cual es una confiabilidad para asegurarnos de que el

sistema sea muy estable. También queremos tener una buena latencia de respuesta: que es la eficiencia; y podemos

tener muchos otros. Finalmente, además de los requisitos funcionales y no funcionales, también puede

tener restricciones adicionales que limitarán las opciones que tendrá para su arquitectura.

Entonces, por ejemplo, podríamos tener algún cumplimiento legal, costos, time to market, estándares, etc.

varias restricciones que limitarán la cantidad de opciones que tendremos para diseñar nuestro sistema.

Digamos que en nuestro sitio de comercio electrónico debemos cumplir con la Ley de Privacidad Europea:

GDPR. Entonces, con eso, debemos tener en cuenta la arquitectura sobre cómo manejar eso.

Entonces, después de obtener el contexto, sabrás todas las cosas que debe hacer el sistema,

cómo debe comportarse y qué restricciones existen que debe tener en cuenta. Entonces,

después de tener todas estas cosas, debes priorizarlas. Algunos requisitos y

restricciones entrarán en conflicto entre ellos. Por ejemplo, si tienes un tiempo estricto de entrega en el mercado,

tal vez necesites eliminar algunas funciones. También puede haber otras cosas, como requisitos

no funcionales , que deben priorizarse. Entonces, por ejemplo, en nuestro caso del sitio de comercio electrónico, es

posible que no nos importe demasiado la portabilidad porque tendremos un fuerte control de dónde se

ejecutará la aplicación y no planeamos moverla a

otras plataformas. Por lo tanto, podríamos abandonar la portabilidad en favor de la escalabilidad o la mantenibilidad. Entonces, después de

haber priorizado la lista y haber analizado los pros y cons, debes pensar si es

aceptable o no. Después de que sea aceptable, comienza a diseñar la arquitectura.

¿Cómo empiezas a diseñar el sistema? Lo primero es que una vez que lo tengas priorizado, comienza

con una cosa importante a la vez. Si intentas abordar todo desde el principio y tratas

de pensar en todos los escenarios posibles en el futuro, puedes terminar teniendo una

solución sobre-diseñada y esto no es bueno porque sería un sistema innecesariamente complejo. También hay un

acrónimo para eso es YAGNI: No lo vas a necesitar (del inglés: You Ain't Going to Need It). Entonces, si no estás seguro de algo o si

no tiene prioridad, intenta no abordarlo al principio. Trata de posponerlo para cuando tengas más

contexto y puedas tomar una mejor decisión al respecto. Ahora que tenemos esto, podemos comenzar a pensar

en cuáles son las posibles arquitecturas que podrían adaptarse a nuestro sistema. Un buen libro

que recomiendo y que me es útil, es este ebook gratuito de O'Reilly que es: "Patrones de

Arquitectura de Software". Es un buen libro para comprender diferentes enfoques arquitectónicos

y puede ver varios patrones arquitectónicos como: Por Capas, Orientado a Eventos, Micronúcleo,

Microservicios

y Basado en Espacio. Este libro muestra los pros y los contras de cada uno de estos patrones y es muy útil al

principio cuando estás diseñando el sistema, qué buscar y qué sería mejor para nuestro

sistema según los requisitos actuales. Así que hemos decidido cuáles son algunas de las características que

queremos que implemente nuestro sistema. También hemos mencionado que la mantenibilidad es uno de los

requisitos no funcionales que es muy importante para nosotros, por lo que podemos comenzar a diseñar nuestro

sistema y podemos tomar, por ejemplo, un enfoque por capas. Podríamos tener una Base de Datos o una

Capa de Persistencia donde almacenaríamos los datos; luego tendremos una Capa de Lógica donde tendremos los

servidores de backend que se encargarán de manejar cualquier lógica de negocios que querramos manejar;

y luego la parte de Visualización o UI, donde estaremos permitiendo que los usuarios interactúen con el sistema

y así es como llegamos a la Arquitectura por Capas (Layered Architecture)

Así que aquí hemos definido la arquitectura con la estructura que tendrá el sistema.

Las funciones se pueden implementar siguiendo esta arquitectura por capas. Si deseas

aprender un poco más sobre cómo implementar las funcionalidades de una manera correcta y escalable, te recomiendo

mi otro video sobre patrones de diseño. Es muy típico en las aplicaciones web

usar una arquitectura por capas, pero no es el único patrón arquitectónico que podemos usar.

No existe una solución milagrosa, así que asegúrate de que, en tu contexto, tengas diferentes enfoques y

elije el patrón de arquitectura que se adapte mejor a tu caso de uso. También es normal que la

arquitectura evolucione con el tiempo y, a veces, incluso de formas no deseadas que harían cambios costosos

en la arquitectura. Por lo tanto, debes buscar un equilibrio entre la previsión de ciertas cosas

que debes cubrir frente a las cosas que debes priorizar en el corto plazo.

Si intentas abordar todo, puedes terminar teniendo una solución de sobre diseñada, innecesariamente compleja.

Una de las cosas más costosas de implementar tarde puede ser escalar. Entonces, en nuestro caso, ya tenemos la arquitectura:

¿Cómo podemos escalar para atender millones y millones de solicitudes de usuarios?

Para eso, mira mi próximo video. ¡Y eso es todo por hoy! Muchas gracias

por mirar y si te gustó el video no olvides hacer clic en el botón Me gusta, suscríbete y

compártelo. Y si me perdí algo, o si quieres que te explique algo un poco mejor, no

olvides mencionarlo en la sección de comentarios a continuación, muchas gracias hasta la próxima.