DDD: czy właściwe jest, aby agregat główny zawierał odwołanie do innego agregatu głównego?

Czy w przypadku projektowania opartego na domenie (DDD) właściwe jest, aby agregacja główna zawierała odwołanie do encji wewnętrznej, która akurat jest jednostką root na oddzielnej agregacji?

Uważam, że nie jest to poprawne, głównie z powodu tej reguły niebieskiej księgi :

Nic poza granicą AGREGACJI nie może zawierać odniesienia do czegokolwiek w środku, z wyjątkiem ENTITY root. Podstawowy ENTITY może przekazywać odniesienia do wewnętrznych PODMIOTÓW innym obiektom, ale te obiekty mogą z nich korzystać tylko przejściowo i nie mogą trzymać się odwołania. Rdzeń może przekazać kopię WARTOŚCIOWEGO OBIEKTU innemu obiektowi i nie ma znaczenia, co się z nim stanie, ponieważ jest to po prostu WARTOŚĆ i nie będzie już miał żadnego związku z AGREGATEM.

Jeśli agregat główny zawiera odniesienie do innego agregatu głównego, granica tego pierwszego zostaje naruszona, a cała koncepcja agregatu jest uszkodzona, więc uważam, że jeśli agregat główny wygląda na potrzebę posiadania odwołania do innego agregatu głównego, to potrzebuję aby utworzyć inny byt, który prawdopodobnie będzie miał część tych samych członków, co inny byt główny, ale nie będzie miał globalnej tożsamości, ponieważ ta inna reguła w książce stanowi:

PODMIOTY Root mają globalną tożsamość. PODMIOTY wewnątrz granicy mają tożsamość lokalną, unikalną tylko w AGREGATIE.

Wierzę, że byłby to właściwy sposób, ale ponieważ wydaje się powtarzalny i zbędny (po zdjęciu z kontekstu DDD, z czystym OOP), proszę o jakieś informacje zwrotne.

object-oriented domain-driven-design

— Lesair Valmont
źródło

Co rozumiesz przez „encję wewnętrzną (która jest akcją root na oddzielnym agregacie)”?

— Erik Eidt,

FWIW, Wszystko może odnosić się do zagregowanej jednostki głównej, ponieważ są to rzeczy o globalnej tożsamości; to, czy strona odsyłająca jest jednostką główną, czy nie, jest nieistotne.

— Erik Eidt,

Jak powiedział Erik. Nie ma również znaczenia, czy odwołujesz się do niego za pomocą identyfikatora, czy odniesienia w swoim modelu. Oba zostaną przekonwertowane na ID na poziomie DB, a posiadanie referencji daje ORM możliwość leniwego ładowania jednostki na żądanie.

— Euforia

Odpowiedzi:

Być może interpretujesz książkę. Mówi w zasadzie: cokolwiek poza agregatem nie może zawierać odniesienia do niczego w nim, z wyjątkiem katalogu głównego. Dlatego trzymanie odwołania do katalogu głównego jest uzasadnione. Trzymanie odniesienia do katalogu głównego nie oznacza, że jest to część twojego agregatu i że możesz kontrolować jego niezmienniki. Zachowuje własne niezmienniki i autonomię.

Jednak,

Powszechnie przyjętą dobrą praktyką jest odwoływanie się do AR poprzez przechowywanie jego identyfikatora, a nie pełnego odniesienia.
Bardziej nowoczesne podejścia do projektowania agregatów (patrz Czerwona Księga ) zalecają czystsze rozdzielenie agregatów. Transakcja biznesowa powinna zmieniać tylko stan pojedynczego agregatu. Przy takim założeniu potrzeba przechowywania odniesienia do innego agregatu ma tendencję do znikania, ponieważ nie zamierzasz modyfikować 2 agregatów w tym samym czasie.

czy właściwe jest, aby agregacja główna zawierała odwołanie do encji wewnętrznej, która jest akcją root na oddzielnej agregacji?

To się nigdy nie zdarza. Obiekt wartości może być częścią wielu agregatów, ale nie może być jednostką. Powodem jest to, że nic nie uniemożliwiłoby ci współużytkowania tej samej instancji encji między agregatami. Powiedzmy, że instancja encji E należy do obu instancji zagregowanych A i B. Ponieważ DDD zakłada, że Aggregate jest punktem wejściowym, będziesz w stanie załadować A, zmodyfikować encję E, jednocześnie cicho naruszając niezmienniki z B (że nie załadowałeś).

Zobacz odpowiedź Grega Younga tutaj: http://domain-driven-design.3010926.n2.nabble.com/Can-an-Entity-be-Shared-across-many-Aggregates-td7579277.html

— guillaume31
źródło

Dziękuję Guillaume za jasną, zwięzłą i wnikliwą odpowiedź. Prawdziwy koneser prawdziwego konesera DDD. Właśnie tego szukałem. Chapeau!

— Lesair Valmont

Wiem, że to może być głupie pytanie, ale czy mogę zapytać, co to znaczy holding a referencew tym kontekście? ponieważ holding a reference to a root is legit

This never happens. A Value Object can be part of multiple Aggregates, but not an Entity. The reason is, nothing would then prevent you from sharing the same entity instance between Aggregates.

— myliłem się,

Hold a referencja = zachowaj ją wewnętrznie / na stałe, jako członek klasy. Dychotomia jest tutaj root a non-root. Możesz zatrzymać odwołanie do katalogu głównego, ale nie odwołanie do użytkownika innego niż root.

— guillaume31

@ guillaume31 bardzo dziękuję, ale czy mogę zapytać, czy dobrze jest przechowywać idwewnętrzny element (inny niż root) w innym agregacie, czy to narusza to, czy (root czy nie)?

— Anyname Donotcare

Co zrobiłbyś z tym identyfikatorem? Nawet repozytoria dają tylko korzenie, a nie jednostki wewnętrzne.

— guillaume31

Twój zagregowany obiekt główny powinien (ogólnie) mieć tylko właściwości, które są częścią jego domeny.

Jeśli masz obiekt AR z właściwością, której nie ma w agregacie, natychmiast pojawia się pytanie. 'Dlaczego nie?'

Możesz dodać identyfikator innego obiektu? Lub wstrzyknąć repozytorium?

Ale wygląda na to, że powinieneś dodać usługę między domenami, która odwołuje się zarówno do obiektów root, jak i wykonuje wymaganą logikę

— Ewan
źródło

Ewan, myślałem raczej o ponownym użyciu klasy między dwoma różnymi agregacjami w sensie OOP, niż o usłudze domenowej działającej jako skrypt biznesowy, który będzie działał z dwoma różnymi agregacjami DDD. Podsumowując, zgadzam się z Tobą, mój zagregowany katalog główny powinien mieć tylko właściwości, które są częścią jego domeny.

— Lesair Valmont,