O que é uma raiz agregada?

Estou tentando entender como usar corretamente o padrão de repositório. O conceito central de uma raiz agregada continua aparecendo. Ao pesquisar na Web e no Stack Overflow para obter ajuda com o que é uma raiz agregada, continuo encontrando discussões sobre eles e links inativos para páginas que deveriam conter definições básicas.

No contexto do padrão do repositório, o que é uma raiz agregada?

No contexto do padrão do repositório, as raízes agregadas são os únicos objetos que o código do cliente carrega do repositório.

O repositório encapsula o acesso a objetos filho - da perspectiva de um chamador, ele os carrega automaticamente, ao mesmo tempo em que a raiz é carregada ou quando eles são realmente necessários (como no carregamento lento).

Por exemplo, você pode ter um Orderobjeto que encapsule operações em vários LineItemobjetos. Seu código de cliente nunca carregaria os LineItemobjetos diretamente, apenas o Orderque os contém, que seria a raiz agregada para essa parte do seu domínio.

Partida Evans DDD:

Um AGGREGATE é um cluster de objetos associados que tratamos como uma unidade com a finalidade de alterar dados. Cada AGGREGATE tem uma raiz e um limite. O limite define o que está dentro do AGGREGATE. A raiz é uma ENTIDADE única e específica contida no AGREGADO.

E:

A raiz é o único membro do AGGREGATE que objetos externos têm permissão para manter referências a [.]

Isso significa que as raízes agregadas são os únicos objetos que podem ser carregados de um repositório.

Um exemplo é um modelo que contém uma Customerentidade e uma Addressentidade. Nunca acessaríamos uma Addressentidade diretamente do modelo, pois não faz sentido sem o contexto de um associado Customer. Então poderíamos dizer que Customere Addressjuntos formam um agregado e que Customeré uma raiz agregada.

Raiz agregada é um nome complexo para uma ideia simples.

Ideia geral

Um diagrama de classes bem projetado encapsula seus elementos internos. O ponto através do qual você acessa essa estrutura é chamado aggregate root.

As partes internas da sua solução podem ser muito complicadas, mas o usuário dessa hierarquia apenas usará root.doSomethingWhichHasBusinessMeaning().

Exemplo

Verifique esta hierarquia de classes simples

Como você quer andar de carro? Escolha melhor API

Opção A (de alguma forma funciona):

car.ride();

Opção B (o usuário tem acesso à classe interna):

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

Se você acha que a opção A é melhor, parabéns. Você fica com o principal motivo por trás aggregate root.

A raiz agregada encapsula várias classes. você pode manipular toda a hierarquia apenas através do objeto principal.

Imagine que você tem uma entidade de computador, essa entidade também não pode viver sem sua entidade de software e de hardware. Estes formam o Computeragregado, o mini-ecossistema da parte Computer do domínio.

A Raiz Agregada é a entidade da mãe-mãe dentro do agregado (no nosso caso Computer), é uma prática comum que seu repositório funcione apenas com as entidades que são Raízes Agregadas, e essa entidade é responsável por inicializar as outras entidades.

Considere a raiz agregada como um ponto de entrada para um agregado.

No 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 {}

Lembre-se de que o hardware provavelmente também seria um ValueObject (não possui identidade por conta própria), considere-o apenas como um exemplo.

Se você seguir uma abordagem baseada no primeiro banco de dados, a raiz agregada geralmente será a tabela no lado 1 de um relacionamento 1-many.

O exemplo mais comum é uma pessoa. Cada pessoa tem muitos endereços, um ou mais recibos de pagamento, faturas, entradas de CRM, etc. Nem sempre é o caso, mas 9/10 vezes.

No momento, estamos trabalhando em uma plataforma de comércio eletrônico e basicamente temos duas raízes agregadas:

1. clientes
2. Vendedores

Os clientes fornecem informações de contato, atribuímos transações a eles, as transações obtêm itens de linha etc.

Os vendedores vendem produtos, têm pessoas de contato, páginas sobre nós, ofertas especiais etc.

Eles são tratados pelo repositório Customer e Seller, respectivamente.

Dinah:

No contexto de um repositório, a raiz agregada é uma entidade sem entidade pai. Ele contém zero, uma ou muitas entidades filhas cuja existência depende do pai para sua identidade. Esse é um relacionamento Um para Muitos em um Repositório. Essas entidades filhas são agregados simples.

De um link quebrado :

Dentro de um agregado, há uma raiz agregada. A Raiz Agregada é a Entidade pai de todas as outras Entidades e Objetos de Valor no Agregado.

Um Repositório opera com uma Raiz Agregada.

Mais informações também podem ser encontradas aqui .

Agregar significa coleção de algo.
root é como o nó superior da árvore, de onde podemos acessar tudo como o <html>nó no documento da página da web.
Analogia do blog, um usuário pode ter muitas postagens e cada postagem pode ter muitos comentários. portanto, se buscarmos qualquer usuário, ele poderá atuar como root para acessar todas as postagens relacionadas e comentários adicionais dessas postagens. Todos esses itens são considerados coletados ou agregados.

Agregado é onde você protege seus invariantes e força a consistência, limitando seu acesso à raiz agregada. Não se esqueça, o agregado deve projetar as regras de negócios e invariantes do seu projeto, não o relacionamento com o banco de dados. você não deve injetar nenhum repositório e nenhuma consulta não é permitida.

Em Erlang, não há necessidade de diferenciar entre agregados, uma vez que o agregado é composto por estruturas de dados dentro do estado, em vez da composição de OO. Veja um exemplo: https://github.com/bryanhunter/cqrs-with-erlang/tree/ndc-london