Patrones - Plenamente justificables al negocio

Patrones de diseño: plenamente justificables al negocio

Sin duda alguna un diseño de software que no toma como base los años de experiencias previas condensadas en los catálogos de patrones de diseño, tiene menos probabilidad de ser exitoso respecto a uno que si lo haga.

Los patrones de diseño son bastante simples una vez se entienden los beneficios que se derivan de su uso. Personalmente pienso que la literatura ha hecho un gran trabajo documentandolos, mostrando la forma como se diseñan o la forma como se implementan, pero muy pocos se han esforzado por mostrar su valor evidente ante el negocio.

Independiente de su origen (GOF, JEE, GRASP, etc), pienso que todos ellos caben perfectamente dentro de dos categorías:

• Aquellos cuya aplicación es percibida directamente por el usuario final.
• Aquellos cuya aplicación es percibida por el negocio en el tiempo (Corto, Mediano o Largo plazo).

Estas dos categorías son las mismas que planteé hace algún tiempo para los atributos de calidad. ¿Por que?, pues porque de no ser así, ¿como justificar su aplicación?. Lo mas importante no es el patrón en si mismo, lo realmente importante es la razón por la cual este debe aplicarse y su justificación se deriva principalmente de todos los drivers arquitectónicos (Necesidades funcionales, Atributos de calidad, Restricciones técnicas y restricciones de negocio). Si no se puede justificar entonces no está bien diseñado.

Ejemplo práctico.

A partir de las reuniones de entendimiento de la necesidad con el cliente queda claro que se requiere una página web que permita realizar pagos a través de tarjeta débito o crédito. Aunque esto está definido, todavía no se ha seleccionado el proveedor a través del cual se realizarán las transacciones. Se tienen tres opcionados y el desarollo debe iniciar inmediatamente.

Una patrón Strategy en combinación con un patrón Adapter serían una buena combinación para solucionar este reto de diseño ¿Por que?.

El negocio requiere iniciar el desarollo inmediatamente pero se tiene un riesgo importante. El proveedor de transacciones de pago no se ha seleccionado. Siguiendo el principio de diseño Open/Close necesitamos entonces diseñar un mecanismo que permita realizar todo el desarollo de la página web de modo que en el momento en el que se decida un proveedor, se pueda realizar la integración sin modificar el código fuente ya escrito. El patrón Adapter tendrá sentido desde el punto de vista de separación de responsabilidades facilitando la lectura del código fuente escrito. Todo esto se traduce finalmente en un incremento del atributo de calidad "flexibilidad", lo que a su vez entregará los siguientes beneficios para el negocio:

• Se podrá iniciar el desarollo inmediatamente tal y como lo desean (Restricción de negocio)
• La integración con el proveedor de transacciones de pago no modificará el código construido hasta ese momento, lo cual reducirá el riesgo de daños a la implementación existente, que a su vez se traducirá en menor tiempo invertido por el área de testing en realización de pruebas de regresión.
• La separación de responsabilidades reducirá el tiempo de mantenimiento, al tenerse componentes altamente cohesivos.

Todo está estrechamente relacionado. En el ejemplo se ve como un atributo de calidad que podríamos pensar le interesa solo al equipo de desarollo, finalmente si es muy relevante para el negocio expresado en sus términos (Alcance , Tiempo, Costo o Calidad).