DDD8 min de lectura
DDD cuando el dominio es complejo
Qué cambia cuando el dominio tiene reglas que no caben en una tabla: límites, lenguaje común y las decisiones que tomé al modelar la operación de un almacén.
Hay dominios donde una tabla por entidad basta. Y hay dominios donde las reglas no caben en columnas: dependen del contexto, cambian por instalación y afectan a varias partes del sistema a la vez. En esos casos, DDD no es una capa de carpetas; es una forma de decidir dónde vive cada regla.
El dominio no es la base de datos
El primer síntoma de un dominio complejo es que el modelo de datos empieza a decidir el comportamiento. Las validaciones se reparten entre la base de datos, el controlador y la interfaz, y ya nadie sabe cuál es la fuente de verdad.
DDD propone lo contrario: modelar el comportamiento y el lenguaje del negocio, y tratar la persistencia como un detalle. No porque la base de datos no importe, sino porque las reglas deben poder probarse sin ella.
Lenguaje común
Un almacén no habla de «registros» ni de «filas»: habla de tareas, posiciones, carretillas, picking y operadores. Cuando el código usa ese mismo vocabulario, las conversaciones con negocio y con los fabricantes se vuelven más cortas.
En Bodega Digital ese vocabulario fue parte del diseño: una tarea es una unidad con intención, no un mensaje genérico; un dispositivo tiene capacidades, no solo un identificador. El modelo refleja cómo se trabaja, no cómo se almacena.
Límites: dónde está el coste de cambiar
La pregunta útil para encontrar un contexto delimitado no es «¿qué entidades van juntas?», sino «¿qué cambia junto y qué puede cambiar por separado?». Las reglas de negocio de un almacén cambian por instalación; el protocolo de un robot cambia por fabricante y versión. Son dos velocidades distintas y merecen límites distintos.
Por eso cada familia de dispositivo terminó en su propio microservicio con adaptadores por modelo, versión y protocolo, mientras el core mantenía las reglas que no dependen del hardware. Un cambio de fabricante no obliga a tocar el dominio; un cambio de regla de negocio no obliga a tocar los adaptadores.
Agregados y tareas
Un agregado es una frontera de consistencia. En una operación industrial, la tarea es un buen candidato: tiene un ciclo de vida claro, un responsable y un resultado. Al modelarla con estados explícitos, las transiciones se pueden probar y los errores dejan de ser efectos secundarios.
Esa frontera también evita el agregado gigante que todo lo sabe. La tarea no necesita conocer el mapa completo del almacén ni el protocolo del dispositivo; necesita saber qué hay que hacer y en qué estado está.
Eventos de dominio
Cuando una tarea cambia de estado, ese cambio es un hecho del negocio. Publicarlo como evento permite que otros servicios reaccionen sin que la tarea sepa quiénes son. Es la misma idea de los límites, aplicada al tiempo: el dominio declara lo que pasó y cada consumidor decide qué hacer.
La disciplina está en no convertir el evento en una llamada encubierta. Si el emisor necesita una respuesta para continuar, probablemente no era un evento.
El coste de DDD
DDD exige más conversación y más modelado inicial que abrir una tabla y seguir. En un dominio simple, ese coste no se recupera: una aplicación de formularios con reglas claras no necesita agregados ni contextos.
Merece la pena cuando hay varias fuentes de variación —instalaciones, fabricantes, reglas que cambian— y cuando el coste de un cambio mal localizado es alto. Ahí, el modelado es lo que evita que cada nueva regla se convierta en un condicional más.
Cierre
DDD no hace que un dominio sea complejo; reconoce que ya lo era y decide dónde poner cada cosa. La señal de que ha funcionado no es la elegancia del diagrama, sino que añadir una variante nueva toca menos archivos de los que tocaba antes.