Introduccion a Arquitectura de Software
Hola Gente! en este post vamos a estar viendo que es una Arquitectura de Software y cuales son sus propositos.
Es muy comun escuchar gente que se reusa a usar una arquitectura y suelen decir que es hacer sobreingenieria o que es demasiado el esfuerzo, en lo personal creo que el que piensa asi es por que realmente nunca aplico una arquitectura. Por lo que me gustaria con este post poder cambiar esa mentalidad y hacer entender la importancia que tiene una arquitectura en cualquier sistema.
Y por ultimo me gustaria aclarar que gran parte de este post esta inspirado en el libro de CleanArchitecture de UncleBob, realmente lo recomiendo ya que expande mucho mas todos los temas que veremos.
¿Que es la Arquitectura de Software?
Una definicion como tal no existe por lo que cada autor la a definido segun su criterio, estas son algunas de las que considero mejores:
David Garlan y Mary Shaw
La arquitectura es un nivel de diseño que hace foco en aspectos más allá de los algoritmos y estructuras de datos de la computación. El diseño y especificación de la estructura global del sistema es un nuevo tipo de problema.
UncleBob
La arquitectura de un sistema de software es la forma que le dan al sistema aquellos que lo crean. La forma se encuentra en la division del sistema en componentes, la organizacion de esos componentes y las formas en las que esos componentes se comunican entre si.
Entonces tomando en cuenta estas dos definiciones quedaria:
La arquitectura es la forma que le vamos a dar al sistema.
Va a ser la encargada de dividirlo en distintos componentes, los va a organizar y va crear reglas que determinan como comunicar estos componentes entre si, establenciendo un diseño y estructura que reflejan todo el sistema.
Como vamos viendo la arquitectura no es un algoritmo ni un codigo definido, sino mas bien una herramienta que utilizan los programadores para construir mejores sistemas.
¿Cuales son los propositos de una Arquitectura?
Como minimo una buena arquitectura deberia tener en cuenta estos propositios:
Facilitar el Desarrollo
Esto quiere decir que agregar o modificar componentes sea una tarea sencilla y que al hacerlo no se rompa nada del sistema.
Buenas practicas tales como Open/Close, TDD y DependencyInjection le dan forma a este principio.
Facilitar la Implementacion
Esto hace enfasis en que el costo de desarrollo debe ser el mismo durante todo el proceso de desarrollo del sistema. Ya que puede ser facil de desarrollarlo, en terminos tecnicos, pero cuando el sistema vaya creciendo el costo del desarrollo e implementacion debe ser siempre el mismo.
Revelar el funcionamiento
Esto quiere decir que al aplicar una arquitectura sabemos donde estamos parados y entendemos como movernos en el sistema, es decir que tanto su funcionamiento como su organizacion sean obvias, las cosas funcionan y estan como uno espera. Y esto se logra ya que la arquitectura implementa reglas y principios que resaltan al sistema, hacen que sea facil de recorrer y amplian el orden de los componentes.
Esto simplifica la comprension del sistema y por lo tanto el desarrollo y mantenimiento.
Mantenimiento
El constante agregado de features, la infinita lista de bugs y correciones consumen muchisimo tiempo en el desarrollo.
El coste principal del mantenimento esta en cavar en el software existente, intentando determinar el mejor lugar y la mejor estrategia para añadir una feature o corregir un bug.
Al hacer estos cambios, la probabilidad de crear nuevos bugs y problemas siempre esta ahi. Una buena arquitectura reduce en gran medida estos costes.
Mantener las opciones abiertas
Dejar la mayor cantidad de opciones abiertas durante el maximo tiempo posible. Esto quiere decir que una arquitectura deberia dejarte implementar o cambiar los detalles del sistema cuando vos quieras y mientras mas se pueda estirar esa decision va a ser mejor.
Pongamos de ejemplo que estamos haciendo un juego multiplayer, este sera un FPS al estilo Half Life, al pricipio del desarrollo no sabemos que api multiplayer vamos a usar, tal vez usamos Photon o tal vez escribimos la nuestra propia en .Net, ya que decidimos aplicar una arquitectura como MVP realmente no tenemos por que tomar la decision de que api elegir en este momento. Y esto se logra gracias a que aplicamos reglas y principios como dividir al sistema en componetes, entonces si lo vemos asi la api para el multiplayer solo sera un componente mas que conectaremos al sistema cuando nosotros queramos, esto nos da pie a probar con todas las api que queramos sin necesidad de reescribir nuestro sistema inicial.
En lo personal este es el proposito mas importante de una arquitectura. Y si quieren saber mas acerca de como aplicar esto de la mejor forma les recomiendo que investiguen sobre DependencyInversion y DependencyInjection.
Otros propositios
- Mejora la comunicacion con el equipo y con vos mismo del futuro.
- Te centra mas en la problematica del sistema que de la organizacion.
- Divide las resposabilidades y hace mas facil el trabajo en equipo.
- Maximiza la productividad del programador.
- Minimiza el coste de vida del sistema.
- Respalda el ciclo de vida del sistema.
Tipos de arquitecturas
Existen miles de tipos de arquitecturas y cada una resolve problemas distintos pero estas son las mas importantes.
- Layered architecture.
- Event-driven architecture.
- Microkernel architecture.
- Microservices architecture.
- Space-based architecture.
- Client-Server architecture.
Layered architecture
La idea de este tipo de arquitectura es organizar en capas los componentes con funcionalidades similares. Esto da como resultado que cada capa ejecute un rol especifico dentro del sistema.
Generalmete podemos dividir el sistema en tres grandes capas:
La capa de la Vista, esta es la que se encarga de todo lo que tenga que ver con la interaccion con el usuario y todo lo que se representa visualmente. Ejemplo de esto es la UI y todo lo que se muestra en el juego como los modelos 3D y los Sprites.
La capa de Presentacion, esta es la encargada de transformar los datos del usuario a datos que nos sirvan mejor para resolver el problema y de darle forma a los datos del modelo para poder mostrarlos de forma conveniente en la vista. Por ejemplo cuando un usuario toque un boton, la vista le avisara a la capa de presentacion y esta le dira exactamente al modelo que hacer, como por ejemplo abrir una puerta o spawnear un enemigo.
La capa de Modelo/Dominio, esta es la encargada de contener las soluciones para el problema y es la que maneja el flow del programa.
Este tipo arquitectura es la mas utilizada para unity y ejemplos de ella son:
- MVC.
- MVP.
- MVVM.
- CleanArchitecture.
Limites
La aquitectura de software es el arte de trazar lineas que yo llamo limites.
Esto segun UncleBob, pero ¿Que significa?, estos limites separan los elementos de software/componentes entre si, y evitan que los de un lado conozcan a los del otro lado, por ejemplo al modelo no le importa si la vista se esta mostrando en un Canvas UI, en GUI o en UIToolkit y tampoco le importa que lo que haga la capa de presentacion con los datos que le envia. Esos son ejemplos de limites y es regla obligatoria nunca cruzarlos, ya que al hacerlo se rompen las resposabilidades y problablemente el proposito de mantener la mayor cantidad de opciones abiertas.
Conclusion
Aplicar una arquitectura puede ser un poco complejo al principio debido a que el material de estudio es dificil de conseguir y tambien por que suele haber un ambiente muy negativo con respecto a las buenas practicas que deberia tener un programador de videojuegos, pero una vez que entendes como funciona solo trae beneficios.
Si te quedaste con ganas de aplicar una arquitectura te recomiendo que empieces por este post sobre MVP para entender de que va y despues intentes hacer este ejemplo de como aplicar MVP en una pantalla de Login.
Espero que el post te haya sido util! y cualquier consulta o duda no dudes en comentar o escribirme a mi mail: LaurencioBerro@gmail.com.
