martes, 29 de diciembre de 2009

DDD - Parte 3: Refactorizando Hacia una Visión más Profunda #3

Cuando refactorizamos un modelo hacia una visión más profunda, hay tres recomendaciones que Eric Evans nos hace:
  • Debemos vivir en el dominio
  • Debemos seguir explorando los conceptos de maneras diferentes
  • Debemos mantener un diálogo ininterrumpido con los expertos del dominio
Con este post, planeo cerrar la tercera parte de Domain-Driven Design. No explicaré nuevos conceptos, sino que repasaré los que ya estuvimos viendo en los dos post anteriores.

Inicio

Los móviles para iniciar una refactorización hacia una visión más profunda pueden ser muchos. Probablemente uno de los más importantes sea que el diseño se haya vuelto demasiado complejo y torpe; claramente un problema de este tipo no se soluciona aplicando una transformación mecánica al código. Quizás puedan estar faltando algunos conceptos en el modelo, o ciertas asociaciones puedan ser erróneas. El código y el modelo pueden estar desconectados del lenguaje del experto del dominio, un nuevo requerimiento puede no encajar de ninguna manera en el modelo ya existente, o pudimos haber aprendido más sobre el negocio y haber vislumbrado cómo exponer conceptos fundamentales.

Equipos de Exploración

La búsqueda de un nuevo modelo puede requerir más tiempo y la participación de más gente de lo esperado. Un grupo de cuatro o cinco personas puede reunirse en una sala de conferencia o en un café y hacer una tormenta de ideas (brainstorming) durante una hora u hora y media. Durante el brainstorming se pueden bocetar diagramas UML, diagramas ad-hoc, para buscar un modelo más flexible, que se ajuste mejor a la realidad y a las necesidades del sistema. Cuando el equipo obtenga algo con lo cual evolucionar, regresará al código y codificará las modificaciones. Algunos cambios puede convenir postergarlos para reflexionarlos con mayor detenimiento, otros se pueden implementar inmediatamente. Unos días después, el grupo podrá reunirse de vuelta para repetir el brainstorming, debatir si los cambios fueron apropiados y qué otras cosas se pueden mejorar.

Para que este proceso sea productivo se requiere:
  • Autodeterminación: los equipos pueden armarse sobre la marcha para explorar un problema de diseño particular y disolverse a los pocos días
  • Mantener acotado el Alcance: los aspectos a tratar en las reuniones de los equipos de exploración deben ser acotadas; si el equipo se atasca durante el brainstorming significa que se está intentando abarcar demasiado contenido de una sola vez
  • Ejercitar el Lenguaje Ubicuo: estas reuniones son una oportunidad perfecta para ejercitar el lenguaje ubicuo; el resultado puede conducir a un refinamiento del lenguaje que será reflejado en el modelo y en el código

Estado del Arte

No siempre es necesario reinventar la rueda. Durante el brainstorming podemos obtener ideas de otras fuentes del dominio, como libros, papers, blogs. Alimentarnos del conocimiento ya masticado, ya organizado, probablemente nos guíe hacia un modelo que resulte más familiar al experto de dominio. También los patrones de análisis pueden sernos útil para brindar conceptos sutiles, difíciles de crear, y evitar así muchos errores comunes.

Un Diseño para Desarrolladores

Un software no es sólo para usuarios. También es para desarrolladores. Los programadores deben integrar código con distintas partes del sistema, entenderlo y manipularlo para construir sobre lo ya construido. Un Diseño Flexible comunica sus intenciones, logrando que resulte más sencillo anticipar los efectos de la ejecución del código y, por lo tanto, predecir las consecuencias de los cambios. Un Diseño Flexible limita la sobrecarga mental, reduciendo dependencias y efectos secundarios.

Calendario

Si esperamos a tener una completa justificación para introducir un cambio, significa que hemos esperado demasiado. La Refactorización Continua es considerada como una buena práctica; sin embargo, muchos equipos de trabajo siguen siendo demasiado cautelosos a la hora de refactorizar. Ven el riesgo de cambiar el código y el costo de desarrollo a invertir, pero no ven el riesgo de mantener un diseño torpe, pesado, incómodo y el costo de trabajar sobre un diseño difícil de manejar.

Es preciso refactorizar cuando:
  • El diseño no expresa el entendimiento actual del equipo sobre el dominio
  • Conceptos importantes del dominio están implícitos en el diseño (y descubrimos una forma de hacerlos explícitos)
  • Encontramos una oportunidad de hacer más flexible una porción importante del diseño
Sin embargo, todo tiene un límite:
  • No debemos refactorizar el día anterior al lanzamiento de la release
  • No debemos introducir modificaciones que sólo demuestran virtuosismo técnico y no aportan valor al modelo
  • No debemos introducir mejoras cuando no podemos convencer al experto del dominio de usarlas
  • No debemos quedarnos con lo que tenemos, si sabemos que podemos tener algo mejor

Las Crisis son Oportunidades

Un período de refinamientos continuos puede traernos de pronto una visión que sacuda todo lo que tenemos hasta ahora. Los Progresos no ocurren todos los días. Los Progresos son el resultado de refactorizaciones continuas en las que modelos más profundos y diseños más flexibles fueron emergiendo. Con frecuencia, estos momentos se ven como crisis y no como oportunidades. De repente el modelo que usábamos resulta inadecuado y todo el equipo entra en pánico.


Esto no es el fin, sino el comienzo de un nuevo nivel de entendimiento. Desde esta nueva evolución, desde este más elevado punto de vista, el modelo que tenemos luce viejo, pobre. ¡Podemos hacer uno mucho mejor!

Por eso, la refactorización hacia una visión más profunda es un proceso continuo.