Domain-Driven Design aplicado a plataformas Java
Cómo se traza un bounded context, por qué el lenguaje ubicuo no es un detalle de documentación y qué parte de DDD aporta valor real en un proyecto empresarial.
Modelar el negocio, no la base de datos
DDD no es un catálogo de patrones técnicos. Es una forma de decidir dónde poner los límites del sistema a partir del lenguaje que usa quien conoce el negocio.
Formulado por Eric Evans, Domain-Driven Design propone que la estructura del código refleje de forma explícita el dominio de negocio y el vocabulario de las personas que trabajan en él.
Se suele reducir DDD a su parte táctica —entidades, objetos de valor, repositorios, agregados— porque es la que se traduce directamente a clases. Pero el valor está sobre todo en la parte estratégica: identificar los bounded contexts, decidir qué relación tienen entre sí y aceptar que un mismo término puede significar cosas distintas en cada uno.
El ejemplo canónico es la palabra «cliente». En facturación es una razón social con un NIF; en soporte es una persona con un historial de incidencias; en marketing es un segmento. Forzar un único modelo de cliente para los tres produce una clase con cuarenta campos de los que cada módulo usa ocho.
Los límites se descubren escuchando, no se dibujan en una pizarra
Un bounded context es la frontera dentro de la cual un modelo y su lenguaje son coherentes. Fuera de ella, los mismos términos significan otra cosa.
Cambia el vocabulario
Un mismo sustantivo se usa con significados distintos según el departamento que lo pronuncie.
Cambia el ritmo
Dos áreas del negocio tienen ciclos de cambio independientes: una lanza cada semana y la otra cada trimestre.
Cambian las reglas
Hay validaciones que solo aplican en una parte concreta del proceso y carecen de sentido en el resto.
Cambia quién decide
Los equipos que mantienen cada parte responden a responsables distintos y priorizan por separado.
Por eso conviene trazar los límites primero como módulos dentro del mismo despliegue: equivocarse en un límite interno cuesta un refactor; equivocarse en un límite que ya es un servicio con su propia base de datos cuesta una migración.
El tamaño de un agregado lo decide la consistencia, no el modelo relacional
Un agregado es un grupo de objetos que se trata como una unidad: tiene una raíz que es el único punto de entrada, y cualquier invariante del grupo se cumple al terminar cada operación sobre él.
La pregunta que determina su tamaño no es cómo se relacionan los datos, sino qué debe ser consistente de forma inmediata. Todo lo que pueda tolerar consistencia eventual pertenece a otro agregado y se coordina mediante eventos de dominio.
El error habitual es diseñar agregados enormes calcados del esquema de la base de datos: un pedido que contiene el cliente completo, el catálogo de productos y el historial de envíos. Ese agregado bloquea filas que nadie necesita bloquear y convierte cualquier operación concurrente en un conflicto. La regla operativa es preferir agregados pequeños y referenciar los demás por identificador.
En qué proyectos aporta valor y en cuáles solo añade clases
DDD aporta valor cuando el dominio es realmente complejo: cuando las reglas de negocio son numerosas, cambian y no resultan evidentes para alguien externo. Ahí la inversión en modelado se recupera en cada cambio posterior.
No aporta valor cuando el sistema es esencialmente un CRUD sobre formularios, cuando la complejidad está en la integración y no en las reglas, o cuando no hay acceso a personas del negocio con las que construir el lenguaje. Sin ese acceso, lo que se obtiene son patrones tácticos sin dominio detrás: más clases y ninguna claridad adicional.
Un contraste rápido: si al preguntar por una regla la respuesta es «depende» y hace falta media hora de explicación, DDD ayudará. Si la respuesta es «se guarda y se muestra», no.
DDD, hexagonal y microservicios son tres decisiones distintas
Suelen aparecer juntas, pero no dependen unas de otras. DDD define qué modelar y dónde están los límites; la arquitectura hexagonal define cómo aislar ese modelo de la tecnología; los microservicios son una decisión de despliegue.
El orden importa. Primero se identifican los bounded contexts y después se decide si cada uno merece ser un despliegue independiente. Hacerlo al revés —definir los servicios y luego intentar encajar el dominio— produce servicios que comparten base de datos y que no pueden desplegarse por separado: un monolito distribuido con todos los costes y ninguna de las ventajas.
La decisión de dividir la trato con más detalle en Java microservicios, y el marco general en arquitectura Java.
Preguntas frecuentes
Dudas habituales sobre domain-driven design en proyectos empresariales.
¿Qué es Domain-Driven Design?
Domain-Driven Design es un enfoque de diseño de software formulado por Eric Evans en el que la estructura del código refleja el dominio de negocio y el lenguaje que emplean las personas que trabajan en él. Su parte más valiosa es la estratégica: identificar bounded contexts y aceptar que un mismo término puede significar cosas distintas en cada uno, en lugar de forzar un modelo único para toda la organización.
¿Qué es un bounded context?
Un bounded context es la frontera dentro de la cual un modelo de dominio y su lenguaje son coherentes y sin ambigüedad. Se identifica escuchando dónde cambia el vocabulario del negocio, dónde los ciclos de cambio son independientes y dónde las reglas de validación dejan de aplicarse. Conviene trazar esos límites primero como módulos dentro del mismo despliegue, porque equivocarse en un límite interno cuesta un refactor y equivocarse en un servicio independiente cuesta una migración.
¿Qué es un agregado en DDD?
Un agregado es un grupo de objetos tratado como una unidad de consistencia, con una raíz que es su único punto de entrada. Su tamaño no lo determina la relación entre los datos, sino qué debe ser consistente de forma inmediata: todo lo que tolere consistencia eventual pertenece a otro agregado y se coordina mediante eventos de dominio. Conviene preferir agregados pequeños y referenciar el resto por identificador.
¿Cuándo conviene aplicar DDD en un proyecto Java?
Conviene cuando el dominio es realmente complejo: reglas numerosas, cambiantes y poco evidentes para alguien externo. No conviene en sistemas que son esencialmente un CRUD sobre formularios, cuando la complejidad está en la integración y no en las reglas, o cuando no hay acceso a personas del negocio con las que construir el lenguaje ubicuo.
¿Qué relación hay entre DDD, arquitectura hexagonal y microservicios?
Son tres decisiones independientes que suelen aparecer juntas. DDD define qué modelar y dónde están los límites, la arquitectura hexagonal define cómo aislar ese modelo de la tecnología, y los microservicios son una decisión de despliegue. El orden correcto es identificar primero los bounded contexts y decidir después si cada uno merece un despliegue independiente; invertirlo produce un monolito distribuido.
Recursos relacionados
Páginas pilar, guías y casos reales que amplían lo tratado aquí.
- Arquitectura Java Dónde encaja DDD en las decisiones estructurales.
- Arquitectura Hexagonal Cómo aislar el modelo de dominio de la tecnología.
- Java Microservicios De bounded context a servicio independiente.
- Guía con código DDD y hexagonal implementados sobre Spring Boot.
- Arquitectura de Software Servicio de diseño y gobierno técnico.
- Hablemos de tu dominio Sesión de modelado para trazar tus bounded contexts.
¿Necesitas modelar el dominio antes de dividir el sistema?
Facilito sesiones de modelado con negocio y tecnología para identificar bounded contexts y definir los límites antes de tocar el código.