LetsBonus comenzó a operar en Italia y España a finales del 2009. Como toda startup al inicio, había una buena idea pero pocos recursos, así que empezaron con una plataforma de venta sencilla y muy ad-hoc para aquel momento.

El 2º trimestre del 2011, LetsBonus había crecido muchísimo y la plataforma que servía unos meses atrás se quedaba obsoleta. Cuando llegó a nosotros el proyecto, ya se debía plantear una plataforma con todas las funcionalidades de aquel momento más una serie de updates y paquetes evolutivos así como un sistema de internacionalización completo.

El desarrollo de todo el proyecto hasta entregarlo al equipo de IT de LetsBonus, fue de 6 meses. En esos 6 meses, fuimos los responsables de publicar las versiones de Italia, España, Mexico, Argentina...

Tecnológicamente fue un reto bastante alto, ya que suponía crear un ecommerce con diferentes paises, idiomas, monedas, tpv y con una lógica de generación y redención de códigos de los cupones muy avanzada para cumplir con las necesidades de LetsBonus.

El proceso no fue fácil, fue un desarrollo más largo de lo deseado y LetsBonus, como startup, necesitaba avanzar más rápido de lo deseado por las necesidades del mercado y su competencia.

En la recta final, y a modo de traspaso, parte del equipo de IT estaba unas semanas en nuestras oficinas desarrollando y familiarizándose con el código que habíamos creado.

Planteamiento tecnológico

El sistema a desarrollar debía ser en PHP y MySQL, por lo que nuestra primera decisión fue la de utilizar Zend Framework como base para el proyecto, creando una capa por encima que permitía la organización del código en una estructura más cómoda para las distintas necesidades del proyecto.
Al tratarse de un sistema evolutivo era necesario dividir el código en 3 capas fundamentales: Presentación, Lógica de negocio y Acceso a BBDD para poder permitir sus distintas implementaciones en los casos deseados:

•   - Capa de presentación: encargada de gestionar las peticiones al sistema y de mostrar los templates correspondientes a cada llamada.

•   - Lógica de negocio: manipula los datos y realiza las operaciones necesarias para devolver la respuesta correcta a la solicitud realizada.

•   - Acceso a BBDD: se encarga de gestionar las conexiones y realizar las peticiones a la Base de Datos.

Una vez conocida la tecnología y su organización se debía preparar todo el modelo de datos encargado de gestionar las múltiples necesidades del sistema, la más destacada de ellas es la necesidad de poder gestionar de forma totalmente independiente los datos introducidos en función del país, ciudad o incluso idioma seleccionado. Por ello se planteó una base de datos con un núcleo central que contiene la información básica de los países, idiomas y ciudades y del cual todas las demás entidades generadas hacen referencia. Este sistema también está preparado para poder alojar los datos necesarios en múltiples servidores para poder cumplir las LOPD de cada país.

La configuración de la pasarela de pagos también supuso un gran reto para el desarrollo puesto que cada país dado de alta podía utilizar distintas plataformas o utilizar algunas de ya existentes, por lo que se utilizó ’Template Method’ como patrón de diseño para definir la base que todas las implementaciones que se realizaran tuviesen la misma estructura. Esto permitía al sistema una abstracción de la pasarela utilizada y simplificó, a la vez que agilizó el desarrollo e implementación de las pasarelas. Además este sistema permitía el aislamiento total de la pasarela de pago para ir bajo una conexión segura y permitiendo al usuario tener la certeza de que sus datos no podrían ser interceptados.

Inicialmente la capa de presentación estaba formada por unos templates comunes para todos los países/idiomas y gestionada con el uso de ficheros externos que contenían las traducciones necesarias de los textos. No obstante, el rápido crecimiento del proyecto y las distintas necesidades de cada país nos permitió idear un sistema de organización distinto en el que existían unos templates por defecto que podían ser sobreescritos en cada caso necesario por otro template distinto. De esta manera, si algunos países compartían una misma zona en común y otro país era radicalmente distinto, la organización y implementación realizada permitía, de forma ágil y sencilla generar un template concreto sin necesidad de modificar nada de la aplicación.

La separación por capas también nos permitió la creación de distintos tipos de interfaz, creando una división de la capa de presentación en varias partes:

•  - Área pública: es el contenido que ven todos los usuarios, tanto registrados como visitantes.

•  - Áreas privadas 1/2: incluyen una extensión de seguridad para que el contenido sólo sea mostrado a las personas indicadas por los administradores y permiten, de forma ágil y intuitiva la gestión de algunos contenidos de la base de datos.

•  - Webservices: para poder devolver los datos en el formato deseado se generó esta capa pensada para la comunicación entre múltiples sistemas informáticos, permitiendo al desarrollador escoger, en cada caso, el formato de retorno a utilizar.

Los planteamientos seguidos durante el análisis y posterior implementación del proyecto permitieron a LetsBonus poder crecer en múltiples direcciones a la vez incorporando nuevas funcionalidades de forma cómoda y sin alterar las partes comunes de la web, permitiendo incluir múltiples desarrolladores en un mismo proyecto y la futura implementación de metodologías como TDD o Integración continuada, cuyas necesidades principales son la estructuración de la aplicación de una forma parecida a la utilizada durante el proyecto.