Primera semana, papel en blanco, pizarra limpia y toda la ilusión y motivación para afrontar un nuevo proyecto y su solución global. Recapitulemos, nuestra meta es ¿cómo acercarnos lo máximo posible al objetivo ideal?
Antes de continuar tengo que pararme para explicar la situación de partida. Actualmente existe una aplicación monolítica que, entre otras muchas características, ya ofrece la funcionalidad que buscamos. El problema es que no la podemos seguir manteniendo ni evolucionando, está muy acoplada, no tiene testing y cada cambio tiene un coste muy elevado, tanto en desarrollo y despliegue como en las complicaciones e incidencias que genera, ¿te suena el problema?.
También existen algunas soluciones ya desarrolladas posteriormente usando TDD, DDD, SOLID, en general, proyectos con código testado, reutilizable y organizado. Estos proyectos ofrecen parte de la funcionalidad de la aplicación monolítica.
Volviendo al proyecto que nos ocupa, a grandes rasgos nos planteamos resolver tres incógnitas: ¿qué queremos?, ¿qué tenemos? y ¿qué vamos realmente a implementar?
Para resolver estas cuestiones nos planteamos la siguiente metodología:
¿Qué queremos?
- Definición del producto como tal, viéndolo como miembro de una solución global
- Definición de invariantes
¿Qué tenemos?
- Enumeración y análisis de los productos actuales para determinar lo que estos ofrecen a la solución global
- Enumeración de características necesarias del producto que no están implementadas en ninguna de las aplicaciones desarrolladas hasta el momento
- Identificación de bounded context comunes a varias o todas las aplicaciones
- Análisis de cada aplicación/bounded context para determinar posible flujo de actuaciones que nos permitan afrontar el desarrollo de la solución atendiendo a valores de entrega continua de MVP
¿Qué vamos a desarrollar?
- Definición de estrategias
- Definición de MVP
- Plan de actuación vivo y revisable
¿Qué queremos?
La idea principal es desarrollar algo que pueda hacer lo mismo en esencia que la aplicación monolítica, eliminando la funcionalidad obsoleta y que nos permita evolucionarla. ¿Compatible? a esa pregunta aún no podemos responder, lo iremos viendo.
- Definición del producto como tal viéndolo como miembro de una solución global.
La primera pregunta puede resultar peregrina, pero no lo es en absoluto, porque define el objetivo ideal, y a esa pregunta debemos responder viendo el proyecto como parte de una solución de mayor ámbito. Aterrizo, lo que quiero decir es que por un lado debemos concretar qué funcionalidad debe ofrecer nuestro proyecto y, por el otro, decidir qué partes de esa funcionalidad no son exclusivas del mismo ya que buscamos que sean compartidas en la solución global. Lo muestro con un ejemplo gráfico.
La solución global
La solución global nos permite gestionar la presentación, presupuesto, pedido y postventa de un producto. Consta de un módulo común y obligatorio, otro común opcional y seis aplicaciones modulares organizadas por grupos (venta y postventa), que utilizan los módulos comunes y que pueden formar parte de la implantación final de forma independiente. Esto significa que podemos tener la aplicación Product Orders sin tener Product Presentation o Calendar, pero no podemos tenerla sin Users.
De aquí se desprenden varios conceptos que luego convertiremos en invariantes del proyecto: modularidad, conectividad, independencia y reutilización.
El proyecto
Nuestro proyecto llamado Product Proposal debe ofrecer funcionalidad para hacer propuestas/presupuestos de producto. Para la gestión de usuarios, logs y notificaciones debe utilizar lógica común (el cuadro rojo) y para el seguimiento debe utilizar también la lógica común (cuadro amarillo).
2. Definición de invariantes.
Ya estamos en disposición de definir los invariantes que condicionarán el desarrollo:
- Aprovechar al máximo posible las soluciones nuevas existentes siempre y cuando no retrase el avance o lastre el proyecto.
- No usar la interfaz gráfica de la aplicación monolítica existente.
- Se mantendrá compatibilidad con la aplicación monolítica siempre que eso no lastre el proyecto. En caso de romperla, se documentará el cambio.
Primera pregunta resuelta, te contaremos cómo respondimos a las dos restantes.