---
title: "Diseño guiado por el dominio"
type: "architectural-pattern"
slug: "domain-driven-design"
url: "http://localhost:3000/es/architectural-patterns/domain-driven-design.md"
also_known_as: "DDD"
description: "Un enfoque de desarrollo de software que centra el diseño en un modelo rico del dominio de negocio, expresado en un lenguaje compartido por ingenieros y expertos del dominio."
languages: ["typescript"]
---
# Diseño guiado por el dominio

_Also known as: DDD_

> Un enfoque de desarrollo de software que centra el diseño en un modelo rico del dominio de negocio, expresado en un lenguaje compartido por ingenieros y expertos del dominio.

## Intent

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.

## Problem

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.

## Solution

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.

## Structure

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.

## Applicability

* Ú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.

## How to Implement

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.

## Pros

* Mantiene el código alineado con el negocio, de modo que los cambios se mapean limpiamente a los requisitos.
* Aísla la complejidad tras contextos delimitados.
* Un lenguaje compartido reduce los malentendidos entre ingenieros y expertos.
* La lógica de dominio rica está desacoplada de la infraestructura y es fácil de probar unitariamente.

## Cons

* Curva de aprendizaje pronunciada y una inversión real en el modelado del dominio.
* Excesivo para aplicaciones simples o mayormente CRUD.
* Requiere acceso continuo a expertos del dominio.
* Mal aplicados, los bloques de construcción se convierten en ceremonia sin beneficio.
## Relations

**Related patterns**

- [CQRS](/es/architectural-patterns/cqrs.md)

## Code Examples

### typescript

```typescript
class Money {
  constructor(readonly amount: number, readonly currency: string) {
    if (amount < 0) throw new Error('amount must be non-negative')
  }
}

// Raíz del agregado: el único lugar donde se imponen las invariantes de Order.
class Order {
  private lines: { sku: string; qty: number }[] = []
  constructor(readonly id: string) {}

  addLine(sku: string, qty: number) {
    if (qty <= 0) throw new Error('quantity must be positive')
    this.lines.push({ sku, qty })
  }
}
```