Continuando con las entrevistas para el Agile Alliance, esta vez tuve el grato placer de entrevistar a Miguel Viera que es un desarrollador, que junto con sus colegas de Codesai imparten consultoría y mentoría técnica en España.
Miguel es un apasionado por el lado técnico de la Agilidad y su interés estos días incluye Domain Driven Design, tema del cual decidió conversar en la entrevista.
Miguel comenzó por dar una definición de Domain Driven Design (DDD), para él DDD es un conjunto de prácticas y principios que ayudan a crear software a partir de una mejor interpretación de los términos de negocios, y esta mejor interpretación del domino ayuda a mejorar los procesos que tienen que ver con la confección del código.
Continuando Miguel mencionó que la principal razón por la cual DDD existe es la creación de un leguaje ubicuo que pueda ser entendido por el negocio y los desarrolladores. Este lenguaje ubicuo es una manera de destilar todo el metalenguaje y que la gente coloquialmente utiliza para comunicarse.
Según Miguel la idea es que este lenguaje ubicuo no sea documentado con texto escrito, sino más bien sea incorporado dentro del código mismo. El resultado será que dentro del código los nombres de variables, procedimiento, etc. acabarán reflejando mejor el entendimiento del dominio del negocio y los problemas que el código trata de resolver.
Miguel también observó que muchas veces existen palabras que son usadas correctamente desde una perspectiva semántica, pero que no reflejan el sentido del negocio. Este fenómeno se conoce como “pérdida en la traducción” que básicamente consiste en usar términos semánticamente correctos pero que no hacen mucho sentido en el domino del negocio. Esa “perdida en la traducción” al reflejarse en el código hará que éste acabe siendo mas obscuro para quien lo lea y trate de entenderlo, limitando a futuro su adaptabilidad y extensibilidad.
Miguel comentó que para que este lenguaje ubicuo sea creado mas efectivamente, sería ideal que los desarrolladores interactúen directamente con alguien del negocio, pero esto muchas veces no es factible debido a limitaciones físicas o de la misma empresa. Si estas limitaciones están presentes, la presencia de un Product Owner que entienda a cabalidad el negocio puede ser un substituto válido, dijo Miguel.
Según Miguel código que no refleje adecuadamente el dominio del problema, acabará creando una complicación extra para quien trate de entenderlo, pues además de entender el código mismo habrá que descifrar cómo se trabajó en el dominio del problema. Es decir, tratar de traducir la traducción lo cual acabará causando complicaciones adicionales.
Miguel señaló que TDD es una práctica que encaja perfectamente con DDD porque recoge el lenguaje ubicuo, que luego se acaba traduciendo en pruebas y código que tendrán más sentido dentro del contexto del negocio. Todo el lenguaje de dominio se podría, en la mayoría de los casos, ser programado en cualquier lenguaje de programación a menos que haya factores técnicos que sesguen la elección de un lenguaje o paradigma de programación en particular, comentó Miguel.
Miguel supone que DDD no ha sido más utilizado entre la comunidad de desarrollares por un cambio de interpretation de lo que es la excelencia técnica, ya que que ahora el foco no solo debe estar en las herramientas y las prácticas técnicas sino en el entendimiento del dominio. Así la excelencia técnica tiene que ver con entender el negocio, plantear soluciones de negocio y luego recién implementarlas. Plantear y discutir soluciones con gente del negocio es lo que al final hace el desarrollo más iterativo e incremental, dijo Miguel.
Para cerrar la entrevista Miguel comentó que un punto de partida para quienes deseen adentrarse en DDD es leer el libro de Eric Evans, con especial énfasis en tratar de entender las limitaciones técnicas que traerá en la parte táctica el no entender cabalmente el dominio del problema. Una reflexion final que nos dejó Miguel es que la excelencia técnica para un desarrollador consiste en entender holísticamente el producto que esta construyendo.
Sobre el Autor: Juan Banda
Juan se especializa en entrenar, mentorear y hacer coaching de equipos Agiles para que en corto tiempo puedan alcanzar resultados asombrosos. Juan es también un agente de cambio que ayuda a que empresas completas vuelquen sus prácticas hacia formas más humanas de trabajo. Juan es un Certified Scrum Trainer (CST) y LeSS Friendly Scrum Trainer. Su formación universitaria incluye un grado de Magister en Administración de Sistemas de Información conferido por The University of Illinois at Chicago.
