Domain Driven Design - Aggregate Roots

Question

Mam problemy z agregatami i zagregowanymi źródłami. Mam naturalny korzeń kruszywa, który działa na około 60% żądań użytkownika. To znaczy. te wnioski w naturalny sposób odnoszą się do sumy głównej.

W ramach mojego agregatu mam inny podmiot, który może istnieć tylko jako członek sumy głównej. Użytkownicy zostaną jednak poinformowani o tym innym obiekcie encji. Konieczne może się okazać, że użytkownicy będą operować bezpośrednio na tym niezagregowanym obiekcie głównym.

Tak, myślę, że mam kilka opcji:

1. Mogą one być zarówno kruszywa korzenie w zależności od których działanie jest wymagane przez użytkownika.
2. Wszystkie operacje muszą przechodzić przez główny agregator najwyższego poziomu.

Należy pamiętać, że główny root agregujący będzie przechowywać kolekcję tego innego obiektu.

---

Przykład:

główna kruszywo root: Car

Druga jednostka: krzesło (a Car posiada 2 lub 4 mandaty zależności od typu). W mojej domenie siedzenia mogą istnieć tylko jako część samochodu.

Większość operacji w domenie odbywa się na poziomie samochodu. To będzie dobry kandydat na agregat root. Jednak (i ​​walczę o przykłady tutaj), niektóre operacje będą na poziomie miejsca, np. SpillCoffee, ChangeFabric, Clean ....

Czy Seat i Car mogą być korzeniami zbiorczymi? Czy powinienem zawsze zacząć od samochodu?

Dzięki

Answer 1

Pomysł agregatu jest zagwarantowanie spójności, jako główny odpowiedzialny za integralność danych i zmuszając niezmienników.

Załóżmy, że istnieje zasada taka jak "Tkanina wszystkich miejsc musi być taka sama" lub "" możesz rozlać kawę tylko na miejsce, jeśli ktoś jest w samochodzie ". O wiele trudniej będzie je wymusić, raz klienci będą mogli zmienić materiał oddzielnie, lub te niezmienniki będą musiały być wymuszone na zewnątrz (strefa niebezpieczna). jeśli jest to konieczne, moją radą jest zacząć wszystko od samochodu, ale zawsze myśl o modelu, jeśli istnieją niezmienniki takie jak te, to kto wymusza te niezmienniki? Następnie spróbuj przekazać ten pomysł do kodu i wszystko powinno być w porządku.

Answer 2

W przypadku koszyka z koszykiem i elementami zamówienia mam oba te elementy jako zbiorcze, ponieważ często je modyfikuję niezależnie.

public class Cart : IAggregateRoot 
{ 
    public List<LineItem> LineItems {get;} 
} 

public class LineItems : IAggregateRoot 
{ 
    public List<LineItem> LineItems {get;} 
} 

Jednak mam oddzielny kontekst ograniczone do zamówień i w tym przypadku wystarczy mieć jeden zbiorczy korzeń ponieważ nie trzeba już zmieniać elementy zamówienia niezależnie.

public class Order : IAggregateRoot 
{ 
    public List<LineItem> LineItems {get;} 
} 

Inną opcją jest mieć sposób patrzenia się łączną pierwiastek z ID dziecięcej.

Car GetCarFromSeatID(guid seatID) 

Answer 3

Prawdopodobnie potrzebujesz głębszej wiedzy na temat jakiegoś aspektu modelu domeny. To pytanie pokazuje, że masz zamiar wymyślić sposób zorganizowania podmiotów do dostarczania systemu, kiedy, najlepiej, tego rodzaju pytania są już odbierane przed wdrożeniem.

Kiedy pojawia się tylko w implementacji systemu, możesz wrócić do przeglądu domeny lub odkryłeś delikatność, której opinie mogą - i powinny - zebrać zmiany w powiązanych szczegółach firmy, aby domena była bogatsza i lepiej modelowana .

W przykładzie samochodowym zastosowałem podejście dwóch agregatów, które korelują różne konteksty. Pierwszym z nich byłoby podejście "samochód ma miejsce", a w tym zestawieniu możliwe działania związane z "siedzeniem" byłyby tylko tymi, które mają sens "siedzenie jako część samochodu". Przykład: czysty.

Drugi agregat byłby w kontekście "siedzenia", a możliwe byłyby działania i konfiguracje siedzenia jako samodzielnego. Przykład: ChangeFabric, ColorList. W ten sposób zagregowany "samochód" ma "siedzibę", ale klienci mogą znać siedzibę w kontekście, który ma sens. Co jest niebezpieczne, jak powiedział samuelcarrijo w poprzednim poście. Jeśli modyfikacje między kontekstami wpływają na integralność domeny, utracisz całą koncepcję zagregowaną.