¿Qué es una raíz agregada?

Estoy tratando de entender cómo usar correctamente el patrón de repositorio. El concepto central de una raíz agregada sigue surgiendo. Cuando busco ayuda tanto en la web como en Stack Overflow para saber qué es una raíz agregada, sigo encontrando discusiones sobre ellos y enlaces muertos a páginas que se supone que contienen definiciones básicas.

En el contexto del patrón de repositorio, ¿qué es una raíz agregada?

En el contexto del patrón de repositorio, las raíces agregadas son los únicos objetos que su código de cliente carga desde el repositorio.

El repositorio encapsula el acceso a los objetos secundarios: desde la perspectiva de la persona que llama, los carga automáticamente, ya sea al mismo tiempo que se carga la raíz o cuando realmente se necesitan (como con la carga diferida).

Por ejemplo, puede tener un Orderobjeto que encapsula operaciones en varios LineItemobjetos. Su código de cliente nunca cargaría los LineItemobjetos directamente, solo el Orderque los contiene, que sería la raíz agregada para esa parte de su dominio.

De Evans DDD:

Un AGREGADO es un grupo de objetos asociados que tratamos como una unidad con el propósito de cambios de datos. Cada AGREGADO tiene una raíz y un límite. El límite define lo que está dentro del AGREGADO. La raíz es una ENTIDAD única y específica contenida en el AGREGADO.

Y:

La raíz es el único miembro de AGGREGATE que permite que los objetos externos contengan referencias a [.]

Esto significa que las raíces agregadas son los únicos objetos que se pueden cargar desde un repositorio.

Un ejemplo es un modelo que contiene una Customerentidad y una Addressentidad. Nunca accederíamos a una Addressentidad directamente desde el modelo, ya que no tiene sentido sin el contexto de un asociado Customer. Entonces podríamos decir queCustomer y Addressjuntos formar un agregado y esa Customeres una raíz agregada.

La raíz agregada es un nombre complejo para una idea simple.

Idea general

El diagrama de clase bien diseñado encapsula sus componentes internos. Se llama el punto a través del cual accede a esta estructura aggregate root.

Las partes internas de su solución pueden ser muy complicadas, pero el usuario de esta jerarquía solo lo usará root.doSomethingWhichHasBusinessMeaning().

Ejemplo

Comprueba esta jerarquía de clases simple

¿Cómo quieres viajar en tu auto? Elegí mejor api

Opción A (de alguna manera funciona):

car.ride();

Opción B (el usuario tiene acceso a las clases internas):

if(car.getTires().getUsageLevel()< Car.ACCEPTABLE_TIRE_USAGE)
    for (Wheel w: car:getWheels()){
        w.spin();
    }
}

Si crees que la opción A es mejor, felicidades. Tienes la razón principal detrás aggregate root.

La raíz agregada encapsula múltiples clases. puedes manipular toda la jerarquía solo a través del objeto principal.

Imagine que tiene una entidad de computadora, esta entidad tampoco puede vivir sin su entidad de software y su entidad de hardware. Estos forman el Computeragregado, el mini ecosistema para la porción de Computadora del dominio.

La raíz agregada es la entidad de la nave nodriza dentro del agregado (en nuestro caso Computer), es una práctica común que su repositorio solo trabaje con las entidades que son raíces agregadas, y esta entidad es responsable de inicializar las otras entidades.

Considere la raíz agregada como un punto de entrada a un agregado.

En el código C #:

public class Computer : IEntity, IAggregateRoot
{
    public Hardware Hardware { get; set; }
    public Software Software { get; set; }
}

public class Hardware : IEntity { }
public class Software : IValueObject { }

public class Repository<T> : IRepository<T> where T : IAggregateRoot {}

Tenga en cuenta que el hardware probablemente también sea un ValueObject (no tiene identidad propia), considérelo solo como un ejemplo.

Si sigue un enfoque de base de datos primero, la raíz agregada suele ser la tabla en el lado 1 de una relación de 1-muchos.

El ejemplo más común es una persona. Cada persona tiene muchas direcciones, uno o más recibos de pago, facturas, entradas de CRM, etc. No siempre es el caso, pero 9/10 veces lo es.

Actualmente estamos trabajando en una plataforma de comercio electrónico, y básicamente tenemos dos raíces agregadas:

1. Clientes
2. Vendedores

Los clientes suministran información de contacto, les asignamos transacciones, las transacciones obtienen líneas de pedido, etc.

Los vendedores venden productos, tienen personas de contacto, páginas sobre nosotros, ofertas especiales, etc.

Estos son atendidos por el repositorio del Cliente y del Vendedor respectivamente.

Dina:

En el contexto de un repositorio, la raíz agregada es una entidad sin entidad principal. Contiene cero, una o muchas entidades secundarias cuya existencia depende del padre para su identidad. Esa es una relación de uno a muchos en un repositorio. Esas entidades infantiles son simples agregados.

Desde un enlace roto :

Dentro de un Agregado hay una Raíz Agregada. La raíz agregada es la entidad principal para todas las demás entidades y objetos de valor dentro del agregado.

Un repositorio opera sobre una raíz agregada.

Más información también se puede encontrar aquí .

Agregado significa colección de algo.
La raíz es como el nodo superior del árbol, desde donde podemos acceder a todo, como el <html>nodo en el documento de la página web.
Blog Analogy, un usuario puede tener muchas publicaciones y cada publicación puede tener muchos comentarios. así que si buscamos a cualquier usuario, entonces puede actuar como root para acceder a todas las publicaciones relacionadas y comentarios adicionales de esas publicaciones. Se dice que todos estos son de colección o agregados

Agregado es donde protege sus invariantes y fuerza la consistencia al limitar su acceso a la raíz agregada de pensamiento. No olvide que el agregado debe diseñar sobre las reglas comerciales e invariantes de su proyecto, no la relación de la base de datos. no debe inyectar ningún repositorio y no se permiten consultas.

En Erlang no hay necesidad de diferenciar entre agregados, una vez que el agregado está compuesto por estructuras de datos dentro del estado, en lugar de la composición OO. Vea un ejemplo: https://github.com/bryanhunter/cqrs-with-erlang/tree/ndc-london