Patrones de Arquitectura

¡Hola a todos! Uno de los cursos más interesantes que imparto es el de "Patrones de Arquitectura", donde se estudia el modelo de solución de diferentes proyectos y problemas habituales en cuanto a su arquitectura. Me he encontrado frecuentemente muchas dudas al respecto durante la impartición, así que he decidido clarificar un poco los conceptos previos con este blog.

Considero que todo buen desarrollador o arquitecto podría hacer buen uso de estas soluciones, y es por ello que en esta entrada intento iluminar algunos puntos de interés. Comenzamos con una definición, como no podría ser de otra manera.

Un patrón es una idea o, dicho de otra manera, es una forma de resolver un problema que no se ata a ningún lenguaje ni software específico. Esta definición nos ha acompañado durante años y últimamente está en boga, debido, como siempre, a las necesidades de nuestra sociedad y empresas respecto a los tipos de productos de software que hacemos.

Modelo MVC

Desde el inicio, los arquitectos de software hemos querido hacer las cosas bien y estudiar la mejor manera que radique en el complicado equilibrio entre mantenibilidad, velocidad y desacoplamiento de nuestros productos.

Así pues, el patrón MVC (Modelo-Vista-Controlador) y el patrón de Arquitectura de capas fueron los primeros creados para tal efecto. La división del código del producto en diferentes capas nos ofrecía un resultado esperanzador, ya que nos permitía que los desarrolladores se enfrentaran en resolver el código en menos líneas, ofreciendo una reusabilidad de las diferentes capas entre sí.

Modelo de microservicios

En los tiempos de las arquitecturas monolíticas estos patrones pegaron fuerte… hasta que llegaron a nuestra vida los terminales móviles. Y es que la llegada de los móviles a nuestras vidas cambió nuestra sociedad desde el inicio, provocando que los usuarios ganaran una dependencia de esos pequeños aparatitos para todo. Desde compras online hasta juegos, pasando por las mismas instituciones del estado que ofrecían sus formularios… todo, hoy en día, se puede hacer con un terminal móvil.

Esta necesidad de velocidad y de tener las aplicaciones funcionando 24/7 se resolvió olvidando las viejas arquitecturas monolíticas tan usadas y pasando al patrón de Microservicios, que nos ofrecía dividir la aplicación en diferentes aplicaciones más pequeñas según disponibilidad. 

Y, a esto, teníamos que unir el uso de eventos en nuestro desarrollo, provocados tanto por nuestros clientes como por otras aplicaciones que resolvían el problema de aplicaciones de “tiempo-real” estilo chats, pujas u otras aplicaciones que necesitaban tener su información completamente actualizada. A este patrón se le denominó Orientado a eventos.

Modelo DDD siguiendo el patrón Hexagonal

Mediante estos últimos patrones se resolvían muchos de los problemas de nuestra sociedad actual pero otro surgía: nuestros usuarios eran cada vez más numerosos y el número de peticiones aumentaba en la misma proporción.

Así pues, se estimó proteger, de alguna manera, nuestros sistemas de información de un número de peticiones tan elevado. 

Se estudió la segregación de nuestras peticiones entre las de lectura y escritura, dividiendo y usando dos sistemas de información que se actualizarán entre sí mediante el patrón Orientado a eventos. Este nuevo patrón se llamó CQRS (Command Query Responsability Segregation) y resolvió con éxito el problema del numeroso número de peticiones a nuestros sistemas de información. 

Pronto, este patrón se conectó al patrón Hexagonal que resolvía que diferentes tipos de clientes accedieran a un mismo núcleo de nuestra aplicación que, al mismo tiempo, se adaptaba también a diferentes sistemas de información.

Todos los patrones de los que he hablado anteriormente resuelven distintos problemas y necesidades, pero hay uno que puede servir de pegamento o unión entre ellos y que maneja la arquitectura de nuestra aplicación de una manera notable y eficiente. Se trata del patrón DDD (Domain Driven Development), que estudia una nueva arquitectura de capas basada en el lenguaje ubicuo que nos dicta a que todo lo que escribamos sea semántico y, por tanto, entendible. DDD nos obliga a reestructurar toda nuestra aplicación y desarrollo, dividiendo en nuevas capas con una estructura donde el dominio es lo más importante y, esto es, el diseño de nuestra aplicación.

Hoy en día los patrones de arquitectura evolucionan con nuestra sociedad, obligando a los arquitectos a redefinirlos para solucionar los problemas enfocados a nuestras aplicaciones. Las necesidades marcan las pautas y el futuro nos dirá qué nuevos patrones traerá consigo. Y es que, en desarrollo, hay una verdad empírica: siempre hay una mejor manera de hacer las cosas.

Espero que os haya resultado interesante el artículo, como siempre aquí os dejo algunos links de interés que pueden ayudar a completar el conocimiento expuesto.

https://medium.com/all-you-need-is-clean-code/patrones-de-dise%C3%B1o-b7a99b8525e
https://www.genbeta.com/desarrollo/patrones-de-diseno-que-son-y-por-que-debes-usarlos
https://platzi.com/blog/patrones-de-diseno/


¡Muchas gracias por vuestra atención y nos leemos de nuevo próximamente!