Respuesta.

El Domain-Driven Design (DDD) es un enfoque para el diseño de sistemas de software que se centra en el dominio y su lógica. DDD descompone dominios complejos en contextos limitados (bounded contexts) que están relacionados pero son independientes. En cada contexto se desarrolla un lenguaje propio (Ubiquitous Language), acordado con los expertos del dominio. Los principales bloques de construcción de DDD:

• Entity: objeto con un identificador único y un ciclo de vida (por ejemplo, un pedido).
• Value Object: objeto inmutable sin identificador único (por ejemplo, una dirección de entrega).
• Aggregate & Aggregate Root: conjunto de objetos para el cual todos los cambios pasan a través de la raíz del agregado.
• Repository: capa para trabajar con el almacenamiento de agregados.
• Service: operaciones que no se relacionan con un objeto específico.

Los contextos limitados a menudo representan microservicios separados que interactúan a través de API claramente descritos o eventos.

Ejemplo de código en Java (Spring):

// Ejemplo de Value Object
@Embeddable
public class Address {
  private String city;
  private String street;
  // ... constructores, equals, hashCode
}

// Ejemplo de Entity con Aggregate Root
@Entity
public class Order {
  @Id
  private Long id;
  @Embedded
  private Address deliveryAddress;
  // ... métodos de negocio
}

Características clave:

• Descomposición clara del dominio y contenedorización de la lógica.
• Simplificación del desarrollo y escalabilidad a través de la isolación.
• Aumento de la coherencia entre el lenguaje técnico y el lenguaje de negocio del equipo.

Preguntas engañosas.

¿Todos los objetos en DDD son Entities?

No, también existen Value Objects: no tienen unicidad, su estado define completamente la identidad.

Address a1 = new Address("Moscú", "Arbat");
Address a2 = new Address("Moscú", "Arbat");
System.out.println(a1.equals(a2)); // true

¿Significa que la descomposición en microservicios implica la aplicación de DDD?

No, se puede aplicar DDD también en el marco de una aplicación monolítica, construyendo los límites de contexto internos.

¿Siempre es necesario un repositorio para cada agregado?

Por lo general sí, pero a veces un agregado se puede almacenar completamente como parte de otro agregado, si no es la raíz de una transacción de negocio separada.