Arquitectura de software

¿Qué? ¿Por qué? ¿Quién? ¿Cómo?

Arquitectura

Es la "forma" que le da al software quién lo diseña

División en componentes
Agrupación de componentes
Comunicación de esos componentes

Objetivo

Facilitar el desarrollo, operación y mantenimiento del sistema de software

La estrategia es mantener tantas opciones abiertas como sea posible por el máximo tiempo posible

Desarrollo

Un sistema que es difícil de mantener no va a tener una vida larga y saludable

Diferentes estructuras de equipos implican diferentes decisiones arquitectónicas

Equipos chicos empiezan sin una estructura clara. Es por eso que generalmente faltan buenas arquitecturas

Despliegue

Todo sistema de software debe ser desplegable

Mientras más alto es el costo de despliegue, menos útil es el sistema

El sistema debe ser desplegable con una sola acción

Mantenimiento

Es la actividad más costosa

Un flujo interminable de features y una inevitable cola de defectos

El riesgo de agregar más defectos aumenta con el paso del tiempo

Mantené las opciones abiertas

Todo sistema tiene 2 tipos de valor: Comportamiento y estructura

La estructura hace que el software sea soft*.

La política es lo mas esencial de un sistema de software. Los detalles no importan

Ejemplos

No es necesario definir la base de datos en etapas tempranas del proyecto. A la lógica del negocio no debería importarle la persistencia

No es necesario definir el servidor web

No es necesario definir el framework

No es necesario definir la API REST

Mientras más información tengas, mejores decisiones podés tomar

Hasta que tomes la decision correcta, podes ir experimentando con distintas cosas para ver qué es mejor.

¿Base de datos relacional? ¿NoSQL? ¿Hadoop? ¿Archivos indexados? ¿Solo memoria?

La arquitectura se va deteriorando de a poco

Duplicación

Conflictos de merge

Rígidez

Para un cambio pequeño hay que tocar en muchos lugares

Fragilidad

Desconfianza

Baja productividad

Consejos para tener arquitecturas saludables

No te cases con el framework

Es tentador adaptar mi arquitectura al diseño de un framework

Los frameworks no son para siempre :(

Lo mismo aplica para la base de datos, servidor web, sistema operativo, etc.

La buena arquitectura empieza con buen código

Principios SOLID

Principio de responsabilidad única: Cada módulo debe tener una única razón para cambiar
Principio abierto-cerrado: Abierto para extensión, cerrado para modificación
Principio de sustitución de Liskov: Contrato sobre intercambiabilidad de partes
Principio de segregación de interfaces: No dependas de cosas que no necesites
Principio de inversión de dependencia: El código de alto nivel no debe depender de código de bajo nivel

Límites arquitectónicos: Dibujá líneas

Separá componentes uno de otros

No dejes que un componente sepa mucho sobre otro

Estas lineas se deben dibujar en etapas tempranas del proyecto

Cruzar los límites: Regla de la dependencia

Las dependencias deben ser del componente de menor nivel de abstracción hacia el de mayor nivel de abstracción

Arquitectura limpia

Bibliografía

Clean Architecture - Robert C. Martin