Co to jest korzeń zagregowany?

Próbuję się zastanowić, jak prawidłowo używać wzorca repozytorium. Coraz częściej pojawia się centralna koncepcja Korzenia Kruszywa. Podczas przeszukiwania sieci i przepełnienia stosu w poszukiwaniu pomocy dotyczącej tego, czym jest zagregowany katalog główny, wciąż znajduję dyskusje na ich temat i martwe linki do stron, które powinny zawierać podstawowe definicje.

W kontekście wzorca repozytorium, czym jest zagregowany katalog główny?

W kontekście wzorca repozytorium zagregowane katalogi główne są jedynymi obiektami, które kod klienta ładuje z repozytorium.

Repozytorium hermetyzuje dostęp do obiektów potomnych - z perspektywy dzwoniącego automatycznie ładuje je, albo w tym samym czasie, gdy ładowany jest root, albo kiedy są one rzeczywiście potrzebne (jak w przypadku leniwego ładowania).

Na przykład możesz mieć Orderobiekt, który zawiera operacje na wielu LineItemobiektach. Kod klienta nigdy nie ładowałby LineItemobiektów bezpośrednio, tylko ten, Orderktóry je zawiera, co stanowiłoby zagregowany katalog główny dla tej części domeny.

Od Evans DDD:

AGGREGATE to klaster powiązanych obiektów, które traktujemy jako jednostkę do celów zmian danych. Każda AGREGAT ma rdzeń i granicę. Granica określa to, co znajduje się w AGREGACJI. Rdzeń jest pojedynczą, specyficzną ENTITY zawartą w AGGREGATE.

I:

Katalog główny jest jedynym członkiem AGGREGATE, w którym obiekty zewnętrzne mogą przechowywać odniesienia do [.]

Oznacza to, że zagregowane katalogi główne są jedynymi obiektami, które można załadować z repozytorium.

Przykładem jest model zawierający Customerencję i Addressencję. Nigdy nie uzyskalibyśmy dostępu do Addressencji bezpośrednio z modelu, ponieważ nie ma to sensu bez kontekstu powiązanego Customer. Więc można powiedzieć, że Customeri Addressrazem tworzą agregat i że Customerjest agregatem korzeń.

Zagregowany katalog główny to złożona nazwa prostego pomysłu.

Główny pomysł

Dobrze zaprojektowany diagram klas zawiera jego elementy wewnętrzne. Punkt, przez który uzyskujesz dostęp do tej struktury, nazywa się aggregate root.

Elementy wewnętrzne twojego rozwiązania mogą być bardzo skomplikowane, ale użytkownik tej hierarchii po prostu użyje root.doSomethingWhichHasBusinessMeaning().

Przykład

Sprawdź tę prostą hierarchię klas

Jak chcesz jeździć samochodem? Wybierz lepsze API

Opcja A (po prostu jakoś działa):

car.ride();

Opcja B (użytkownik ma dostęp do wewnętrznych klas):

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

Jeśli uważasz, że ta opcja A jest lepsza, to gratulacje. Masz główny powód aggregate root.

Agregat root zawiera wiele klas. możesz manipulować całą hierarchią tylko poprzez główny obiekt.

Wyobraź sobie, że masz encję Komputer, ta encja również nie może żyć bez encji Oprogramowanie i encji Sprzęt. Tworzą one Computeragregat, mini ekosystem dla komputerowej części domeny.

Korzeń agregujący jest jednostką macierzystą wewnątrz agregatu (w naszym przypadku Computer), powszechną praktyką jest, aby repozytorium działało tylko z jednostkami będącymi korzeniami agregującymi, a ta jednostka jest odpowiedzialna za inicjowanie innych jednostek.

Rozważ Korzeń agregatu jako punkt wejścia do agregatu.

W kodzie 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 {}

Należy pamiętać, że sprzęt prawdopodobnie byłby również obiektem ValueObject (nie ma własnej tożsamości), należy go traktować jedynie jako przykład.

Jeśli zastosujesz podejście oparte na pierwszej bazie danych, agregacja katalogu głównego jest zwykle tabelą po 1 stronie relacji 1-many.

Najczęstszym przykładem jest Osoba. Każda osoba ma wiele adresów, co najmniej jeden odcinek wypłaty, faktury, wpisy CRM itp. Nie zawsze tak jest, ale 9/10 razy.

Aktualnie pracujemy na platformie e-commerce i zasadniczo mamy dwa zagregowane źródła:

1. Klienci
2. Sprzedawców

Klienci dostarczają dane kontaktowe, przypisujemy do nich transakcje, transakcje otrzymują elementy zamówienia itp.

Sprzedawcy sprzedają produkty, mają osoby kontaktowe, strony o nas, oferty specjalne itp.

Zajmują się nimi odpowiednio repozytorium klienta i sprzedawcy.

Dinah:

W kontekście repozytorium zagregowany katalog główny jest bytem bez bytu nadrzędnego. Zawiera zero, jeden lub wiele bytów potomnych, których istnienie jest zależne od rodzica pod względem tożsamości. To relacja jeden do wielu w repozytorium. Te byty potomne są zwykłymi agregatami.

Z niedziałającego linku :

W obrębie agregatu znajduje się korzeń agregatu. Korzeń agregacji jest jednostką nadrzędną dla wszystkich innych jednostek i obiektów wartości w agregacie.

Repozytorium działa na Root Aggregate.

Więcej informacji można również znaleźć tutaj .

Agregat oznacza zbiór czegoś.
root jest jak górny węzeł drzewa, z którego możemy uzyskać dostęp do wszystkiego, jak <html>węzeł w dokumencie strony internetowej.
Blog Analogia, użytkownik może mieć wiele postów, a każdy post może mieć wiele komentarzy. więc jeśli ściągniemy dowolnego użytkownika, może on działać jako root, aby uzyskać dostęp do wszystkich powiązanych postów i dalszych komentarzy do tych postów. Wszystko to razem określa się jako zbiór lub agregację

Agregat to miejsce, w którym chronisz niezmienniki i wymuszasz spójność, ograniczając dostęp do głównego źródła danych. Nie zapominaj, że agregacja powinna projektować według reguł biznesowych i niezmienników projektu, a nie relacji do bazy danych. nie powinieneś wstrzykiwać żadnego repozytorium i żadne zapytania nie są dozwolone.

W Erlang nie ma potrzeby rozróżniania agregatów, gdy agregat składa się ze struktur danych wewnątrz stanu, a nie ze składu OO. Zobacz przykład: https://github.com/bryanhunter/cqrs-with-erlang/tree/ndc-london