DDD: Anti Corruption Layers

por Publicado el

Uno de los patrones que me llamo la atención de DDD es el llamado: Anti corruption layer. Esta estrategia de diseño busca alejar diseños estructurales distintos, conceptos ajenos o cualquier otra idea o comportamiento ajeno del dominio de conocimiento del sistema. No es un concepto nuevo, Robert C. Martin y otros autores abordan esta problemática bajo otros nombres.

La dependencia de terceros es peligrosa.

En el diseño y construcción de software te vas a enfrentar con la convivencia con sistemas malos, viejos legados, mal diseñados o poco funcionales, es un hecho. Dejar que tu solución se contamine  con ideas ajenas, o que  esta siga la lógica, un flujo de un tercero, el cual tiene cero compromiso con tu sistema es malo, también puede a llegar a ser inevitable. Las capas de deflexión o anticorrupción pueden ayudar a mitigar o absorber los cambios en el sistema. El aislamiento de componentes mediante capas es un tema polémico, algunos programadores lo ven como una útil herramienta, otros como un esfuerzo innecesario o burocracia. Las capas son una valiosa herramienta si, y solo si se usan bien, si son mal ocupadas solo ocasionan problemas y restan adaptabilidad al sistema.

¿Cuándo y como se debe aplicar una capa?, ¿cuántas capas son muchas?, o ¿cuántas capas es lo mínimo?. Todas estas son preguntas que se responden con la experiencia, no hay una receta rápida que te permita tener el diseño perfecto.  Lo que es un hecho es que cualquier dependencia o implementación de terceros que fuerce al sistema a adaptarse  (excepto la UI, es un caso especial) sin ser bidireccional es un riesgo. Por bidireccional me refiero a que ambas partes estén dispuestas a ser modificadas, por ejemplo: dos equipos de desarrollo, con dos sistemas distintos, que trabajan paralelamente en una adecuación,  se reúnen para elegir el mejor método de comunicación entre los servicios. En un escenario así, se puede conceder que el sistema se adapte a un cambio de un tercero.

La corrupción puede venir de todos lados, incluso desde adentro.

Comúnmente se asocian las capas de deflexión con la convivencia con sistemas malos, si bien son una útil herramienta en este caso, no es el único caso a tener en cuenta al momento de construir el aislamiento de las reglas de negocio. La base de datos, por ejemplo, puede ser un elemento que corrompa nuestros servicios y entidades. La persistencia, o el detalle de como se ejecuta, no debería ser conocido por las entidades. Estas no deberían ser forzadas a adaptarse para que la base de datos pueda operar, debe ser al revés. DDD tiene contemplado este escenario con el patrón Repository lo sé, implementar repositorios también cuenta como capa anticorrupción.

Existen más casos en los que es necesario aislar las reglas de negocio del exterior y por exterior también incluyo a elementos internos de la empresa. Lo importante es tener en cuenta que el diseño de las entidades y los comportamientos van primero, después, todo lo demás.

La corrupción es física y es conceptual.

Por corrupción física hay que entender aquella que busca modificar la estructura física de tu solución, a nivel componente o a nivel arquitectónico. La corrupción conceptual es la que busca introducir conceptos o comportamientos ajenos y hacerlos pasar por elementos del dominio del problema. Por ejemplo, agregar relaciones de agregados innecesarias, propiedades de entidades que no se usan dentro del dominio del problema, o tener términos ajenos del problema mencionados en el sistema.

Por ejemplo: nuestro sistema requiere enviar un folio de factura al cliente mediante un servicio de entregas por correo electrónico. En lugar de enviar solo el folio de factura del servicio de facturación, se decide enviar todos los campos provenientes de ese servicio, aunque no está en el requerimiento. Se está agregando complejidad innecesaria, en el correo por ejemplo: se puede ver el ID interno de la base de contabilidad, también el ID del sistema de inventarios. Por ahorrarse la construcción de una capa anticorrupción se están agregando elementos ajenos al dominio de nuestro sistema. Puede que más adelante alguien incluya a estos conceptos como propios del sistema con la excusa de que ya están mencionados en la lógica de negocios.

Conclusiones.

DDD busca la pureza de ideas en el problema que tratamos de solucionar con la ayuda del dueño del proceso o conocedor del dominio del problema, nuestro deber es tener los mecanismos necesarios para conservar la pureza del sistema, por decirlo así. Si bien DDD hace una mención explicita, este es un tema clave en la construcción de sistemas, no es exclusivo de DDD.

Autor imagen: nrcgov

Referencias:

Gustavo Sánchez
Últimas entradas de Gustavo Sánchez (ver todo)

Publicado por Gustavo Sánchez

Soy especialista en escribir software de calidad. Mediante el uso de marcos de trabajo, técnicas y automatización de procesos he podido reducir los costes operativos de los sistemas de la empresa. Sistemas confiables y adaptables producen clientes felices.