¿Se puede implementar DDD sin DDD?
En software engineering el diseño guiado por domino, más conocido como DDD (Domain Driven Design), tiene dos vertientes, la vertiente estratégica y la vertiente táctica.
A menudo, como desarrolladores nos solemos centrar en los aspectos tácticos del DDD, es decir, su implementación en conjunto con algún tipo de arquitectura en capas (layered architecture), de hecho mi primera publicación acerca de este tema ha sido un articulo que trataba de como implementar DDD y Arquitectura Hexagonal en PHP con Laravel.
Implementar DDD con el apoyo de alguna arquitectura en capas sin duda nos ayuda a crear mejores aplicaciones, más robustas, escalables y testeables, hace que nuestro código sea más limpio y legible y favorece la reutilización del mismo.
Además, cabe recordar que los beneficios de la implementación del diseño guiado por dominio se extienden también a la estructuración, gestión y crecimiento de los equipos de desarrollo que lo utilizan.
Esto quiere decir que no solo mejora los productos de una empresa sino también su capital humano que representa uno de los activos más valiosos sino el más valioso si se considera la inversión en contratación, formación y el conocimiento de los productos desarrollados y del negocio que un profesional adquiere a lo largo de su permanencia.
¿Pero que hay de la parte estratégica?
¿Podemos realmente hablar de DDD si solo aplicamos la parte táctica, si solo nos centramos en la implementación?
Cada empresa, tiene unos objetivos de negocio y el diseño guiado por dominio nace para ayudar a las empresas a conseguir y maximizar estos objetivos optimizando los recursos disponibles.
Utilizamos DDD para construir modelos que reflejen de la manera más fiel posible los procesos de negocio de la vida real y construir herramientas que nos permitan solucionar los problemas de un dominio en concreto.
Y entonces ahí tenemos la respuesta.
No podemos decir que estamos implementando DDD sin antes haber estudiado y modelado dichos procesos.
Eso sería como participar en un maratón de atletismo sin tener un plan de acción.
Para competir, antes de empezar a correr hace falta planificar la carrera. Tienes que saber en que dirección correr, como dosificar los esfuerzos a lo largo del camino, y da igual que tengas el mejor equipamiento posible, si eliges el camino equivocado o el más engorroso, si lo das todo al principio porque no has tomado en cuenta todo el recorrido hay dos posibilidades:
La primera es la de no llegar a la meta, la segunda es la de perderte por el camino y tener que volver sobre tus pasos una y otra vez antes de alcanzar el objetivo, y aunque lo alcances te habrá costado mucha energía lograrlo (léase tiempo y dinero).
Con el diseño de software pasa lo mismo.
En DDD la parte que se encarga de definir el plan es la parte de diseño estratégico (strategic design) y este es precisamente el argumento que trataré en este artículo.
Aunque existan unos conceptos que es imprescindible conocer y de los cuales hablaré, el objetivo del artículo no es ofrecer una disertación profunda acerca de todos esos conceptos, sino hacerlo de la manera más simple posible proporcionando unas bases y unas metodologías para poder dar el primer paso hacia la introducción del diseño estratégico en nuestros procesos de desarrollo con el objetivo de definir, consolidar, formalizar y compartir el conocimiento acerca del negocio y conseguir información valiosa para que pueda ser utilizada posteriormente por los equipos en la fase de implementación.
Vamos allá…
¿Quien está involucrado en la parte estratégica del DDD?
Como he dicho anteriormente, utilizamos DDD para definir modelos que reflejen fielmente los procesos de negocio de la vida real e implementar herramientas que los soporten.
Aquí las dos palabras clave son negocio e implementar.
Se puede derivar que los stakeholders involucrados en esta tarea son gente de negocio, también llamados expertos del dominio, y los IT que se encargarán de implementar dichas herramientas.
Las partes se reúnen y armados de rotuladores y una pizarra (o simplemente de papel y bolígrafo) se ponen manos a la obra.
El diseño estratégico contempla dos espacios, el espacio del problema y el espacio de la solución.
Problema
En el espacio del problema vamos a identificar el dominio, sus subdominios y las relaciones entre ellos.
Solemos descomponer el dominio en subdominios porque el dominio puede ser un concepto muy amplio y abstracto, y encontrar una solución para este tipo de problemas es bastante difícil y entonces lo que hacemos es dividirlo en problemas más pequeños y solucionarlos.
El conjunto de soluciones de los problemas más pequeños nos proporcionará finalmente la solución al problema más grande (el divide et impera de toda la vida tan conocido en informática).
Identificar el dominio y los subdominios
El dominio vendría a ser aquello a que la empresa se dedica, o también, el principal objetivo de negocio que se propone alcanzar. Ejemplos de dominios podrían ser vender viajes online, facilitar servicios de email marketing, proponer productos de gestión financiera etc.
Una vez identificado el dominio (supongamos el de vender viajes online) nos toca preguntarnos:
¿Para vender viajes online que necesitamos?
A partir de las respuestas que van surgiendo podemos identificar las áreas de actuación dentro del dominio. Estas áreas de actuación son los subdominios.
En el caso de los viajes online posibles subdominios podrían ser conceptos relacionados con, creación del stock de productos y gestión de los proveedores, creación de los contenidos para la web, definición de una estrategia de precios, organización del servicio de atención al cliente, obtención de analíticas de venta etc.
Categorizar los subdominios
Tras haber identificado nuestro dominio y sus subdominios dividimos los subdominios en tres categorías.
- Dominio principal (Core domain)
- Subdominios de soporte (Supporting subdomains)
- Subdominios genéricos (Generic subdomains)
¿Porque aplicamos esta categorización?
Porque sin duda hay áreas de actuación que son más importantes que otras para el éxito del negocio y merecen más atención, recursos y prioridad (aquí es donde se empieza a ver el beneficio del DDD que comentaba al principio respecto a la estructuración de los equipos de desarrollo).
Dominio principal
Podría resumirse como el conjunto de subdominios sin los cuales no hay negocio, no hay empresa, son imprescindibles.
Subdominios de soporte
Son subdominios necesarios pero que no pertenecen al dominio principal y no merecen igual atención o recursos.
Subdominios genéricos
Por norma general se trata de dominios que no pertenecen al dominio principal y que pueden ser externalizados y ser integrados de alguna manera con nuestro sistema.
Siguiendo con el ejemplo de vender viajes online…
¿Podemos vender viajes online sin el producto?
¿Podemos tener una web de viajes online sin contenidos para los productos que queremos vender?
¿Puede el negocio prosperar sin una adecuada estrategia de precios?
Si la respuesta a estas preguntas es no (como es probable que sea) entonces estos tres subdominios son nuestro core domain.
¿Podemos vender viajes online sin un sistema de analíticas de ventas?
Muy probablemente si.
¿Sería mejor tenerlo para perfilar la oferta?
Sin duda, pero no es imprescindible para vender viajes online, por lo menos no en una primera etapa.
Y entonces este es un subdominio de soporte.
¿El servicio de atención al cliente es un aspecto critico de nuestro negocio y merecería ser parte del core domain?
No
¿Es posible externalizarlo, contratarlo en outsourcing?
Si
Se trata de un subdominio genérico.
Definir las relaciones entre los subdominios
El paso siguiente es identificar las relaciones entre las diferentes áreas de actuación, estas relaciones representan la manera en la que los subdominios interactúan entre ellos.
Supongamos que estamos analizando las posibles relaciones que el subdominio Contenidos puede tener con las demás áreas y entonces empezaremos preguntándonos…
¿Que necesitamos para crear los contenidos de un producto en concreto?
Seguramente necesitaremos información acerca del producto y del precio que le vamos a aplicar.
Acabamos de identificar dos relaciones.
¿Y para definir la estrategia de precios?
Necesitaremos del precio que nos proporciona el proveedor.
Ahí va otra relación.
Y así sucesivamente, seguimos investigando planteándonos preguntas hasta tener una red de relaciones que nos permita tener una idea lo suficientemente clara de como las diferentes partes se integran entre ellas.
Hasta aquí con la parte del problema, ahora toca ver de que manera vamos a definir una solución para el problema que acabamos de analizar.
Solución
Definir el contexto y el lenguaje
Lo primero es identificar el contexto o los contextos en los cuales los procesos de negocio se desarrollan y el lenguaje utilizado en dichos contextos.
¿Pero a que nos referimos cuando hablamos de contexto y lenguaje?
El contexto es una parte bien definida dentro de la empresa cuyos integrantes se comunican utilizando sus propios términos, tienen sus propias definiciones y reglas para desempeñar el trabajo y alcanzar los objetivos.
Siguiendo con el ejemplo utilizado hasta ahora, supongamos que además de una web por medio de la cual vendemos viajes online ofrecemos también un software para agencias de viajes para que ellas también puedan vender a su público.
Es bastante probable que en la empresa existan por lo menos estos cuatro departamentos:
- Venta
- Accounting
- Desarrollo
- Atención al cliente
Ahora, si consideramos la palabra cliente, dependiendo de quien la utilice, donde y cuando, puede adquirir un significado u otro.
Para los de venta y accounting, el cliente vendría a ser la agencia de viajes que contrata el software.
Para los de atención al cliente, el cliente es el usuario final que compra los productos en la web.
Para los de desarrollo, el cliente es un dispositivo que se conecta a una API.
¿Ya empezáis a ver por donde van los tiros verdad?
Con este sencillo ejemplo nos damos cuenta de la importancia de estar todos alineados cuando hablamos de algo, de entender en que contexto nos estamos moviendo y utilizar el mismo lenguaje.
¿Y de que manera identificamos los contextos?
Una de las herramientas que DDD propone para identificar el contexto son los bounded context.
Tal como lo define Eric Evans, autor del libro Domain-Driven Design: Tackling Complexity in the Heart of Software y uno de los personajes más influyentes del panorama DDD, un bounded context es una parte bien definida de un software en la cual términos, definiciones y reglas concretas pueden aplicarse de manera consistente.
Entonces, si quisiéramos solucionar el problema del subdominio Producto y proveedores probablemente deberíamos preguntarnos…
¿Como podemos dar soporte a este subdominio, de que manera lo vamos a modelar?
Y con toda probabilidad la respuesta sería: con algún sistema para la gestión del stock de productos.
Y así sucesivamente para cada subdominio.
Puede que el mismo bounded context de soporte a más de un subdominio o que un subdominio se vea soportado por más bounded context, es el caso del subdominio Pricing.
Para poder definir nuestra estrategia de precios es probable que necesitemos de datos del stock y de los datos sobre de las ventas.
Como dicho antes, cada bounded context tiene sus términos, definiciones y reglas concretas.
El conjunto de estos términos y definiciones es el que se conoce como lenguaje ubicuo.
El lenguaje ubicuo es un termino utilizado por el mismo Evans en DDD para describir la practica de crear un lenguaje riguroso entre usuarios del sistema y desarrolladores. El termino riguroso es utilizado aquí para subrayar el hecho de que el lenguaje no puede admitir ambigüedades en un mismo contexto.
Un producto, en el bounded context Gestión del stock seguramente tendrá atributos y comportamiento diferente respecto a un producto en el bounded context Creación de los contenidos, por esta razón es oportuno que estén en bounded context diferentes.
Utilizamos el lenguaje ubicuo para definir las reglas de negocio dentro de un bounded context y estas reglas pueden tener sentido solo y exclusivamente en ese contexto.
Podemos definir el lenguaje ubicuo para cada contexto utilizando un simple archivo de texto o una hoja de calculo en la que iremos recopilando los términos y su significado para el contexto que estamos examinando.
Definir el lenguaje ubicuo y las reglas de negocio no es un proceso unidireccional en el que la gente de negocio habla y los desarrolladores apuntan, más bien es colaborativo.
De hecho los desarrolladores tienen la función de ayudar a esclarecer conceptos o términos que definen el lenguaje.
Un ejemplo podría ser la palabra cliente o usuario que pueden ser términos genéricos, en este caso el desarrollador puede ofrecer sugerencias y alternativas para definir más específicamente un termino o concepto.
En el contexto de una persona que reserva un viaje puede que sea interesante considerar la posibilidad de utilizar la palabra viajero.
Otra metodología extremadamente útil y eficaz que podemos utilizar para definir el lenguaje ubicuo y las reglas de negocio es el event storming. Esta metodología ha sido introducida por primera vez por Alberto Brandolini y consiste en modelar los procesos a partir de un evento clave que normalmente suele ser el cumplimiento del objetivo principal, el más importante.
En el caso de vender viajes online el evento principal sería: un viaje ha sido reservado
A partir de este evento intentaremos determinar que proceso ha originado este evento, probablemente será el proceso de compra.
A su vez el proceso de compra habrá sido desencadenado por una acción o un comando etc.
Y así seguimos dando pasos atrás y en este ejercicio aparecerán términos y reglas de negocio que nos ayudarán a clarificar de una manera más efectiva, colaborativa y divertida el escenario.
El event storming es una practica que merece ser profundizada y en internet hay mucha información al respecto. Os invito a buscar y documentaros acerca de este tema.
Definir las relaciones entre los bounded contexts
Al igual que hemos definido relaciones entre subdominios también tenemos que definir relaciones entre bounded contexts. Puede que existan bounded context que pueden vivir de manera aislada sin tener ninguna relación con los demás contextos pero sin duda habrá contextos que tienen algún tipo de relación entre ellos.
Por ejemplo, para crear los contenidos para un producto es probable que necesitemos información de este producto que se manejan en el stock. Esto determina una relación entre el bounded context Creación de contenidos y el bounded context Gestión de stock.
Las relaciones se pueden clasificar según el flujo de información.
Si el bounded context es el que proporciona información a otro bounded context hablaremos de relación upstream, si en cambio es el que la consume hablaremos de relación downstream.
El entramado de relaciones entre bounded contexts es conocido en DDD como context map.
Existen patrones organizativos y de integración que describen los tipos de relación entre los bounded-context pero como dicho al principio de esta sección no entraremos en detalles en este articulo. Exclusivamente a titulo informativo estos patrones son el Partnership, Shared Kernel, Customer-Supplier Development, Conformist, Separate Ways, Big Ball of Mud, Open Host Service (OHS), Published Language (PL) y Anticorruption Layer (ACL).
Como podéis ver, esto da para otro articulo y es probable que más adelante me plantee hablar del tema.
Y esto es todo respecto a lo que concierne la parte estratégica de DDD.
A partir de aquí podremos ir profundizando en cada punto para adquirir cada vez más conocimiento y experiencia en este tema muy interesante, pero como siempre suelo decir, por algo se empieza y espero que esta guía os sea de ayuda para empezar a introducir el diseño estratégico en vuestro día a día.
Conclusiones
El diseño estratégico en DDD es extremadamente importante para el éxito del negocio y lo mejor de todo, no es nada caro, de hecho, es mucho más barato y rápido de ejecutar de lo que se pueda imaginar.
Todo lo que he explicado se puede resumir en dos o tres días de workshops y si lo comparamos con los enormes beneficios que puede tener en el corto, medio y largo plazo, tanto para la empresa como para sus productos como para los profesionales que en ella trabajan estamos hablando de un negocio redondo (nunca mejor dicho).
El ahorro en tiempo y dinero, unido a la profesionalidad que aporta a todos los niveles de la empresa hace del strategic domain driven design una practica a utilizar sin ninguna duda.
Os aseguro que cuesta mucho más explicar cada vez que algún trabajador se incorpora en la plantilla como funcionan los procesos y a nivel practico, luchar contra la deuda técnica y arreglar bugs que requieren horas de ingeniería inversa, esto sin contar los costes de infraestructura que pueden surgir a raíz de una mala decisión, servidores y bases de datos para mejorar las performances de nuestras aplicaciones, en fin, la pregunta es:
¿Porque no dar una posibilidad al DDD utilizando de verdad DDD?
Gracias por haber llegado hasta el final y hasta pronto.
