1.- Arquitectura de un Producto

¿Qué es un producto software?

Un producto, en el ámbito del software, es mucho más que un programa que funciona en nuestro ordenador el día que hemos terminado de codificarlo.

Los clientes quieren usar software que siga funcionando en el futuro, en hardware o sistemas operativos más modernos, que se corrijan los bugs o problemas de seguridad que se descubran, que siga operando con el resto del mundo, aunque este haya cambiado, y habitualmente que evolucione con nuevas funcionalidades.

Para un proveedor de software será más eficiente realizar todas esas tareas en su propia infraestructura, ya que es un entorno que controla, y vender acceso como suscripciones para cubrir sus costes operativos, lo que se conoce como SaaS (Software as a Service).

Entonces, ¿qué esperamos de un buen producto software?: un nivel constante de servicio y calidad lo cual requiere niveles constantes de inversión y cariño por parte de las organizaciones que los ofrecen.

A veces se suele usar el termino Aplicación para referirse a un software creado a medida según los requisitos de un cliente (que será el dueño de la aplicación). El termino Producto se utiliza cuando el software se desarrolla teniendo en cuenta necesidades generales del mercado y su dueño es la organización que lo crea.

Estructura de un Producto

Una simple pieza de código no es un producto.

El producto menos complejo posible requiere una combinación de varios elementos: servicios básicos, utilidades genéricas (reusables y publicadas por terceros) y funcionalidades específicas de nuestra aplicación (desarrolladas por nosotros).

Además, a medida que los sistemas software crecen se vuelven más complejos de desarrollar y mantener. Modularizar el sistema, es decir, separarlo en piezas o componentes hace más fácil entenderlo y evolucionarlo.

Un componente es un artefacto software que encapsula funcionalidad y es versionable, reutilizable y se puede desplegar de forma independiente. Desplegar significa transformar código en un artefacto directamente consumible y alojarlo en un repositorio (para ser reutilizado como dependencia por otro componente o aplicación) o directamente en un entorno y runtime donde se ejecuta y exponen sus interfaces.

Esta estructura de componentes y sus relaciones forman parte de la arquitectura física de la aplicación y será nuestra primera decisión.

¿Cómo organizamos nuestro código modular?

Nomenclatura

Vamos a crear nuestro primer componente agrupando su código en una carpeta.

Le damos un nombre descriptivo preferiblemente usando sustantivos. Vamos a usar el siguiente patrón: nombre_organizacion-nombre_producto-funcionalidad.

Todos los artefactos contenidos en esta carpeta comparten el mismo ciclo de vida, por eso la vamos a asociar con un repositorio git local que nos permita llevar registro de los cambios y control de versiones.

Como regla general un commit sobre una rama representa una unidad de trabajo y debe incluir todas las modificaciones en los ficheros relacionados con esa tarea. Merece la pena hacer un esfuerzo en que los mensajes de los commits sean descriptivos.

Estos dos simples hábitos van a hacer más fácil rastrear bugs y entender los cambios incluso meses después de realizados.