Diseño guiado por el dominio.

Aborda la complejidad en el corazón del software modelando explícitamente el dominio de negocio, y manteniendo ese modelo —y el código que lo expresa— en estrecha alineación con el lenguaje que usan las personas que entienden el dominio.

A medida que un sistema crece, las reglas de negocio tienden a dispersarse entre controladores, servicios y consultas a la base de datos. El código se aleja de cómo el negocio habla realmente de su trabajo, así que cada conversación necesita traducción y cada cambio arriesga romper una regla que nadie recordaba.

Los diseños centrados en datos lo empeoran: los modelos se convierten en bolsas anémicas de getters y setters, las invariantes no viven en ningún lugar concreto, y el sistema se transforma poco a poco en una "gran bola de lodo" que solo unos pocos se atreven a tocar.

El diseño guiado por el dominio ataca el problema en dos niveles.

El diseño estratégico divide un dominio grande en contextos delimitados —fronteras explícitas dentro de las cuales un modelo y su lenguaje son consistentes— y mapea las relaciones entre ellos. Cada contexto es libre de modelar el mismo concepto de forma distinta allí donde el negocio realmente lo ve de forma distinta.

El diseño táctico construye un modelo rico dentro de un contexto a partir de un pequeño conjunto de bloques de construcción, e insiste en un lenguaje ubicuo: los mismos términos aparecen en las conversaciones, en el modelo y en el código.

Los bloques de construcción tácticos:

• Entidades: objetos definidos por una identidad que persiste en el tiempo (un Customer, un Order).
• Objetos de valor: objetos inmutables definidos por sus atributos (un Money, una Address).
• Agregados: conjuntos de entidades y objetos de valor con una única raíz del agregado que protege las invariantes del conjunto y es el único punto de entrada para los cambios.
• Repositorios: interfaces tipo colección que cargan y persisten agregados completos, ocultando los detalles de almacenamiento.
• Servicios de dominio: operaciones sin estado que no pertenecen de forma natural a una sola entidad.
• Eventos de dominio: registros de algo significativo que ocurrió en el dominio.

Los bloques estratégicos —contexto delimitado y mapa de contexto— organizan estos modelos entre equipos y subsistemas.

• Úsalo cuando la complejidad principal esté en las reglas de negocio, no en la tecnología: logística, finanzas, seguros, planificación.
• Úsalo cuando varios equipos deban ponerse de acuerdo en una comprensión compartida y en evolución de un dominio.
• Evítalo en aplicaciones CRUD simples o de entrada de datos, donde la sobrecarga del modelado te aporta poco.

1. Habla con los expertos del dominio y destila el lenguaje ubicuo; anota los términos y lo que significan.
2. Identifica el dominio principal —la parte que da ventaja competitiva— y concentra ahí el esfuerzo de modelado.
3. Divide el dominio en contextos delimitados y dibuja un mapa de contexto de sus relaciones.
4. Dentro de un contexto, modela agregados de modo que cada uno imponga sus propias invariantes en una sola transacción.
5. Carga y guarda los agregados a través de repositorios; publica eventos de dominio para lo que les importa a otros contextos.
6. Refina de forma continua: el modelo nunca está “terminado”, evoluciona a medida que se profundiza la comprensión.