Jaque.

Hace un par de días descubrí el muy prometedor Un Punto Azul Pálido. Empecé a leer hacia atrás, hasta darme con la entrada El objeto del negocio donde el autor despotrica contra los métodos de negocio "inútiles" al estilo public void almacenarCuenta(Cuenta c) { cuentaDao.almacenar(c); }

Donde se ve una capa de negocio inútil que hace de pasamanos entre el front-end y la capa de datos, sin aportar nada.

Alguna parte de la aplicación sobre la que trabajo está así. "Jaque", pensé, porque por un lado no podía dejar de estar de acuerdo con lo que había leído, pero por el otro mi orgullo, un poco herido, quería salir a defender la estructura que armamos (es un proyecto que comenzamos de cero absoluto) y que ha probado ser más que robusta, legible y escalable (en serio, lo ha probado).

Logré dejar el amor propio de lado (sentimiento dañino si los hay para un desarrollador, que debe estar siempre consciente de que **nunca** ha escrito código sin errores), pensé un rato y me dí cuenta de que en realidad el post critica algo que nosotros mismos ya nos hemos criticado y conversado, por lo que creo que es interesante contar un poco cómo es que sucedió eso y, sobre todo, advertir que si bien no está bien que esto suceda, podría ser peor.

El requerimiento (absolutamente paperless) era crear un framework de trabajo, y al tiempo desarrollar la nueva versión de la aplicación principal de la empresa reescribiéndola desde 0. Cambio de tecnología (de .Net 1.1 parecido a VB 6 a .Net 2.0), de lenguaje (de VB a C#) de paradigma (de estructurado + orientado a formularios y eventos a orientado a objetos) y de entorno (de aplicación de escritorio a aplicación web para correr en un servidor de la intranet).

Entonces, teníamos que "copiar funcionalidad" (producir la misma salida que antes en pantalla y contra la base de datos) con la aplicación existente como única referencia. Ésta contaba con poca documentación y tenía el código enmarañado por el mantenimiento y el rápido crecimiento. Por otro lado el equipo estaba muy fresco, recién habíamos entrado a la empresa y no teníamos la más mínima idea de un negocio que para colmo de males es bastante particular.

Encima se sucedieron algunos cambios de asignaciones y finalmente de personal (todo tranquilo, nada terrible). Finalmente quedamos dos "arquitectos". Yo en realidad tirando un poco más para el lado de la aplicación o el negocio. Así que el otro empezó desde más abajo en la arquitectura, yo desde la capa de datos hacia arriba.

Cuestión que después de un tiempo la capa de datos quedó muy bien armada utilizando un generador de código, con la que creamos una clase encargada de cada tabla más algunos artilugios.

Llegamos al punto. El negocio. Nuestra agenda se basaba en reproducir "pantallas" de la aplicación anterior. Pero no teníamos un inventario de las funcionalidades que involucraban esas pantallas. En todo caso, esta forma de ver la aplicación (como un conjunto de pantallas independientes) se basaba en una filosofía que no era la nuestra (patrón MVC, con una controladora por funcionalidad, que puede vincular una o muchas páginas a uno o varios objetos de negocio).

Resumen: teníamos la estructura armada para el MVC, teníamos la estructura para la capa de datos, teníamos la estructura general del front-end armada... y faltaba diseñar la capa de negocio... de un negocio que no sabíamos muy bien de qué la venía.

Y ahí metí la pata. Sí, metí la pata. Con el generador de código creé una clase de negocio inicial a partir de cada tabla de la aplicación. Pasamanos. Un montón de pasamanos.

Tres errores conceptuales, por lo menos:

• El principal: un negocio no se automatiza, se piensa, se diseña. Nadie nos salva de eso, hay que tener cuidado con las soluciones mágicas. El negocio es la parte de la aplicación en la que ninguna herramienta puede reemplazar a un ser humano, y en la que ninguna regla automática nos va a venir a salvar. Hay que relevar y entender el negocio antes de meter los dedos.
• Vincular conceptualmente el negocio a la estructura de la base de datos. Es casi el mismo error que vincularlo conceptualmente al front-end. El negocio es el negocio, por eso es una capa separada. Si lo vinculamos a la base de datos caemos en la estructura pasamanos, si lo vinculamos al front-end caemos en la siempre terrible, enmarañada y cambiante lógica del usuario.
• Reprodujimos una lógica que no era la nuestra (la del sistema viejo) sin conocerla a fondo. Nos "comimos" todos sus errores conceptuales al no diferenciar lo que estaba bien de lo que estaba mal. No vimos sus puntos fuertes. No utilizamos la experiencia. Copiamos.

Pero, dentro de todo, algunos aciertos:

• Algo había que hacer, y se respetó la máxima de los principios de diseño: "más vale disperso que denso". Con el tiempo muchos pasamanos se fueron llenando de código: de validaciones, de relaciones, de métodos y clases complejas. Se creó mucho espacio vacío e inútil, pero la mayor parte de ese espacio terminó siendo esencial para colocar código que sabíamos que iba a estar pero que en ese momento no sabíamos cuál era. De esto adolecen los ejemplos en el código mencionado arriba. Ok, el método simplemente toma los datos y los graba a ciegas. ¿Pero no tiene que validar nada antes? ¿No tiene que presentar mensajes al usuario en caso de problemas de negocio ("El movimiento no se puede insertar porque el cliente no tiene saldo suficiente")? ¿No tiene que verificar que el estado del sistema sea válido para la operación? ¿No tiene que revisar los permisos del usuario actual? ¿Dónde está esta funcionalidad? Si la operación impacta en varias tablas ¿no tiene que iniciar una transacción? Creo que debería estar ahí. Supongo que el problema de la aplicación que describe el post de Improbable es que ese código no está, y por eso el método está vacío. ¿Dónde lo habrán puesto?
• Con esta "salida" la capa de datos quedó oculta, inaccesible (internal de la librería de datos+negocio) y esto es importante. El front-end no debe acceder a datos directamente. El pasamanos actúa al menos como un encapsulador de la capa de datos donde podemos ubicar código de ser necesario. Si no hacemos nada es peor, ya que tendremos muchas páginas o elementos del front-end accediendo cada uno por su lado a los datos. Un cambio en la estructura de una tabla impactaría directamente en el front-end, y no habría un lugar donde frenar ese impacto.
• Fue corregible, fue mantenible. Fuimos haciendo refactorizaciones. Borramos algunas clases. Fuimos metiendo unas en otras que se convirtieron en internas y así se presentaron objetos y métodos más complejos. En esto fue fundamental el uso del patrón MVC que frenó los cambios, que no impactaron en el front-end (que se desarrollaba en paralelo), detalle sutil que los hizo posibles. Creo que si hubiésemos vinculado el negocio al front-end hubiese sido imposible "bajar" la complejidad adquirida.
• Representó en su momento lo poco que conocíamos del negocio: la estructura de la base de datos. Es importante que la estructura de un proyecto represente lo que los desarrolladores saben de él. Lo vuelve legible. A medida que aprendíamos más del negocio, lo íbamos modificando. Nunca tuvimos documentación funcional, y todavía (con varios módulos desarrollados) no nos perdemos. A veces no sabemos qué hay que hacer, pero por lo menos es fácil saber qué fue lo que hicimos.
• No repetimos el error: cuando hubo que incorporar un nuevo módulo, hicimos el relevamiento correspondiente a partir del sistema viejo y repensamos y rediseñamos el negocio de acuerdo a las virtudes y a los errores que vimos. Es decir, aprovechamos la experiencia del sistema anterior, cosa que antes no habíamos hecho.

En resumen, lo que rescato:

Hay que pensar el negocio, no queda otra.

Pero si estamos apurados, es preferible crear objetos de más (pasamanos) que enmarañar todo.

Está bien salir del paso, pero no debería quedar así. Hay que ir depurando lo que sobra a medida que se dan los cambios.

Para finalizar, creo haber salido del Jaque aunque con alguna pieza de menos, veremos cómo sigue.