[Parte 2] 9 pasos para que la Arquitectura de Software que ‘siembres’ sea fuerte desde la raíz

Etapa 5: Patrones de diseño, regar la semilla

Casi todos los problemas en el crecimiento de plantas se da por el exceso de riego o la carencia de agua y con los softwares ocurre lo mismo. Los problemas de software ya se han categorizado y resuelto. A estos patrones los llamamos: patrones de diseño, en realidad.

Hay 3 categorías de patrones de diseño: creacionales , estructurales y de comportamiento:

• Creacional: Los patrones de creación son patrones que controlan cómo se crean los objetos: el patrón Singleton, el patrón Abstract Factory, el patrón de prototipo.

• Estructural: Los patrones estructurales son patrones que simplifican cómo definimos las relaciones entre los componentes.

Ejemplos de patrones de diseño estructural incluyen:

1. Patrón Adaptador.
2. Patrón Bridge.
3. Patrón Decorator.

• Conductual: Los patrones de comportamiento son patrones comunes para facilitar la comunicación elegante entre objetos.

Ejemplos de patrones de comportamiento son:

1. Patrón de método de la plantilla.
2. El patrón Mediador.
3. El patrón Observador

Etapa 6: Principios arquitectónicos, la base para un crecimiento eficiente

Ahora estamos en un nivel superior de pensamiento más allá del nivel de clase. Ahora entendemos que las decisiones que tomemos para organizar y construir relaciones entre componentes de alto y bajo nivel, tendrán un impacto significativo en la capacidad de mantenimiento, flexibilidad y capacidad de prueba de nuestro proyecto.

Conoce los principios rectores que te ayudarán a desarrollar la flexibilidad que tu código base necesita para poder reaccionar a las nuevas características y requisitos con el menor esfuerzo posible. Siguiendo la línea de nuestra comparativa, este punto significa dar soporte a nuestro árbol. ¿Alguna vez has visto cómo se le amarran palos o cuerdas a las plantas en crecimiento para que no se tuerzan a modo de principios arquitectónicos? ¡Voilá! En este punto, queremos que lo analices todo de esa forma.

Esto es lo que recomendaría aprender de inmediato:

• Principios de diseño de componentes, el principio de abstracción estable, el principio de dependencia estable y el principio de dependencia acíclica, sobre cómo organizar componentes, sus dependencias, cuándo acoplarlos y las implicaciones de crear ciclos de dependencia accidentalmente y necesitar de componentes inestables.
• Política frente a detalle, para comprender cómo separar las reglas de su aplicación de los detalles de implementación.
• Límites y cómo identificar los subdominios a los que pertenecen las características de su aplicación.

Etapa 7: Estilos arquitectónicos, la parcela

La arquitectura se trata de lo que importa. Se trata de identificar lo que un sistema necesita para que tenga éxito y luego acumular las probabilidades de éxito eligiendo la arquitectura que mejor se adapte a los requisitos, es elegir el mejor terreno para que el software fluya y se pueda aprovechar. Por ejemplo, un sistema que tiene mucha complejidad de lógica empresarial se beneficiaría del uso de una arquitectura en capas para encapsular esa complejidad.

Es importante señalar que las 3 categorías de estilos arquitectónicos son similares a las 3 categorías de patrones de diseño, porque los estilos arquitectónicos son patrones de diseño de alto nivel.

• Estructural

  Los proyectos con distintos niveles de componentes y una amplia funcionalidad se beneficiarán o sufrirán al adoptar una arquitectura estructural.

• Mensajería

Dependiendo de tu proyecto, la mensajería puede ser un componente realmente importante para el éxito del sistema. Para proyectos como este, las arquitecturas basadas en mensajes se basan en principios de programación funcional y patrones de diseño de comportamiento como el patrón del observador.

A continuación, se muestran algunos ejemplos de estilos arquitectónicos basados ​​en mensajes:

• Las arquitecturas basadas en eventos, reconocen todos los cambios significativos de estado como eventos. Por ejemplo, dentro de una aplicación de comercio, el estado de una oferta puede cambiar de «pendiente» a «aceptado» cuando ambas partes acuerdan el intercambio.
• Las arquitecturas de publicación-suscripción se construyen sobre el patrón de diseño del Observador, convirtiéndolo en el principal método de comunicación entre el propio sistema, los usuarios finales/clientes, otros sistemas y componentes.

• Distribuida

Una arquitectura distribuida significa que los componentes del sistema se implementan por separado y operan comunicándose a través de un protocolo de red. Los sistemas distribuidos pueden ser muy efectivos para escalar el rendimiento, escalar equipos y delegar (tareas o responsabilidades potencialmente costosas) a otros componentes.

Algunos ejemplos de estilos arquitectónicos distribuidos son:

• Arquitectura cliente-servidor . Una de las arquitecturas más habituales, donde dividimos el trabajo a realizar entre el cliente (presentación) y el servidor (lógica de negocio).
• Las arquitecturas peer-to-peer o P2P, distribuyen las tareas de la capa de aplicación entre participantes igualmente privilegiados, formando una red peer-to-peer.

Etapa 8: Patrones arquitectónicos

Los patrones arquitectónicos explican con mayor detalle táctico cómo implementar realmente uno de esos estilos arquitectónicos. En esta etapa debemos entender todos los elementos que intervienen, así como en la siembra de un árbol, se deben tener en cuenta el clima, tipo de tierra, abono, entre otros, en términos de esta etapa, con este paso se establece el conjunto de sub-sistemas predefinidos, especificando sus responsabilidades, reglas, directrices que determinan la organización, comunicación, interacción y relaciones entre ellos.

Aquí hay un par de ejemplos de patrones arquitectónicos y los estilos de los que heredan:

• El diseño basado en dominios (DDD – Domain Driven Desing, por sus siglas en inglés) es un enfoque para el desarrollo de software frente a dominios de problemas realmente complejos. Para que DDD sea más exitoso, necesitamos implementar una arquitectura en capas para separar las preocupaciones de un modelo de dominio de los detalles infraestructurales que hacen que la aplicación se ejecute realmente, como bases de datos, servidores web, cachés, etc.
• Model-View Controller (modelo vista controlador) es probablemente el patrón arquitectónico más conocido para desarrollar aplicaciones basadas en interfaces de usuario. Funciona dividiendo la aplicación en 3 componentes: modelo, vista y controlador. MVC es increíblemente útil cuando está comenzando, y lo ayuda a aprovechar otras arquitecturas, pero llega un punto en el que nos damos cuenta de que MVC no es suficiente para problemas con mucha lógica empresarial.
• El abastecimiento de eventos es un enfoque funcional en el que almacenamos solo las transacciones y nunca el estado. Si alguna vez necesitamos el estado, podemos aplicar todas las transacciones desde el inicio.

Etapa 9: Patrones empresariales

Cualquier patrón arquitectónico que elija introducirá una serie de construcciones y jerga técnica con los que familiarizarse y decidir si vale la pena el esfuerzo de usarlo o no. En este punto se trata de qué tipo de semilla va a plantar y adaptarse a cosechar los frutos correspondientes.

Tomando un ejemplo que muchos de nosotros conocemos, en MVC , la vista contiene todo el código de la capa de presentación, el controlador traduce los comandos y consultas de la vista en solicitudes que son manejadas por el modelo y devueltas por el controlador .

¿En qué parte del Modelo (M) manejamos estas cosas?:

• Lógica de validación
• Reglas invariantes
• Eventos de dominio
• Casos de uso
• Consultas complejas
• Lógica empresarial

Si simplemente usamos un ORM (mapeador relacional de objetos) como Sequelize o TypeORM como modelo, todas esas cosas importantes quedan a la interpretación de dónde debería ir, y se encuentra en una capa no especificada entre modelo y el controlador .

Para cada una de esas cosas que el MVC no aborda, existen otros patrones empresariales para resolverlas. Por ejemplo:

• Las entidades describen modelos que tienen una identidad.
• Los objetos de valor son modelos que no tienen identidad y se pueden utilizar para encapsular la lógica de validación.
• Los eventos de dominio son eventos que significan que ocurre algún evento comercial relevante, y se pueden suscribir desde otros componentes.

Dependiendo del estilo arquitectónico que haya elegido, habrá un montón de otros patrones empresariales para que aprenda a fin de implementar este patrón en su máximo potencial.

Conclusión

Una vez que su aplicación esté en funcionamiento, a medida que obtenga más y más usuarios, es posible que tenga problemas de rendimiento. Las llamadas a la API pueden llevar mucho tiempo, los servidores pueden fallar por estar sobrecargados con solicitudes, etc. Para resolver estos problemas, puede leer acerca de la integración de cosas como colas de mensajes o cachés para mejorar el rendimiento.

Diseñar un sistema a escala puede ser un desafío increíble. Requiere una comprensión profunda de las limitaciones de cada componente dentro de la arquitectura y un plan de acción sobre cómo mitigar el estrés en su arquitectura y continuar atendiendo solicitudes en situaciones de alto tráfico. Las grandes empresas deben poder realizar auditorías para identificar posibles problemas de seguridad, comprender cómo los usuarios utilizan sus aplicaciones y tener un registro de todo lo que ha sucedido.

Y ahora, después de nuestra parte 1 y 2, ¿qué opinas de la Arquitectura Tecnológica? En tiempos de post pandemia, ¿esto sería un recurso que apela más a un lujo o a una necesidad? Esperamos que esta nueva entrega te haya puesto a pensar en una posible estructuración arquitectónica tecnologíca si es que no la tienes, y si ya hace parte de tu organización, ¡Revisa si estás obteniendo los resultados que esperas! Recuerda que en Trycore somos expertos en la materia y estamos para acompañarte en cada parte del proceso.