fbpx

La arquitectura de software son aquellas reglas que nos proponemos llevar a cabo cuando diseñamos y construimos un software. No tiene nada que ver con infraestructura física.

¿Cuándo NO debemos de definir la arquitectura de un software?

Para empezar voy a explicar cuando no es necesario definirla, básicamente cuando llevamos a cabo proyectos de una tarde de un par de funcionalidades. Si haces un script que realiza pings a un servidor para detectar si el servidor se ha desactivado no es necesario que definas una arquitectura.

Como es el caso de este módulo de NPM que me notifica por telegram cuando alguno de mis servidores se desactiva: is-server-alive.

Nos tenemos que acostumbrar a refactorizar el código, cuando programamos hemos de empezar siempre de menos a más, está bien ser organizado y cumplir algunos principios pero no debemos de perder tiempo en tareas que no lo requieren. Evita procrastinar.

¿Cuándo SÍ debemos de definir la arquitectura de un software?

Cuando nos proponemos llevar a cabo un proyecto a medio-largo plazo el cual reune multiples funcionalidades como puede ser: gestionar usuarios, registros, movimientos bancarios, etc…

Los principales objetivos que preseguimos a la hora de definir una arquitectura son:

  • Facilitar la mantenibilidad del software: Que los otros programadores entiendan que carajo hemos hecho.
  • Facilitar la extensibilidad: Que el software puede crecer en funcionalidades.
  • Facilitar la modificación: Que sea fácilmente modificable y no tengamos que rebuscar en miles de lugares para cambiar una cosa.

Como puedes ver todo se resume en ganar velocidad de desarrollo, reducir costes de la empresa y eliminar los dolores de cabeza. Existen otros motivos pero considero que estos son los más genéricos.

Para lograrlos existen distintas formas de trabajar por ejemplo el modelo SOLID del cual hice un artículo introductorio para que puedas coger ideas.

Complejidad accidental vs complejidad esencial

Sumar las manzanas que tienen dos usuarios de la base de datos puede ser un problema que a simple vista presenta una complejidad esencial sencilla: realizar las consultas y realizar una funcion de suma. Sin embargo la complejidad accidental es otro tema, pongamos que nuestro software no permite realizar este cálculo de forma sencilla porque las manzanas se encuentran en tablas distintas de la base de datos, tardaremos mucho más de lo esperado en aportar una solución. A esto también se le conoce como deuda tecnológica o deuda técnica.

A medida que un proyecto avanza sin realizar refactorización y sin definir una arquitectura clara esta complejidad accidental crece de forma exponencial, es por eso que si queremos llevar a cabo un proyecto profesional debemos de definir un protocolo de desarrollo.

La arquitectura hexagonal

La arquitectura hexagonal está formada por capas, para entender bien como funciona debemos de centrárnos en las dependencias, si, todas esas clases y métodos que creamos que terminan dependiendo de otros. Tenemos que ser capaces de aislar estas dependencias e impedir que una capa tenga dependencias con otras y para eso se construye de una forma concreta.

arquitectura hexagonal

Capas de la arquitectura hexagonal:

Domain o core: Entidades y servicios de dominio: Contiene todas las reglas de negocio que dependen de nosotros y no de externos, es el core de la aplicación.

Casos de uso de nuestro sistema: registrar usuarios… Cuando queremos realizar una acción llamamos al servicio, y es el servicio el que se encarga de realizar esta acción, en caso de error generaría un rollback o informaría de ello, nos tenemos que dar cuenta de que el servicio se encuentra encapsulado sin depender del agente que lo invoca.

Framework o infraestructura: Las decisiones de infraestructura no deben de afectar al software, lo que nos encontraremos es un controlador del framework que utilicemos que se encargará de llamar al servicio de turno. Si nos damos cuenta este servicio no tiene dependencias por lo que podrá ser utilizado por nosotros en el futuro o ser llamado por cualquier agente externo con independencia del framework aportando escalabilidad al proyecto.

Espero que este artículo te haya sido útil. Si te ha servido puedes compartirlo con tus amigos y unirte a mi red de LinkedIn para que sigamos en contacto. Muchas gracias.