Lo que entiendo sobre el diseño dirigido por dominios

DDD 101

Cuanto más grande es el proyecto, más difícil es mantenerlo. Una forma de ayudar a ello es dividir la aplicación en áreas más pequeñas según sus reglas de negocio, conocidas como dominios.

Básicamente, un dominio es un área de conocimiento, ya sea pública, como las reglas del ajedrez, o privada, como las reglas de negocio de una organización sin ánimo de lucro.

Un dominio complejo es probable que utilice conocimientos de otros dominios. Por ejemplo, una ONL que enseña ajedrez en línea sabrá sobre el ajedrez, la enseñanza a través de plataformas en línea, y, aunque no se cobre como alumno, sobre sus finanzas.

Cada subdominio de su dominio se conoce en DDD como contextos acotados, cada uno tiene su propio modelo del mundo construido con unidades de código especializadas, conocidas como bloques de construcción. Aquí me centraré en las entidades y los objetos-valor, ambos pueden ser referenciados como objetos.

Las entidades son objetos destinados a ser únicos dentro del dominio. Esto se consigue utilizando una o más propiedades para identificar una entidad determinada. Por ejemplo, dos usuarios que utilicen el mismo nombre en un sistema siempre tendrán correos electrónicos diferentes porque los correos electrónicos no se pueden repetir – la mayoría de las veces, las entidades se diferencian por un id, y a veces por una combinación de propiedades.

Los objetos-valor, por otro lado, no tienen una identidad, por lo que sólo sus propiedades se pueden utilizar para distinguir entre dos instancias. Tomemos por ejemplo dos peones (la ficha de ajedrez), tienen el mismo aspecto si provienen del mismo juego y tienen el mismo color, por lo que no importa si se intercambian. En DDD, los objetos-valor son inmutables por lo que es más fácil razonar con ellos.

Integridad de los datos

Un contexto acotado no expone todos sus objetos para garantizar la integridad de sus datos. En su lugar, expone algunas raíces de los agregados como una especie de interfaz pública para sí mismo.

Un agregado no es más que una entidad que se compone de otros objetos. Para ser más precisos, un agregado es un conjunto de objetos asociados que tratamos como una unidad a la hora de modificar los datos.

En términos prácticos, los agregados adoptarán la forma de la estructura de datos conocida como árbol. Y por esa razón, todos los agregados tienen una raíz.

El único miembro de un agregado al que pueden referirse otros objetos es su raíz, y por tanto esto es lo que exponemos. Esto se hace así porque evita que otros objetos retoquen los datos de una forma que el agregado no puede controlar.

Es importante dejar claro que un contexto acotado puede usar muchos agregados aunque su raíz no esté expuesta directamente al mundo exterior.

Tratando con múltiples contextos acotados

Pero las cosas se pueden complicar más, ¿verdad? Cada contexto delimitado obtiene un modelo ligeramente diferente de los mismos objetos, teniendo diferentes propiedades y comportamientos. Así que un usuario en un contexto de juego puede tener una propiedad para manejar su puntuación que en un contexto financiero es irrelevante y por lo tanto no existe.

Y eso no es todo. También es posible que un concepto de dominio, representado como una entidad en un contexto acotado, se represente como un objeto-valor en otro, o simplemente se omita por completo.

Por ejemplo, mientras que el contexto de la enseñanza requiere que los profesores sean representados como entidades para que puedan ser asignados a los estudiantes por sus ids, el contexto de las finanzas prefiere ver «profesor» como un valor para la propiedad de posición de la entidad de los empleados.

Algunos de los otros bloques de construcción DDD son los servicios, los repositorios, las fábricas y los eventos. Intentaré describirlos brevemente.

Los servicios son capacidades de un dominio que no se ajustan naturalmente a las entidades ni a los objetos-valores. Cuidado que son servicios de dominio, no de aplicación ni de infraestructura.

Los repositorios son puentes hacia las unidades de almacenamiento – ¡hola CRUD!.

Las fábricas son métodos de creación de objetos de dominio para que nunca tengan valores inválidos. Esta parte es la que me hizo empezar a pensar en las pruebas impulsadas por el producto.

Los eventos son objetos que representan algo que sucedió en el dominio – sus expertos se preocupan por ellos. Grandes oportunidades para crear una aplicación impulsada por eventos.

Aunque no recuerdo que Evans lo dijera, los contextos acotados son una buena oportunidad para dividir tu código en microservicios, donde cada servicio es un contexto en sí mismo. El primer paso podría ser una ruptura «virtual» donde cada contexto se pone en un módulo diferente en la misma aplicación, y luego si detectas que están realmente aislados, moverlos a otros diferentes.

Un lenguaje para gobernarlos a todos

Una de las primeras cosas que la gente aprende cuando estudia DDD es que su sistema debe ser descrito por un lenguaje omnipresente. Es decir, debemos escribir código utilizando los mismos verbos (para los métodos o servicios) y sustantivos (para los objetos) que utilizan los expertos del dominio cuando hablan con nosotros.

Escribir código así tiene la ventaja de cerrar la brecha de comunicación entre los desarrolladores y los expertos cuando están hablando, pero es una simplificación excesiva de la vida real, por lo que personalmente lo uso como una pauta pero no como una solución definitiva.

Lo dejé para el final porque, para mí, lo más importante de DDD no suele leerse, ya que está en la parte «compleja» del libro.

Recientemente me he enterado de que el propio autor dijo que el orden en que presenta las cosas en el libro no es el óptimo, y que lo que describí aquí se acerca más a lo que hubiera sido ideal 😍. Lo escuché en un podcast refiriéndose a este