Che cos'è una radice aggregata?

Sto cercando di capire come utilizzare correttamente il modello di repository. Il concetto centrale di una radice aggregata continua a emergere. Quando cerco sia il Web che Stack Overflow per aiuto su cosa sia una radice aggregata, continuo a trovare discussioni su di essi e collegamenti morti a pagine che dovrebbero contenere definizioni di base.

Nel contesto del modello di repository, che cos'è una radice aggregata?

Nel contesto del modello di repository, le radici aggregate sono gli unici oggetti caricati dal codice client dal repository.

Il repository incapsula l'accesso agli oggetti figlio: dal punto di vista di un chiamante li carica automaticamente, contemporaneamente al caricamento della radice o quando sono effettivamente necessari (come nel caso del caricamento lento).

Ad esempio, potresti avere un Orderoggetto che incapsula le operazioni su più LineItemoggetti. Il codice client non caricherà mai gli LineItemoggetti direttamente, ma solo quelli Orderche li contengono, che sarebbe la radice aggregata per quella parte del dominio.

Da Evans DDD:

Un AGGREGATO è un cluster di oggetti associati che trattiamo come un'unità ai fini della modifica dei dati. Ogni AGGREGATO ha una radice e un confine. Il confine definisce ciò che è all'interno dell'AGGREGATO. La radice è una singola ENTITÀ specifica contenuta nell'AGGREGATO.

E:

Il root è l'unico membro di AGGREGATE a cui gli oggetti esterni possono contenere riferimenti a [.]

Ciò significa che le radici aggregate sono gli unici oggetti che possono essere caricati da un repository.

Un esempio è un modello che contiene Customerun'entità e Addressun'entità. Non potremmo mai accedere a Addressun'entità direttamente dal modello in quanto non ha senso senza il contesto di un associato Customer. Quindi potremmo dire che Customere Addressinsieme formano un aggregato e che Customerè una radice di aggregazione.

La radice aggregata è un nome complesso per un'idea semplice.

Idea generale

Il diagramma di classe ben progettato incapsula i suoi interni. Viene chiamato il punto attraverso il quale si accede a questa struttura aggregate root.

Gli interni della tua soluzione possono essere molto complicati, ma l'utente di questa gerarchia userà semplicemente root.doSomethingWhichHasBusinessMeaning().

Esempio

Controlla questa semplice gerarchia di classi

Come vuoi guidare la tua auto? Scegli meglio API

Opzione A (funziona in qualche modo):

car.ride();

Opzione B (l'utente ha accesso agli interni di classe):

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

Se pensi che l'opzione A sia migliore, allora congratulazioni. Hai la ragione principale dietro aggregate root.

La radice aggregata incapsula più classi. puoi manipolare l'intera gerarchia solo attraverso l'oggetto principale.

Immagina di avere un'entità Computer, anche questa entità non può vivere senza la sua entità Software e Hardware. Questi formano l' Computeraggregato, il mini-ecosistema per la parte del dominio Computer.

Aggregate Root è l'entità madre all'interno dell'aggregato (nel nostro caso Computer), è pratica comune far lavorare il proprio repository solo con le entità che sono Radici aggregate e questa entità è responsabile dell'inizializzazione delle altre entità.

Considerare la radice aggregata come un punto di ingresso a un aggregato.

Nel codice 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 {}

Tieni presente che probabilmente anche l'hardware sarebbe un ValueObject (non ha un'identità propria), consideralo solo come esempio.

Se segui un approccio basato sul database, la radice aggregata è in genere la tabella sul lato 1 di una relazione 1-many.

L'esempio più comune è una persona. Ogni persona ha molti indirizzi, una o più buste paga, fatture, voci CRM, ecc. Non è sempre il caso, ma è 9/10 volte.

Attualmente stiamo lavorando su una piattaforma di e-commerce e fondamentalmente abbiamo due radici aggregate:

1. I clienti
2. venditori

I clienti forniscono informazioni di contatto, assegniamo loro transazioni, transazioni ottengono elementi pubblicitari, ecc.

I venditori vendono prodotti, hanno persone di contatto, su di noi pagine, offerte speciali, ecc.

Questi sono curati rispettivamente dal repository Cliente e Venditore.

Dinah:

Nel contesto di un repository, la radice aggregata è un'entità senza entità padre. Contiene zero, una o più entità figlio la cui esistenza dipende dal genitore per la sua identità. Questa è una relazione One to Many in un repository. Tali entità figlio sono aggregati semplici.

Da un collegamento interrotto :

All'interno di un aggregato è presente una radice aggregata. La radice aggregata è l'entità padre di tutte le altre entità e oggetti valore all'interno dell'aggregazione.

Un repository opera su una radice aggregata.

Ulteriori informazioni possono essere trovate anche qui .

Aggregato significa raccolta di qualcosa.
root è come il nodo superiore dell'albero, da cui possiamo accedere a tutto come il <html>nodo nel documento della pagina web.
Blog Analogy, un utente può avere molti post e ogni post può avere molti commenti. quindi se recuperiamo qualsiasi utente, allora può agire come root per accedere a tutti i post correlati e ulteriori commenti di tali post. Si dice che siano tutti insieme raccolti o aggregati

Aggregato è dove proteggi i tuoi invarianti e forza la coerenza limitandone l'accesso alla radice aggregata del pensiero. Non dimenticare, l'aggregato dovrebbe progettare in base alle regole e agli invarianti del tuo progetto, non alle relazioni con il database. non si deve iniettare alcun repository e non sono consentite query.

In Erlang non è necessario distinguere tra aggregati, una volta che l'aggregato è composto da strutture di dati all'interno dello stato, anziché dalla composizione OO. Vedi un esempio: https://github.com/bryanhunter/cqrs-with-erlang/tree/ndc-london